ubuntu 18.04 server btrfs backup

ubuntu 18.04 server btrfs backup

ubuntu 18.04 hw2018 server backup btrfs snapper

While writing the previous posts, I lied. Backup are OK at home, but not on my virtual server that I use for writing this blog.

So while growing my RAID, I removed one disk from the array using mdadm and I physically removed the other. That one that was expected to stay in the array…

So I had a look at all my post about the server and I have redone the full install.


Those tools have been especially designed to play well with snapper.

buttersink Unusable.

Works but because of issue #50 about wrong orders of snapshots, btrfs can not benefit of the CoW feature, and thus use a lot of space. Unusable.

snapsync Unusable.

sudo /opt/snapsync/bin/snapsync auto-sync
/opt/snapsync/bundle/ruby/2.5.0/gems/ruby-dbus-0.11.2/lib/dbus/marshall.rb:301: warning: constant ::Fixnum is deprecated
Traceback (most recent call last):
	10: from /opt/snapsync/bin/snapsync:14:in `<main>'
	 9: from /opt/snapsync/bin/snapsync:14:in `load'
	 8: from /opt/snapsync/bundle/ruby/2.5.0/gems/snapsync-0.3.8/bin/snapsync:4:in `<top (required)>'
	 7: from /opt/snapsync/bundle/ruby/2.5.0/gems/thor-0.19.4/lib/thor/base.rb:444:in `start'
	 6: from /opt/snapsync/bundle/ruby/2.5.0/gems/thor-0.19.4/lib/thor.rb:369:in `dispatch'
	 5: from /opt/snapsync/bundle/ruby/2.5.0/gems/thor-0.19.4/lib/thor/invocation.rb:126:in `invoke_command'
	 4: from /opt/snapsync/bundle/ruby/2.5.0/gems/thor-0.19.4/lib/thor/command.rb:27:in `run'
	 3: from /opt/snapsync/bundle/ruby/2.5.0/gems/snapsync-0.3.8/lib/snapsync/cli.rb:296:in `auto_sync'
	 2: from /opt/snapsync/bundle/ruby/2.5.0/gems/snapsync-0.3.8/lib/snapsync/auto_sync.rb:29:in `load_config'
	 1: from /opt/snapsync/bundle/ruby/2.5.0/gems/snapsync-0.3.8/lib/snapsync/auto_sync.rb:29:in `read'
/opt/snapsync/bundle/ruby/2.5.0/gems/snapsync-0.3.8/lib/snapsync/auto_sync.rb:29:in `read': No such file or directory @ rb_sysopen - /etc/snapsync.conf (Errno::ENOENT)

snap-sync untested

My last candidate. It should test it some day, but in the meantime, I will take a real backup using the good old rsync.

My own backup script

First backup

Take an empty disk, then create one partition on it:

sudo apt-get install gdisk
sudo sgdisk -Z /dev/vdg
sudo sgdisk -p /dev/vdg
sudo sgdisk -n1 /dev/vdg

Create a btrfs filesystem on it, with the backup-1 label :

sudo mkfs.btrfs /dev/vdg1 -L backup-1

Get my backup script and config file from github:

wget https://raw.githubusercontent.com/RandomReaper/scripts/master/backup/backup.sh
wget https://raw.githubusercontent.com/RandomReaper/scripts/master/backup/backup.cfg.sample-local
mv backup.cfg.sample-local backup.cfg
chmod +x backup.sh
sudo mkdir -p /mnt/backup

Edit the cfg file to match the server and disk:


Run the backup:

sudo ./backup.sh
Backup start : 2018-06-26 13:32:42 DESTINATION_DIR:/mnt/backup
mounting /dev/disk/by-label/backup-1
backup /
backup /var/log
backup /home
backup /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/vdg1       8.0G  2.6G  4.9G  35% /mnt/backup
unmounting /dev/disk/by-label/backup-1
Backup end : 2018-06-26 13:33:20

Done in 38 seconds (thanks to the SSDs), but the next run should be faster :

sudo ./backup.sh
1742 (process ID) old priority 0, new priority 19
Backup start : 2018-06-26 13:33:24 DESTINATION_DIR:/mnt/backup
mounting /dev/disk/by-label/backup-1
backup /
backup /var/log
backup /home
backup /boot
Filesystem      Size  Used Avail Use% Mounted on
/dev/vdg1       8.0G  2.8G  4.7G  38% /mnt/backup
unmounting /dev/disk/by-label/backup-1
Backup end : 2018-06-26 13:33:28

4 seconds!


Question, remark, bug? Don't hesitate to contact me or report a bug.