Merge lp:~mterry/deja-dup/verify into lp:deja-dup/24
Status: | Merged |
---|---|
Merged at revision: | 1378 |
Proposed branch: | lp:~mterry/deja-dup/verify |
Merge into: | lp:deja-dup/24 |
Diff against target: |
700 lines (+274/-43) 22 files modified
common/Makefile.am (+5/-1) common/Operation.vala (+53/-5) common/OperationBackup.vala (+50/-5) common/OperationRestore.vala (+3/-8) common/OperationVerify.vala (+85/-0) common/RecursiveDelete.vala (+4/-1) common/RecursiveMove.vala (+4/-1) common/RecursiveOp.vala (+4/-1) po/POTFILES.in (+4/-3) po/POTFILES.skip (+4/-3) tests/runner/runner.vala (+12/-2) tests/scripts/bad-hostname.test (+1/-1) tests/scripts/clean-incomplete.test (+1/-1) tests/scripts/encrypt-ask.test (+13/-1) tests/scripts/encrypt-regex.test (+12/-1) tests/scripts/read-error.test (+1/-1) tests/scripts/threshold-full.test (+1/-1) tests/scripts/threshold-inc.test (+1/-1) tests/scripts/verify.test (+10/-0) tools/duplicity/DuplicityInstance.vala (+4/-1) tools/duplicity/DuplicityJob.vala (+1/-1) tools/duplicity/Makefile.am (+1/-4) |
To merge this branch: | bzr merge lp:~mterry/deja-dup/verify |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Robert Bruce Park (community) | Approve | ||
Ken VanDine | Pending | ||
Review via email: mp+119176@code.launchpad.net |
Description of the change
This branch does two things:
1) Every backup now also backs up a file created by Deja Dup: ~/.cache/
This folder can be safely deleted.
@SECONDS_
Where obviously, @SECONDS_
Intentionally, part of it is always the same (the safely deleted part) and part of it is always different. This means duplicity will always back it up, so it will be present in every backup. And the part that is the same can be sanity-checked.
It doesn't matter if the user sets their cache directory in some weird place, since we always currently use this file right after a backup, so the cache directory will be in the same place we expect it.
2) After each backup, we restore this file and sanity check it. This will have to download one volume from each incremental backup since the start. The idea is to test that the backup can be restored if needed. This isn't 100% foolproof, but will test for a lot of different problems.
The next step in this plan (and a different branch altogether) will be to add logic that every now and then tries to restore without using saved knowledge like the user's encryption password or duplicity cached data, to really test that the user remembers enough to restore if needed.
Looks good, all tests pass, backup and restore both function.