I took a fresh backup after having done the firmware update and that looks to have fixed it, at least I don’t get the error and it says the restore is done. I haven’t made any significant changes to be able to compare a before and after to be able to say that the backup was applied correctly, but the process is at least reporting success. Thanks for taking a look at this.
Simon
Will test tonight when I get home from work, Simon’s comments look promising!
100% working now, thanks for the quick fix. Created a back up, success! Restored a backup, success! 
When do you think the doc on the api for this will be available?
Available now: http://docs-local.appbond.com/#tag/Backup
(Sorry was an oversight that caused it not to be visible.)
I don’t see an option to dowload/upload the back info. This would be really handy so I wouldn’t have to reply on my phone’s backup/restore options (which aren’t granular enough to just get the bond backup).
Thanks for this. I finally moved over from the BD1000 to the pro since it was a simple backup and restore.
No such option exists at this time. We took the approach of first empowering users to make their own backups rather than rely on our cloud (reliable though it is 
). Perhaps we could support something in the future, but we want to first see how the local backup is used before going further. Currently we don’t have concrete plans to implement a cloud backup option.
Sounds reasonable. I’ll keep an eye on this thread in case it gets done at some point.
So I made a backup on 6/30 from a ZZ and tried to restore today on a Pro (firmware 2.21.0-beta) and got the expected “content length” error.
I went in and deleted the 3 devices from Pro so Pro has 0 devices.
Made a fresh backup from the ZZ (firmware now 2.20.14-beta) for 5 devices, long-pressed the old 6/30 backup and confirmed delete, then went to the Pro and hit restore, use a restore from a compatible Bond, selected the 7/21 backup … and the Pro is now unreachable, despite blue lights inside and LAN activity lights on ethernet port.
My Pro is PoE powered.
Unplugged ethernet to power cycle the Pro manually and the device is still unreachable in the Bond app.
Some pull-down refreshes later, the Bond app shows duplicates of all 5 devices from the ZZ Bridge - but device ID and associated Bridge for all of the pairs both show as ZZ and the Pro remains unreachable.
Force quit the app and relaunched - same issue remains.
ZZ Bridge shows 5 associated devices.
Pro remains Unreachable after sync attempts, but does show 5 Associated devices.
I have not wiped data or cache or power cycled anything further, in case any of this is of interest to the Bond team, @merck .
Thanks for the report. Will try to repro this setup today.
Update: Pro shows online now in the app (did nothing except wait to check until now).
However in the app, the duplicate devices still show same ID and Associated Bridge as ZZ.
Confirmed there are 5 devices each on ZZ (as expected) and Pro (so apparently the restore was a success) via API.
Suspect just an app bug as far as why the duplicate devices show as associated with ZZ.
Still a little odd about the restore seemingly knocking the PoE + Ethernet Pro offline / making the connection unstable for >15 minutes.
Note: I am both power and data over ethernet; I am not one of the PoE + WiFi folks. 
Ok, I’ve reproduced a problem here. It seems that Ethernet can slow down the database write performance. So, although the unit works normally under most circumstances, actions like deleting a whole device or performing a restore causes network instability and eventually rebooting of the Bridge. The Bridge then takes longer than normal (possibly 60 sec+) to come back if there’s many devices loaded.
I’m looking into the root cause… Will stay focused on this until it’s fixed, however, this will take a while to study. So far this has only been seen on BBP units connected to Ethernet, but I’ll update when we have more info.
Update: We’ve solved the database performance issue on BD-1750-PRO. This problem caused connectivity errors (or device reboots in extreme cases) when performing certain write-intensive operations such as creating or deleting template devices, and performing restores. This would only happen on Bridges that have seen heavy use (many devices created/deleted). — Firmware v2.21.0-beta should solve this performance problem.
There does seem to be another kind of Ethernet problem which we are still tracking down. It happens only in certain installs, so we are still trying to isolate the causes. Will provide updates as we know more.
UPDATE: We’ve solved a problem with Ethernet flow control that was causing lots of different problems with certain Ethernet switches, from intermittent performance issues isolated to the Bond Bridge Pro up to the whole switch hanging.
Firmware v2.21.4, currently available via Beta channel, fixes these problems. Specifically, I think it will fix the problem @residualimages reports.
We will just get some test mileage with this today and release to stable asap. Thanks for the reports on that.
Thank you so much for releasing the backup feature! I’m using an iPhone. This is awesome.
I’ve created a backup in the Bond app. The app shows that the backup was created successfully, but now I’m trying to download the backup file from my iPhone.
The backup file is not appearing in my iOS backups, when I browse using the “Files” app on the phone or when I browse the iCloud backups. The Bond app does not appear as one of the apps containing documents.
Has anyone been able to locate the Bond backup file on an iPhone?
Thanks,
Roy.
So, an update to my previous post. I still haven’t found a way to get the actual Bond backup file from iOS or Android without rooting my devices. I understand that when the Bond app is backed app as part of the phone / tablet backup, it’s data files containing any user backups should be part of it. It would be nice to have a download feature for a backup within the Bond iOS or Android app, so the actual backup file can be saved on the device in the user files.
So, next I tried the the backup API to initiate a backup, following:
http://docs-local.appbond.com/#tag/Backup/paths/~1v2~1sys~1backup/put
Using the following HTTP PUT request:
PUT http://192.168.1.15/v2/sys/backup
{
"host": "192.168.1.6",
"http_port": "80",
"path": "/snapshots",
"timestamp": "1618599782"
}
I getting the following response. I don't see any issues with my request:
{
"_error_id": 710,
"_error_msg": "please specify one operation (backup or restore)"
}
Has anyone had any luck using this API to initiate a backup?
“_error_msg”: “please specify one operation (backup or restore)”
Sorry, error in the documentation. — You need to add another field to your request: "backup": 1.
Has anyone been able to locate the Bond backup file on an iPhone?
We will check to see what it will take to expose this either in Files or iTunes. I agree that’s quite desirable to let you take ownership of the file.
Thank you for clarifying the missing field for the backup request!
So, now when I send the “put” to initiate the backup, I get a response right away with the new filename:
{
"backup": 1,
"filename": "ZZBL44158_v2.22.6-beta_1618599782_fa5166c4.bondbackup",
"progress": 1,
"_": "7e52bbf1"
}
But then I never see the backup file actually being sent to the destination server by the Bond device.
What mechanism is being used to send the actual backup file…is it HTTP PUT or POST?
I’ve setup an HTTP echo server to “receive” the backup file, and was expecting a subsequent HTTP call after requesting the backup containing the file, i.e. Base 64 encoded.
The documentation does not really describe what the “snapshot” server should expect when the backup is ready.
Also, thanks for looking into exposing the backup file in Files or iTunes!
Best Regards,
Roy.
What mechanism is being used to send the actual backup file…is it HTTP PUT or POST?
Sorry, we should improve these docs!
Upload is HTTP PUT, with Transfer-Encoding: chunked. Unfortunately however, many simple HTTP server implementations do not support chunked transfers. It’s a lesser-used part of the HTTP standard. It allows for the Bond to transfer chunks of specified size without having to precompute the full size of the file. This is why sometimes when you download a file in your web browser it says “x MB of unknown” and cannot give you a percent complete. We use chunked transfer because the firmware in the Bond doesn’t know the size of the upload until it is done building the backup file, and there’s not enough RAM or Flash to store the backup file anywhere in the worst case. Without chunked transfer, the Content-Length (size of the file) must be known ahead of time.
Not sure if this is helpful, but here’s a Python 3 implementation of a server supporting chunked transfer. I wrote this script as part of our internal test for the backup & restore feature:
from http.server import HTTPServer, SimpleHTTPRequestHandler
import time
from threading import Thread
from queue import Queue
Q = Queue()
class ChunkedRequestHandler(SimpleHTTPRequestHandler):
def do_PUT(self):
self.send_response(200)
self.end_headers()
path = self.translate_path(self.path)
if "Content-Length" in self.headers:
content_length = int(self.headers["Content-Length"])
body = self.rfile.read(content_length)
with open(path, "wb") as out_file:
out_file.write(body)
elif "chunked" in self.headers.get("Transfer-Encoding", ""):
with open(path, "wb") as out_file:
while True:
line = self.rfile.readline().strip()
chunk_length = int(line, 16)
if chunk_length != 0:
chunk = self.rfile.read(chunk_length)
out_file.write(chunk)
# Each chunk is followed by an additional empty newline
# that we have to consume.
self.rfile.readline()
# Finally, a chunk size of 0 is an end indication
if chunk_length == 0:
break
Q.put(path)
def start_daemon(port):
httpd = HTTPServer(("127.0.0.1", port), ChunkedRequestHandler)
print("Serving at port:", httpd.server_port)
Thread(target=httpd.serve_forever, daemon=True).start()
def wait_upload(timeout=None):
return Q.get(timeout=timeout)
if __name__ == "__main__":
start_daemon(4444)
while True:
time.sleep(1)