How to check backup (increment) integrity?
Is there any way to check integrity of backup files?
I don't mean verification with comparison to original files.
I mean integrity test without touching source folder, i.e check whether any backup file is corrupted.
The only way that came to my mind is restore with --dry-run but it'll check the whole backup and may last for ages.
How to check integrity of certain increment? Is there any possibility?
Question information
- Language:
- English Edit question
- Status:
- Solved
- For:
- Duplicity Edit question
- Assignee:
- No assignee Edit question
- Solved by:
- ardabro
- Solved:
- 2017-09-20
- Last query:
- 2017-09-20
- Last reply:
- 2017-09-15
| edso (ed.so) said : | #1 |
On 9/12/2017 22:58, ardabro wrote:
> New question #657939 on Duplicity:
> https:/
>
> Is there any way to check integrity of backup files?
> I don't mean verification with comparison to original files.
verify does not compare to the source files since some time unless you give he --compare-data parameter.
> I mean integrity test without touching source folder, i.e check whether any backup file is corrupted.
> The only way that came to my mind is restore with --dry-run but it'll check the whole backup and may last for ages.
> How to check integrity of certain increment? Is there any possibility?
no. as increments depend on earlier backups all those will be used as well. from the man page
"
verify [--compare-data] [--time <time>] [--file-to-restore <rel_path>] <url> <local_path>
Restore backup contents temporarily file by file and compare against the local path’s contents. duplicity will exit with a non-zero error level if any files are different. On verbosity level info (4) or higher, a message for each file that has changed will be logged.
The --file-to-restore option restricts verify to that file or folder. The --time option allows to select a backup to verify against. The --compare-data option enables data comparison (see below).
"
it should be updated that data comparison is not the default anymore although the local_path is still obligatory. somebody needs to find the time to clean that out
.
..ede/duply.net
| ardabro (ardabro) said : | #2 |
Ok, but this doen't answer my question. I don't want to check backup contents. I want to check compressed and encrypted files integrity, without accessing source folder.
| edso (ed.so) said : | #3 |
you can!
using a recent duplicity it will ignore <local_path> (whule still needed) and simply check if the backup is restorable.. ede/duply.net
| ardabro (ardabro) said : | #4 |
The necessity of giving fake-source path for verification is very confusing idea but OK. Thanks
| edso (ed.so) said : | #5 |
On 9/20/2017 22:34, ardabro wrote:
> Question #657939 on Duplicity changed:
> https:/
>
> Status: Answered => Solved
>
> ardabro confirmed that the question is solved:
> The necessity of giving fake-source path for verification is very
> confusing idea but OK. Thanks
>
it's legacy. previously the restored files meta data was _always_ compared to the local source, hence the need for the parameter.
as i wrote, somebody needs to take care of it. nobody did so far.
..ede/duply.net
