I get a “FATAL Chunk [ID] can’t be found” error every time I try to restore a file. I’ve tried multiple snapshots and several different files. I manually verified that the chunks in questions are there and accessible from the computer. (Using a local network folder for the repository.) Using v 2.0.6
What should I check next?
If the storage is a local/network drive or an SFTP server, Duplicacy expects a hierarchical chunk directory (chunk abcdef… will be under the subdirectory ab/cd). For all other types of storages, the chunk directory is flat and there are no subdirectories.
The ‘Chunk can’t be found’ error usually is a result of copying the chunk directory between storages of different types. Did see a flat chunk directory or a hierarchical one from the local network folder?
I see a hierarchical file structure for sure. The data has not been moved since it was backed up. Subsequent snapshots have gone off fine, so it appears to be finding the chunks when it backs up.
Can you turn on verbose logging and send me the log? Send to duplicacy-support@acrosync.com if you don’t want to post here.
Will do. It takes like 4-5 hrs to populate the restore file list, so it will be a while. (800K files and 16 TB in the repository)
A much faster way would be to run the CLI version in the DOS prompt (assuming you’re running Windows).
The 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 users.
First create and initialize the directory to be restored:
mkdir c:/temp/restore
cd c:/temp/restore
duplicacy_win_x64_2.0.6.exe init repository_id storage_url
repository_id can be found in the GUI version – it is the first one shown in the Repository ID dropdown box under the Restore tab.
You can then restore files using this command:
duplicacy_win_x64_2.0.6.exe -d restore -r revision files
For anyone else who encountered the same chunk not found error (while the chunk file does exist), this is a go bug with the os.Stat() call when the storage directory is on a Windows disk that has the data deduplication option enabled: https://github.com/golang/go/issues/10935
The fix has been checked in to the github branch and should be included in version 2.0.7.