# \[Error-Duplicati.Library.Main.Operation.TestHandler-FailedToProcessFile\]: Failed to process file duplicati-20200105T000000Z.dlist.zip
**URL:** https://forum.duplicati.com/t/error-duplicati-library-main-operation-testhandler-failedtoprocessfile-failed-to-process-file-duplicati-20200105t000000z-dlist-zip/9140
**Category:** Support
**Created:** [February 9, 2020, 8:14pm UTC](https://forum.duplicati.com/t/error-duplicati-library-main-operation-testhandler-failedtoprocessfile-failed-to-process-file-duplicati-20200105t000000z-dlist-zip/9140 "2020-02-09T20:14:11Z")
**Posts on this page:** 1
**Showing post:** 10
### Author:  [@ts678](https://forum.duplicati.com/u/ts678)
#### Post date: [March 10, 2020, 1:04am UTC](https://forum.duplicati.com/t/error-duplicati-library-main-operation-testhandler-failedtoprocessfile-failed-to-process-file-duplicati-20200105t000000z-dlist-zip/9140/10 "2020-03-10T01:04:35Z")
> [@Tom\_van\_Dijken](#):
>
> because the backup looks fine
The dlist files are not ordinarily used for Restore, because their information (and dindex info) is in a database. If that database is damaged or its drive breaks, the dlist file is needed to get that version.
Figuring out what this is is probably worthwhile, but you have to get more details than the summary.
> [@ts678](#):
>
> Try watching the action with live log at About → Show log → Live → Retry, otherwise the one line summary is pretty useless because the error details are on the lines below it that you didn’t see…
If you see an interesting looking error message, try clicking on it. Sometimes it will expand with detail.
> [@drwtsn32](#):
>
> Sounds like the testing portion (which is done at the end of a backup job) is failing.
[Verifying backend files](https://duplicati.readthedocs.io/en/latest/03-using-the-graphical-user-interface/#verifying-backend-files) is the testing that was referred to.
> At the end of each backup job, Duplicati checks the integrity by downloading a few files from the backend. The contents of these file is checked against what Duplicati expects it to be.
[–backup-test-samples](https://duplicati.readthedocs.io/en/latest/06-advanced-options/#backup-test-samples)
> `--backup-test-samples = 1`
> After a backup is completed, some files are selected for verification on the remote backend. Use this option to change how many.
[The TEST command](https://duplicati.readthedocs.io/en/latest/04-using-duplicati-from-the-command-line/#the-test-command) is a more technical description of it:
> Verifies integrity of a backup. A random sample of dlist, dindex, dblock files is downloaded, decrypted and the content is checked against recorded size values and data hashes. `` specifies the number of samples to be tested. If “all” is specified, all files in the backup will be tested. This is a rolling check, i.e. when executed another time different samples are verified than in the first run. A sample consists of 1 dlist, 1 dindex, 1 dblock.
So by default there will often be three files tested, but they wouldn’t all be dlist (and not the same dlist).
Are these completely independent backups, meaning two Duplicati jobs, one to SATA, one to Dropbox? Generally I’d expect SATA to be quite reliable. Network destinations are more likely to have file damage.
Another odd thing is that seeing a `duplicati-20200105T000000Z.dlist.zip` error on both would say both backups ran at the same time, and that doesn’t happen. Or is this some sort of a sync to Dropbox?
---
_[View the full topic](https://forum.duplicati.com/t/error-duplicati-library-main-operation-testhandler-failedtoprocessfile-failed-to-process-file-duplicati-20200105t000000z-dlist-zip/9140)._