summaryrefslogtreecommitdiff
path: root/yarns/0030-basics.yarn
blob: 0106eb0da4396c50f38711a057778095017d0fd9 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
Basic operation: backup and restore
===================================

This chapter tests the basic operation of Obnam: backing up and
restoring data. Tests in this chapter only concern themselves with a
single generation; see later for tests for multiple generations.

The goal of this chapter is to test Obnam with every kind of data,
every kind of file, and every kind of metadata.

Backup simple data
------------------

This is the simplest of all simple backup tests: generate a small
amount of data in regular files, in a single directory, and backup
that. No symlinks, no empty files, no extended attributes, no nothing.
Just a few files with a bit of data in each. This is what every backup
program must be able to handle.

    SCENARIO backup simple data
    GIVEN 100kB of live data
    WHEN user backs up live data
    THEN user can restore their data correctly
    AND user can fsck the repository

Backup sparse files
-------------------

Sparse files present an interesting challenge to backup programs. Most
people have none, but some people have lots, and theirs can have very
large holes. For example, at work I often generate disk images as
raw disk images in sparse files. The image may need to be, say 30
gigabytes in size, even though it only contains one or two gigabyte of
data. The rest is a hole.

A backup program should restore a sparse file as a sparse file.
Otherwise, the 30 gigabyte disk image file will, upon restore, use 30
gigabytes of disk space, rather than one. That might make restoring
impossible.

Unfortunately, it is not easy to (portably) check whether a file is
sparse. We'll settle for making sure the restored file does not use
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
    WHEN user backs up live data
    THEN user can restore their data into X
    AND restored file S in X doesn't use more disk