2025-01-31 BorgBackup for the laptop and the server
A few days ago I mentioned the rsync-based backup script I use to copy data from the server to the laptop.
The backup script that makes backups of my laptop (including the backup from the server) to external disks is different, however.
My actual backup uses external disks. I have two of them. One of them is always at the office. Every now and then (not often enough!) I make a backup to the external disk I have at hand and then I carry it to the office and bring the other one back. That is, the laptop and the two external disks are never in the same location.
The two external disks I use are "known backup disks". When I plug them in, BorgBackup immediately starts making a backup. I discussed this setup back in 2017.
I'm just going to repost the stuff and I don't think there have been any significant changes.
Run commands and create files as root.
Either use `sudo` for every command you run, or use `sudo su` once and do everything as root. No matter how you do it, the danger zone awaits!
`/mnt/backup`
Create the mount point on the laptop:
`/etc/fstab`
Any disk labeled “Backup” will be mounted as `/mnt/backup`:
`/etc/backups/40-backup.rules`
Install a symlink to this file:
The file content:
This makes sure that the service `automatic-backup` starts whenever an external disk gets plugged into the laptop.
`/etc/backups/automatic-backup.service`
Install a symlink to this file:
The service does nothing except start the `run.sh` shell script.
`/etc/backups/backup.disks`
The `run.sh` below runs for every external disk plugged in. It's important to only make backups to known backup disks, however.
The known backup disks are identified by their `uuid` in the `backup.disks` file.
To list the disk labels and their `uuid`:
Add the `uuid` to the `/etc/backups/backup.disks` file.
This is the content of the file identifying my backup disks, for example:
If you create your copy of the file, your uuids will be different!
When you run `lsblk -o+uuid,label` you'll also see the device itself. In my case, that's `/dev/sdb`. Create a BorgBackup repository on the new disk, mount it, create the directory and initialize the repository.
When initializing the repository, you're asked for a passphrase. You will need it for the `run.sh` script.
Make sure the disk has the correct label! You can do this from the command-line but I used Disks.
`/etc/backups/run.sh`
Now we're ready for the actual script. It checks whether a known backup disk is mounted under `/mnt/backup` and if so, it creates a new archive in the repository.
Don’t forget to search for `BORG_PASSPHRASE` and change it to whatever you used when you ran `borg init` above!
Hide the passphrase from everybody else and make it executable:
This the content of the shell script:
Check the logs!
Check the log while the backup is being written:
Make sure the backup disk is identified correctly and look at the sizes of the archives. If they're too small, check whether the archives contain the right files!
​#Backup ​#Administration
**2025-02-04**. A reader sent me an email saying: “you may want to call `borg compact` after `borg prune` in order to actually free up the disk space corresponding to the pruned archives. Otherwise your backup repo will keep growing in size.”
Good point. At first I thought that in my case it would not matter because surely Borg would reuse the space. But not so, as I found out a few weeks later (see below). I amended the `run.sh` script.
**2025-06-01**. Hm, something still doesn't work. When I plug the disk into the second laptop, nothing happens. It's as if the udev rule doesn't get consulted. When I run `sudo systemctl start automatic-backup.service` the backup gets written.
**2025-07-11**. Oh, found it. The link from `/etc/udev/rules.d/40-backup.rules` → `/etc/backups/40-backup.rules` was there and the file `/etc/backups/40-backup-rules` existed.
Did you notice the typo? Today I renamed `40-backup-rules` to `40-backup.rules`. That fixed the issue.
**2025-08-16**. I recently upgraded from Debian Bookworm (12) to Trixie (13). And I ran out of disk space!
`df -h` reports:
So now:
Let's see if that frees up some space. Otherwise, I'll have to reduce the number of archives kept.
New:
Well done! 7% reclaimed is enough. I have amended my `run.sh` script.
**2025-12-29**. I was running out of disk space again and decided to only keep 2 daily, 2 weekly and 2 monthly backups. With the current regime of 7 daily, 4 weekly and 6 monthly backups on two independent disks, my backups went back to 2022. That is too much.