I have quite a large backup of around 750GB in total, which could take sometime to restore (I’ve not tried to restore the whole thing yet as a test). My question is what would happen if the restore process is interrupted (internet drops/machine reboots)? Would you need to re-initiate the restore manually? Would you need to work out yourself what was restored successfully already and whether or not to start the restore from scratch again overwriting everything? Thanks
You need to restart the restore again. If you choose to overwrite the destination files, Duplicati will pre-scan the files and figure out what is missing. It will then only do the work that it did not do the last time.
If you do not choose overwrite, it will create a new file with a timestamp in the name, for the files that exist but are not of the correct version.
1 Like
Is it safe to assume the restore of individual files is “transactional” such that if the interruption is hard (say a power outage) half-restored files will either:
- not be moved into the final restore destination OR
- be recognized as half-restored (as part of the pre-scan?) and replaced with a full restore of the file?
No, I estimated that there would not be enough storage to have all the partial files elsewhere. You can restore to an empty folder and choose “overwrite” to get the same functionality.
1 Like
How about you restore the file to a temporary file in the destination (ex: temp{GUID}.duplicati) then rename/move it to the extraction target only once complete. This way you use no extra storage on the target and if you keep the temp file in the root hopefully you can avoid issues with blowing through the target FS maximum path length. The alternative would be to let the user specify a temp folder for extractions, and put the temp file in that, which would probably be better since it can avoid max path length issues.
That being said, the simple solution is to just give proper user feedback. If a restore operation is interrupted, let the logs show which file was interrupted so the user can rectify the situation manually. At a later stage an even better solution would be to track the restore operation in the DB so that interrupted restores can be gracefully resumed. As someone who has suffered through CrashPlan’s terrible handling of this scenario I can see the value in such a solution…
1 Like
That sounds like a good idea to me, though there are edge cases that need to be handled such has what happens when something like a restore of backup #5 gets interrupted and before it can be resumed backup #5 ages out of the history.
Well in that case the restore operation would simply fail whenever it resumes. I get what you mean, such cases and similar might need explicit checks.
For this very specific edge case I was thinking more along the lines of a message saying “The backup you were trying to restore has aged out of the history. Would you like to start over with the next available backup?”.
Either way the database saved “this file has been restored” flags would have to be re-set. And of course there’s the issue that if the user does NOT re-start the restore from the next available backup they’re working with a half-restored set of files. Ick.