Backups¶

Practical 4.6 backups-annex.pdf · PDF

Think of one thing on your phone or laptop you would hate to lose. Your photos, a project, a game save. Now count: how many copies of it exist, and where? If the answer is "one, right here", it is not a question of if you lose it. It is a question of when.

In RAID is not a backup you learned what a backup must be: a copy from another moment, in another place, that you have already restored. Today you make one with your own hands for Tramuntana Apps, break the original on purpose, and get it back.

The 3-2-1 rule¶

In 2005 a photographer, Peter Krogh, wrote a book about keeping digital photos safe for a whole career: The DAM Book (DAM for Digital Asset Management, nothing to do with your course). In it he gave a rule that fits on one hand, and system administrators adopted it:

For Tramuntana Apps:

flowchart LR
    subgraph OFFICE["In the office"]
        C1["<b>Copy 1</b><br>~/tramuntana-share<br>the original, system disk"]
        C2["<b>Copy 2</b><br>another disk<br>mounted on /mnt/backup"]
    end
    C3["<b>Copy 3</b><br>outside the office<br>needs the network (Units 3 and 6)"]
    C1 -->|"today: tar and rsync"| C2
    C1 -.->|"later in the course"| C3

Prepare the backup disk¶

You reuse one of the empty 1 GiB disks from LVM and RAID. This is all from the last few days: partition, file system, mount point, mount.

lsblk
sudo parted -s /dev/vdc mklabel gpt \
  mkpart backup ext4 1MiB 100%
sudo mkfs.ext4 -L backup /dev/vdc1
sudo mkdir /mnt/backup
sudo mount /dev/vdc1 /mnt/backup
sudo chown $USER: /mnt/backup
df -h /mnt/backup

If mkfs asks Proceed anyway? (y,N), it found the old file system from the LVM practical on this disk: answer y. Then df -h /mnt/backup must show your new partition (/dev/vdc1, about 988M), not the system disk. If it shows the system disk, your "backup" is on the same disk as the original.

/mnt/backup is deliberately not in /etc/fstab: it plays the role of an external disk you connect to make the copy.

A full backup with tar¶

tar (from tape archive) packs a whole folder into one file. Three letters do almost everything:

tar -czf ARCHIVE FOLDER     # c = create   z = compress with gzip   f = into this file
tar -tzf ARCHIVE            # t = list what is inside
tar -xzf ARCHIVE WHAT       # x = extract (everything, or only WHAT)

Make the backup and look inside it:

cd ~
ls -lh tramuntana-share/design/old
tar -czf /mnt/backup/wed-full.tgz tramuntana-share
ls -lh /mnt/backup
tar -tzf /mnt/backup/wed-full.tgz

The fake promo-video.mp4 is 20M, and yet the archive of the whole folder is about 25K. Is it incomplete? No: tar -tzf lists every file. That video is 20 MB of nothing but zeros, the most repetitive data there is, and the rest is short text. Repetitive data shrinks enormously; real video and photos hardly shrink at all.

Disaster and restore¶

Pau cleans the wrong folder:

rm -r tramuntana-share/admin
ls tramuntana-share

Aina calls you. Bring back only her folder from the archive:

tar -xzf /mnt/backup/wed-full.tgz \
  tramuntana-share/admin
ls tramuntana-share/admin

invoices, staff.csv and wifi.txt are back. Aina was without her folder for about a minute, because the copy was on another disk and you knew the command. If you mistype the path, tar says Not found in archive and extracts nothing.

Full, incremental, differential¶

Your full backup is tiny. The real projects folder of a studio is 100 GB. A full copy every night means 700 GB a week, and hours of copying, to save the two files that changed. There are smarter ways.

Think of a diary. A full backup is the whole diary photocopied. An incremental backup is "what happened today". A differential backup is "everything that happened since Sunday", rewritten every night.

Work it out with numbers. Full backup on Sunday night: 100 GB. Every working day, 2 GB of files are new or changed (different files each day).

