DanielH Oct 18 9:09PM 2017 GUI
Hi, i was just wondering what would be the procedure to restore a full backup after a system crash?
gchen Oct 19 11:13AM 2017
For the GUI version, you can create an empty directory on another computer as the repository and then select the same storage. Under the restore tab you can click list revisions and select the repository id of the original repository and then you will be able to list all files in the original repository and select them to restore.
You can also restore using the CLI version by running the following commands:
mkdir -p path/to/restore/to
cd path/to/restore/to
duplicacy init repository_id storage_url
duplicacy restore -r n # n is the revision number that you want to restore
For the init command you need the repository id of the original repository. You can find it out by listing the snapshots directory in the storage.
Timo Dec 2 10:49AM 2017
I got into the same situation to restore after a full crash, but unfortunately it does not work as intended! I really need my backup now...
I tried the process with the GUI as you described but "List revisions" and "List files" results in nothing.
The verbose log looks fine until this line: "16:45:57.853 id: , revisions: [], tag: , showFiles: false, showChunks: false"
Please help me, I don't wont to mess around with my precious backup...
gchen Dec 2 2:12PM 2017
You can always use the CLI version to restore:
mkdir -p path/to/restore/to
cd path/to/restore/to
duplicacy init repository_id storage_url
duplicacy restore -r n # n is the revision number that you want to restore
On Windows, the Duplicacy CLI executable can be found under either C:\Program Files (x86)\Duplicacy or C:\Users\username\AppData\Local\Duplicacy, depending on if you installed Duplicacy for all users or for the current user only.
On macOS, the Duplicacy CLI executable is usually under /Applications/Duplicacy.app/Contents/Resources.
The repository_id can be found under the snapshots directory on the storage.
Timo Dec 3 5:48AM 2017
Thanks for your fast reply, but it didn't get my any further unfortunately.
E.g., I get this:
D:\Restore>C:\Users\Timo\AppData\Local\Duplicacy\duplicacy_win_x64_2.0.9.exe -v list -a
Storage set to N:\Duplicacy
Listing all snapshot ids
D:\Restore>
With correct ID pre-entered:
D:\Restore>C:\Users\Timo\AppData\Local\Duplicacy\duplicacy_win_x64_2.0.9.exe -v list -id TIMO-LENOVO-Timo-SymLinks
Storage set to N:\Duplicacy
Listing revisions for snapshot TIMO-LENOVO-Timo-SymLinks
D:\Restore>
My chunks and snapshots folders are not empty...
Please advise me how to access my backup :'(
gchen Dec 3 10:03AM 2017
Are there any files under n:\Duplicacy\snapshots\TIMO-LENOVO-Timo-SymLinks?
Timo Dec 4 12:06PM 2017
Yes, 21 files in \snapshots\TIMO-LENOVO-Timo-SymLinks: 1, 22, 33, 42, 52, 53, 60-74
And another 39 files in my wife's backup snapshot - none of both backups is detected by Duplicacy.
gchen Dec 4 3:20PM 2017
Is TIMO-LENOVO-Timo-SymLinks a symbolic link? What is the output of dir N:\Duplicacy\snapshots /a?
Timo Dec 5 12:04PM 2017
It's not a symbolic link. Duplicacy was backing up a folder called SymLinks which includes 4 symbolic links to folders and the .duplicacy folder.
Output is:
N:\Duplicacy\snapshots>dir N:\Duplicacy\snapshots /a
Datenträger in Laufwerk N: ist Sicherung I
Volumeseriennummer: 3F77-A7C4
Verzeichnis von N:\Duplicacy\snapshots
03.09.2017 15:19 <DIR> .
03.09.2017 09:22 <DIR> ..
24.10.2017 21:12 <DIR> TIMO-LENOVO-Timo-SymLinks
26.10.2017 15:34 <DIR> HYEONAES-TABLET-hyeon-Symlinks
0 Datei(en), 0 Bytes
4 Verzeichnis(se), 1.052.060.123.136 Bytes frei
N:\Duplicacy\snapshots>
gchen Dec 5 3:39PM 2017
Can you try this version: https://acrosync.com/duplicacy/duplicacy_win_x64_2.1.0.exe?
Run the list command as:
duplicacy_win_x64_2.1.0.exe -d list -a
It will print out files/directories while listing the snapshots directory.
Timo Dec 6 12:39PM 2017
Looks like this:
D:\Restore>C:\Users\Timo\AppData\Local\Duplicacy\duplicacy_win_x64_2.1.0.exe -d list -a
Storage set to N:\Duplicacy
Reading the environment variable DUPLICACY_PASSWORD
Reading password from keychain/keyring
Using a static salt and 16384 iterations for key derivation
Chunk read levels: [2 3], write level: 2
Compression level: 100
Average chunk size: 4194304
Maximum chunk size: 16777216
Minimum chunk size: 1048576
Chunk seed: 36a44ef1d058a5e57096fc226fbdaa9bb7c4acafd6fa82fec8542ef34dc1e9b3
Reading the environment variable DUPLICACY_PASSWORD
id: , revisions: [], tag: , showFiles: false, showChunks: false
Listing all snapshot ids
D:\Restore>
Any idea?
gchen Dec 6 11:16PM 2017
Can you try this build: https://acrosync.com/duplicacy/duplicacy_win_x64_2.1.0a.exe?
I suspect it was the extra slash at the end of the path that caused the issue. This 2.1.0a build removes the extra slash.
Timo Dec 8 12:56PM 2017
Thanks for you continuous support!
I think you almost nailed it:
D:\Restore>C:\Users\Timo\AppData\Local\Duplicacy\duplicacy_win_x64_2.1.0a.exe -d list -a
Storage set to N:\Duplicacy
Reading the environment variable DUPLICACY_PASSWORD
Reading password from keychain/keyring
Using a static salt and 16384 iterations for key derivation
Chunk read levels: [2 3], write level: 2
Compression level: 100
Average chunk size: 4194304
Maximum chunk size: 16777216
Minimum chunk size: 1048576
Chunk seed: 36a44ef1d058a5e57096fc226fbdaa9bb7c4acafd6fa82fec8542ef34dc1e9b3
Reading the environment variable DUPLICACY_PASSWORD
id: , revisions: [], tag: , showFiles: false, showChunks: false
Listing all snapshot ids
Listing N:\Duplicacy/snapshots error: Readdir N:\Duplicacy/snapshots: Das System kann den angegebenen Pfad nicht finden.
D:\Restore>
Looks like there still is a problem with the slashes \ vs. /
gchen Dec 8 9:42PM 2017
I can get you a new build that converts / to \, but according to the Windows doc, / is a valid path separator.
What kind of drive is this N: is? A local disk or a networked drive?
Timo Dec 9 6:57AM 2017
N: is a 2TB USB3.0 HDD now directly attached to my laptop. The file system is ext4 as it was connected to a Raspberry Pi for shared network backup via SFTP.
gchen Dec 9 12:09PM 2017
Windows doesn't seem to support ext4 natively. What software do you use to mount the drive?
Timo Dec 10 8:54AM 2017
Full-licensed versions of Paragon ExtFS for Windows and since yesterday Linux File Systems for Windows by Paragon Software
CheckMate Dec 10 8:59AM 2017
You can install Ubuntu in Virtualbox, directly connect your external drive to Ubuntu, and run the Linux version of Duplicacy to do the restore.
gchen Dec 10 11:16PM 2017
This build should work better: https://acrosync.com/duplicacy/duplicacy_win_x64_2.1.0b.exe
Timo Dec 11 3:35PM 2017
Thanks, but output looks again like version 2.1.0:
D:\Restore>C:\Users\Timo\AppData\Local\Duplicacy\duplicacy_win_x64_2.1.0b.exe -d list -a
Storage set to N:\Duplicacy
Reading the environment variable DUPLICACY_PASSWORD
Reading password from keychain/keyring
Using a static salt and 16384 iterations for key derivation
Chunk read levels: [2 3], write level: 2
Compression level: 100
Average chunk size: 4194304
Maximum chunk size: 16777216
Minimum chunk size: 1048576
Chunk seed: 36a44ef1d058a5e57096fc226fbdaa9bb7c4acafd6fa82fec8542ef34dc1e9b3
Reading the environment variable DUPLICACY_PASSWORD
id: , revisions: [], tag: , showFiles: false, showChunks: false
Listing all snapshot ids
D:\Restore>
Will try the Ubuntu restore later!
Timo Dec 12 2:30PM 2017
OK, got it to list all snapshots and revisions with Ubuntu! :-)
After discovering the latest revision number with Duplicacy under Ubuntu, I was finally able to start the restore under Windows by using the latest Duplicacy CLI build 2.1.0b and entering the correct revision number!
Any idea why Duplicacy CLI is working but not the GUI and not the "list" command?
Timo Dec 13 12:18PM 2017
Quick update: I was able to restore 30GB out of 927GB until I run into missing chunks, e.g.
G:\Restore>C:\Users\Timo\AppData\Local\Duplicacy\duplicacy_win_x64_2.1.0b.exe restore -overwrite -r 74
Storage set to N:\Duplicacy
Restoring G:\Restore to revision 74
Chunk 434548aa7855f2bb3e36d6355acc901918f077e602fdd45e29652317a84c6f89 can't be found
G:\Restore>
Tried different revisions for restore but that 30GB is all I've got out of my backup.
-> Any tips before I give up on my Duplicacy backup?
gchen Dec 13 2:01PM 2017
Does that file exist under N:\Duplicacy\chunks? The full path should be N:\Duplicacy\chunks\43\4348aa... if it exists.
If the file is there, it could be an issue with Paragon's ext4 disk driver (especially consider that Duplicacy can't even list N:\Duplicacy\snapshots properly with the standard API call). Can you try restoring file using Ubuntu just as how you did with the list command?
Timo Dec 15 12:48PM 2017
No luck either, chunk is not there...
timo@timo-VirtualBox:/media/timo/Volume/Restore$ ~/Downloads/duplicacy_linux_x64_2.0.10 restore -overwrite -r 74
Storage set to /media/timo/Sicherung I/Duplicacy
Restoring /media/timo/Volume/Restore to revision 74
Chunk 434548aa7855f2bb3e36d6355acc901918f077e602fdd45e29652317a84c6f89 can't be found
timo@timo-VirtualBox:/media/timo/Volume/Restore$
gchen Dec 16 9:41AM 2017
The check command can report which chunks are missing:
~/Downloads/duplicacy_linux_x64_2.0.10 check -r 74
If the missing chunks don't exist on the storage and it is likely that a prune command deleted them with the -exclusive option while there were ongoing backups. The prune logs are kept under the .duplicacy/logs directory and you'll be able to find out when they are deleted.
If you never ran a prune command before then I had no clue why they are missing.
kevinvinv Dec 16 10:02AM 2017
This one has me a bit worried. Can I ask a question about this?
Does duplicacy somehow verify that all chunks are present on the storage when a backup is complete? Should I be running a check command after backup and prune to be sure?
Next question,
If a chunk somehow disappears on the storage- will it get re-uploaded at the next backup?
Final question to the OP,
Can you go back a couple snapshots and get a complete restore?
gchen Dec 16 3:56PM 2017
No, the backup command doesn't verify that all chunks are present before it is complete. A prune command with the -exclusive option may remove some chunks before the snapshot file is uploaded as the last step of the backup command. Therefore, if you can't absolutely exclude the possibility of a prune -exclusive command you should run the check command.
If a chunk somehow disappears on the storage- will it get re-uploaded at the next backup?
Only if you run backup -hash, otherwise Duplicacy will always assume that all chunks referenced by the last snapshot exist.
Timo Dec 16 4:47PM 2017
3 chunks are missing in total starting from my 2nd oldest revision 22 up to the latest revision 74. Revision 1 is fine - trying to recover now. I had the "Prune snapshots after first backup" checkbox enabled in the GUI though...
Can you implement the -hash option into the GUI please, make Duplicacy more fail-proof? Finding out the hard way is quite unsatisfactory as you can imagine... :-(
I don't care much about speed, I care about my data.
kevinvinv Dec 16 5:22PM 2017
Couple more questions"
A prune command with the -exclusive option may remove some chunks before the snapshot file is uploaded as the last step of the backup command.
This would only happen if multiple concurrent operations are happening to the same storage ... is that correct? If I am the only user backing up to a particular storage- then would this ever happen?
And lets say that we run the -check command to be sure of no missing chunks... If I find a missing chunk- what do we do then to get those chunks re-established? I guess you probably answered this... the only way to do this is run backup -hash? Is that right?
I feel a little concerned about this. Can you help me become a little less so? :)
gchen Dec 16 5:43PM 2017
This would only happen if multiple concurrent operations are happening to the same storage ... is that correct? If I am the only user backing up to a particular storage- then would this ever happen?
This would only happen if multiple concurrent operations are happening to the same storage AND you run the prune command with the -exclusive option. You can run the prune command without the -exclusive option if there are multiple concurrent operations to the same storage.
The key here is the -exclusive option. It assumes the exclusive access to the storage so by definition you can't have another backup that is in progress.
If you find a missing chunk, then first make sure it doesn't exist in the storage. If it does exist then it is a different issue. Then check the prune logs under the .duplicacy/logs directory to see when the chunk was removed. This is to confirm this isn't a Duplicacy bug. If it was deleted accidentally (due to the use of the -exclusive option), then run duplicacy backup -hash hoping it may be able to recreate the same chunk. However, if the on-disk files already changed then you may not be able to recreate it.
kevinvinv Dec 16 6:09PM 2017
Thank you very much This makes sense.
But lets say I want to be sure that my most recent backup is good.... regardless of any corruption that may have happened on the storage previously... what do I have to do.. run the backup with -hash?
kevinvinv Dec 16 6:59PM 2017
Also- reading the documentation on -hash -- I dont quite understand how that accomplishes what we want. Can you explain just a bit please?
THANK YOU!
gchen Dec 16 10:37PM 2017
Run duplicacy check -r revision is probably enough under most circumstances, but if you are worried about the reliability of the storage then duplicacy check -r revision -files, which basically downloads every file to verify they have the right hashes and thus may take a long time.
The -hash option rescans all the files in the repository without checking if they have been changed. In doing so they will blindly attempt to upload every chunk it creates, but skip the upload if the chunk already exists. Therefore it may have a chance to recreate a missing chunk.
kevinvinv Dec 16 11:13PM 2017
ok thanks.
I guess I dont understand really what to do about this.
I went to my storage and deleted one chunk file deliberately.
Then I ran the check command and verified that duplicacy reports a missing chunk.
Now I want to "fix" the problem.... so I tried to do a backup command with the -hash option... but it seems like the newly created snapshot is still missing the chunk... so the -hash didnt really solve the problem.
I guess I am thinking of periodically running the check command and maybe with -files ... BUT I dont know what to do if I find a missing chunk... somehow there needs to be a way to "heal" the backup snapshot.
Thoughts?
Timo Dec 17 4:04AM 2017
Yes, my thoughts are that I can't relay on Duplicacy unfortunately. And when it comes to backups I need something 100% bulletproof. Duplicacy should consistently check its chunks. I never run a prune -exclusive command... maybe some chunks got lost in the upload process to my server or due to faulty sectors on the HDD or whatever. But this should be detected and repaired by an automatic backup, otherwise I could copy the files by hand, as Duplicacy's repair functionality seems to be carried out manually by the user and maybe - as I read your discussion - is unsuccessful anyway.
Long story short, thank you very much for your support @gchen but may I ask for a (partial) refund for my two licenses, as I'm not going to use Duplicacy any longer... Thanks!
kevinvinv Dec 17 10:42AM 2017
Hi Timo,
I have struggled with this one and have sort of convinced myself it is a medium level problem in some sense. For example- it seems to me that while some backup solutions do continually monitor the backup integrity (crashplan and others) - many dont (Time Machine, acronis, most personal-level tools)... do you think I am right about this?
It further indicates the need for multiple backup solutions.
I for one, dont want to use the duplicacy copy function for this sort of reason- rather I am using duplicacy to backup to two storages completely independently (rather than backing up the backup)...
And I'll still run time machine
What I am worried about though are some of my family members who now rely on me for backups (duplicacy) and dont seem to be as obsessed with this sort of thing as I am... until they need the data... and then I feel bad if there is a problem and they didnt follow my direction to use a 2nd backup too as well :) -- so I still am a little stressed about this... and not sure what to do :)
gchen Dec 17 2:15PM 2017
Timo, I issued the full refund of your two licenses on stripe.com and you should be able to see it on your credit card statement in a couple of days. If you don't, please let me know.
Sorry to lose you as a customer, but I should clarify that it is possible to check chunks automatically after each backup -- we just don't make this the default. You can create a post-backup script that runs the check command to make sure that every chunk just uploaded does exist. This will catch any missing chunk error much earlier.
In most cases when users reported missing chunks, the cause was always the misuse of the -exclusive option (for example here and here. However, in your case I tend to believe it is the issue of the Paragon ext4 driver, mostly because of the weird listing bug. If so, then it would have been caught by the post-backup check script.
On how to recover from missing chunks -- sorry I was wrong on the use of the -hash option. I forgot that the -hash option still assumes that the chunks referenced by last snapshot all exist. The correct way is run the backup command with a different repository id (by editing the .duplicacy/preferences file). After the repairing backup command you can change the repository id back to the original one. Then you can remove the snapshot file snapshots/temporary_id/1 from the storage. If no files changed before this repairing backup command then no unreferenced chunks will be generated by this operation.
It should be noted that repairing missing chunks isn't guaranteed to work every time. If some files have changed then it will be impossible to regenerate the missing chunks. To be able to recover from missing chunks under any circumstances requires the error correction technique, which incurs significant overhead on most storage systems that can be reasonably trusted. If you're really worried about this issue, then you should back up to multiple storages.
Kevinvinv, I disagree with you on the reason that the copy function should be avoided. If you back up to two storages independently and some files changed between these two backups then you will not get the same set of chunks on different storages. So when one chunk is missing on one storage you can't grab it from the other storage. Another advantage of the copy function is that you can use third-party tools like rsync/rclone to copy chunks between storages.
kevinvinv Dec 18 8:23AM 2017
HI Gchen, thanks for this thorough response.
I had a question- can one determine if all the chunks are available (like the -check command) without using a password? In other words, is the storage password really required to verify the presence of all the chunks?
I would like to do something server-side for all my users but dont want to have their passwords on file.
gchen Dec 18 8:31PM 2017
Unfortunately you need the encryption keys to derive the file names of chunks, so the answer is no.
kevinvinv Dec 19 9:31AM 2017
Thanks.
Also- to me it seems that an acceptable recovery method when one finds a missing chunk is to re-upload the entire backup. I agree that replacing a missing chunk is pretty difficult since source files will no-doubt have changed.
Detecting the situation reliably is the main concern I have at the moment. Recovering from it can be dealt with ... but knowing one needs to recover is the first step! :)