yes but what is tested here is the backend, not the local disk. The error message just above is reporting rightly about the wrong file on the backend, while this one is failing to say where is the real problem.
the first part of my answer was not correct, I was fooled by a misleading error message.
The second part about not backing up temp files and Duplicati own files is correct but may be irrelevant to your problem.
although I had a boost from moderator power which let me get original source before forum interprets (attempting to āhelpā by tweak double quotes into different forms, interpreting special characters, etc.).
The pretty form looks reasonable, not because it improved the details but because it didnāt show them
Yes the destination file is tested, but done by downloading to a temporary file (canāt hash remotely).
The human-friendly display doesnāt highlight the internal working, but the complete log JSON does.
One problem with the good-for-troubleshooting enhancement 2.0.7.100 Canary which stores more information about the details of a problem (in addition to the summary) is that it reveals more detail.
Intentionally corrupting the one dblock in a tiny backup and using Verify files now logs like this:
and the error showed up in Verification section, while my attempt at viewing userās error put it lower.
Iām not worrying about it right now though. There are other differences, e.g. Iām not encrypting here.
OK. Here is the completed file test results.
The link is to a large file sharing site called wetransfer.com. Itās safe.
I donāt get it, the passphrase is not valid. If you have a running backup and you use the command line from the Web UI, the passphrase is preset, did you remove it ?
I used the same passphrase to encrypt files that I did before I reformatted the hard drive and reinstalled duplicati. It was custom. The UI flow asked me to assign a passphrase. So I did.
Itās presented as a question (but is a good one).
There seem to be 349 bad files, almost all 50 MB dblock files, only 3 the small dindex files for them.
One of the posted logs said 721 files were uploaded. Thereās a dindex per dblock, and a dlist at end.
This makes an estimated 720 / 2 = 360 50 MB dblock files, which is 18 GB, which is āalmostā all of it.
Whatās odd is that a password mismatch would also kill the small dindex files, but they seem to work.
How remote? Sounds like over the Internet. Any known potentially error-inducing networking in there? Breaking large files and leaving small ones more likely to survive is the kind of thing networks can do.
Odd thing is that the initial upload seemed pretty clean.
Duplicati.CommandLine.BackendTester.exe in a Command Prompt (is this Windows?) can run a test. Export As Command-line can give a URL, but you need to edit it so it uses an empty Synology folder.
Is there another way into Synology, e.g. SFTP? We might wind up wanting more reliable file transfers.
did you enter a value in the field above filled by dots ? itās a marker for the current passphrase, you should not touch it.
I guess weāll hear what response is. Itās not clear to me what the problem is, but a passphrase error should kill all the files. Even in early report, the verification of dlist and dindex worked, dblock didnāt.
duplicati-b8d4e45575ba545c1b0c87091cc6fccb7.dblock.zip.aes failed, but not on its retest.
Mountain Duck does SFTP. Can that be used to get the file reliably so that it can be integrity-tested?
Or try some other failing dblock file on the new list, or one of its 3 dindex files, or a not-failing dindex.
Remote being over the internet through WEBDAV. I donāt think the network is causing errors there. Sometimes the location loses power, but then when that happens the backup just plain does not run.
This is a Windows PC.
" Duplicati.CommandLine.BackendTester.exe in a Command Prompt (is this Windows?) can run a test. Export As Command-line can give a URL, but you need to edit it so it uses an empty Synology folder."
What do you want me to do with the above quoted text? I donāt understand.
There may be a way to connect to Synology other than WEBDAV. I need to look into it.
I didnāt touch the passphrase field. When I mentioned assigning a passphrase, it was in reference to setting up the backup itself, in the configuration page.
I can look into this. Do you mean connect the Storj drive to Mountain duck using something other than an Amazon S3 connection? Or the connection from that Mountain Duck network folder to the synology backup destination?
EDIT: I turned on SFTP on the synology unit. Tried to test the connection to Duplicati in the edit configuration page for the backup. The connection failed. I used port 22.
This with SFTP. Or if you use its related product Cyberduck, that should also be able to do SFTP.
As this is Windows, do you use Command Prompt at all? If not, it takes more explaining, but if so
C:\Program Files\Duplicati 2>Duplicati.CommandLine.BackendTester
Usage: <protocol>://<username>:<password>@<path>
Example: ftp://user:pass@server/folder
but in your case the URL-like item after the command name comes from job Export as I mentioned.
Alternatively, go to Destination screen for three-dot menu Copy Destination URL to clipboard.
Remember that, either way, you should edit it to an empty Synology folder, otherwise it wonāt test it.
I tried to set up SFTP in duplicati, linking the Mountain Duck/Storj network drive with the Synology backup destination. It didnāt work. I couldnāt get the two to talk to one another over the network. Not like with the WEBDAV. That, when testing the connection, confirms right away. But it also may be the cause of the problem.
I use the CMD very very infrequently. Sorry.
EDIT: How do I know what my server name is in the SFTP setup in Duplicati? The same as the one I used with WEBDAV?
How to Open Command Prompt (Windows 11, 10, 8, 7, etc.) is sample directions. Web has lots.
Once open, type cd C:\Program Files\Duplicati 2 to get to the Duplicati installation folder.
Use link Duplicati.CommandLine.BackendTester.exe for all directions, but basically the one thing
required is the URL that tells it where to go test. The other options can be ignored for initial tests.
For Synology, I donāt know whatās turned on by default. Do you have a way to check the settings?
I donāt understand why in this case you can do a backup using this setup (can you now ?) but not doing a test using the same web interface and the same job. Baffling.
I can do a backup, but there is the resulting error we are trying to solve.
SFTP at Synology says how to enable it.
Itās strange how files seem to upload quite nicely, but are seemingly corrupted when they come back.
The test tool will perhaps confirm that thereās a problem somewhere, and if need be, thereās also tool
Duplicati.CommandLine.BackendTool.exe for manual use. And weāre trying to get some SFTP going.
Yes but in this post your Duplicati is successfully decoding all files but one, while in your test attempt all files are failing to decode. Thatās not coherent, you must be doing something different but I canāt imagine what it is.
Itās not all unless the log is wrong. Itās almost all of the dblock, and a few dindex. The dlist survives.
Was Duplicati in use before? Was it working well then? Was it the same backup plan to Synology?
What happened to old backup? If itās still there, itās āknown goodā. Are Windows versions 10 or 11?
Did you select the Use SSL box? This would be wise unless network is trusted (distrust Internet).
SSL refers to the encryption that https:// web pages also use. Exact version change over time.
Already the industry has gone from SSL to TLS, and latest TLS version 1.3 sometimes has bugs. Switching to Windows 11 from Windows 10 could reveal them, as thatās when Windows changed.
This would not affect SFTP, and there might be a workaround for WebDAV, but first letās see if the Windows version allows the failure to be possible. Windows 10 would not by default use TLS 1.3.
If files are truncated, I would have hoped Duplicati would complain of that first, but maybe it wonāt. Manual download that can show the problem might leave a non-temporary file to look at furtherā¦