Now Wednesday's archive cannot be read. With incrementals you can only get back to Tuesday night: the chain is broken, and Thursday's archive alone is not enough. With differentials there is no problem: Thursday's archive holds everything since Sunday.

tar can make incrementals with a small notebook file (-g) where it writes what it already saved:

tar -czf /mnt/backup/mon-full.tgz -g /mnt/backup/week.snar tramuntana-share
echo 'Invoice 2026-006' > tramuntana-share/admin/invoices/2026/invoice-2026-006.txt
tar -czf /mnt/backup/tue-incr.tgz -g /mnt/backup/week.snar tramuntana-share
tar -tzf /mnt/backup/tue-incr.tgz

The full archive is about 25,800 bytes; the incremental is about 785, and its list shows the folders and only one file: the new invoice.

rsync: copy only what changed¶

In 1996, in Australia, Andrew Tridgell and Paul Mackerras announced rsync. The idea: before copying, compare both sides and send only the differences. Tridgell is also the author of Samba, the file server you will install later in the course.

sudo apt install rsync
rsync -av tramuntana-share/ /mnt/backup/mirror/
rsync -av tramuntana-share/ /mnt/backup/mirror/

-a (archive) copies folders inside folders, with dates and owners; -v (verbose) says what it does. The first run lists every file. The second run lists no files at all: nothing changed, so almost nothing is sent.

Change two files and sync again:

cd ~/tramuntana-share
echo 'new client' > admin/client-new.txt
echo 'v2' > design/logos/icon.svg
cd ~
rsync -av tramuntana-share/ /mnt/backup/mirror/

Only admin/client-new.txt and design/logos/icon.svg travel.

--delete, and why you look first¶

--delete makes the copy identical: files that no longer exist in the original are deleted in the copy too. Always look first with --dry-run, which shows what would happen and does nothing.

rm tramuntana-share/admin/wifi.txt
rsync -av --delete --dry-run \
  tramuntana-share/ /mnt/backup/mirror/

deleting admin/wifi.txt
...
(DRY RUN)

ls /mnt/backup/mirror/admin still shows wifi.txt: nothing was done. Run it without --dry-run and wifi.txt is gone from the mirror too. Where can you get it back? From the old tar archive:

tar -xzf /mnt/backup/wed-full.tgz \
  tramuntana-share/admin/wifi.txt

Prove it¶

A restore you have not checked is a guess. Extract the whole archive into an empty folder (-C means "extract into that folder") and compare it with the live data:

mkdir ~/rtest
tar -xzf /mnt/backup/wed-full.tgz -C ~/rtest
diff -rq ~/rtest/tramuntana-share tramuntana-share

diff -rq compares two folders recursively (-r) and only says which files differ (-q, quiet):

Only in tramuntana-share/admin: client-new.txt
Files /home/student/rtest/tramuntana-share/design/logos/icon.svg and tramuntana-share/design/logos/icon.svg differ

That is exactly the work done after the backup. If the system disk died now, Tramuntana would lose the new client and the new logo.

So which is the good backup? The mirror lost wifi.txt. The old archive does not have the new client. Neither alone: you want new and old at once, without storing 100 GB every night. That is the tool of the next page. All the steps, with space for your evidence, are on the Practical 4.6 sheet.

Key takeaways¶

• The 3-2-1 rule: three copies, on two kinds of storage, one in another place.
• tar -czf creates a compressed archive, tar -tzf lists it, tar -xzf extracts all of it or only one path.
• Incremental = since the last backup of any kind (small, delicate chain). Differential = since the last full (grows, needs only two archives).
• rsync copies only what changed; --delete makes the copy identical, so check first with --dry-run.
• A mirror has one moment in time: it repeats your deletions. A backup keeps old versions.
• diff -rq proves a restore by listing every difference with the live data.

Quick check¶

You had to choose between a fresh mirror with no past and an old archive with no present. Next, one program that gives you both, in the space of one: restic and the restore drill.