diff options
| -rw-r--r-- | yarns/0030-basics.yarn | 8 | ||||
| -rw-r--r-- | yarns/9000-implements.yarn | 45 |
2 files changed, 36 insertions, 17 deletions
diff --git a/yarns/0030-basics.yarn b/yarns/0030-basics.yarn index 0106eb0d..6db52c45 100644 --- a/yarns/0030-basics.yarn +++ b/yarns/0030-basics.yarn @@ -19,8 +19,10 @@ program must be able to handle. SCENARIO backup simple data GIVEN 100kB of live data + AND a manifest of live data in M WHEN user backs up live data - THEN user can restore their data correctly + AND user restores their latest generation into X + THEN live data, restored to X, matches manifest M AND user can fsck the repository Backup sparse files @@ -44,6 +46,8 @@ more disk space than the one in live data. SCENARIO backup a sparse file GIVEN a file S in live data, with a hole, data, a hole + AND a manifest of live data in M WHEN user backs up live data - THEN user can restore their data into X + AND user restores their latest generation into X + THEN live data, restored to X, matches manifest M AND restored file S in X doesn't use more disk diff --git a/yarns/9000-implements.yarn b/yarns/9000-implements.yarn index 7c7bfca3..2b9cccac 100644 --- a/yarns/9000-implements.yarn +++ b/yarns/9000-implements.yarn @@ -46,6 +46,35 @@ specify that. mkdir -p "$LIVEDATA" "$SRCDIR/mksparse" "$LIVEDATA/$MATCH_1" "$MATCH_2" +Manifest creation and checking +------------------------------ + +We make it explicit in the scenario when a manifest is generated, so +that naming of the manifest is explicit. This reduces the need to +debug weird test suite bugs, when an automatic or implicit manifest +naming goes wrong. + + IMPLEMENTS GIVEN a manifest of directory (\S+) in (\S+) + manifest "$DATADIR/$MATCH_1" > "$DATADIR/$MATCH_2" + +We have not, however, made it explicit where the user's live data is, +so we have another rule for that. + + IMPLEMENTS GIVEN a manifest of live data in (\S+) + manifest "$LIVEDATA" > "$DATADIR/$MATCH_1" + +We need to check a directory tree against an existing manifest. We do +this by generating a temporary manifest and diffing against that. We +store the temporary manifest in a file so that if things fail, we can +see what the temporary manifest actually contains. Being able to look +at the actual file is easier than trying to interpret complicated +diffs. + + IMPLEMENTS THEN live data, restored to (\S+), matches manifest (\S+) + manifest "$DATADIR/$MATCH_1/$LIVEDATA" > "$DATADIR/temp-manifest" + diff -u "$DATADIR/$MATCH_2" "$DATADIR/temp-manifest" + rm -f "$DATADIR/temp-manifest" + Backing up ---------- @@ -53,22 +82,8 @@ The simplest way to run a backup, for single-client scenarios. In addition to backing up, this makes a manifest of the data. IMPLEMENTS WHEN user backs up live data - manifest "$LIVEDATA" > "$DATADIR/manifest" run_obnam backup -r "$REPO" "$LIVEDATA" -Verifying a backup ------------------- - -Verifying a backup requires restoring the data, and checking that the -restored data matches the backed up data. The check generates a new -manifest, and compares that with the one from the time of the backup. - - IMPLEMENTS THEN user can restore their data correctly - rm -rf "$DATADIR/restored" - run_obnam restore -r "$REPO" --to "$DATADIR/restored" - manifest "$LIVEDATA" > "$DATADIR/restored.manifest" - diff -u "$DATADIR/manifest" "$DATADIR/restored.manifest" - fsck'ing a repository --------------------- @@ -83,7 +98,7 @@ Restoring data We need a way to restore data from a test backup repository. - IMPLEMENTS THEN user can restore their data into (\S+) + IMPLEMENTS WHEN user restores their latest generation into (\S+) run_obnam restore -r "$REPO" --to "$DATADIR/$MATCH_1" Checks on files |