пятница, 27 июня 2014 г.

stat command - for telling directories from mount points/subvolumes

Cool way to find out if directory is a mount point and thus subvolume

if the argument is equal to the output - we have a mountpoint/subvolume

$ stat --format=%m /usr/src/linux
/usr/src

BTRFS send/receive

BTRFS send/receive may fail in between, leaving the partially completed backup. Although, this can be covered by sending subsequent snapshots and they (if succeeded) would be ok, this failed one will still be corrupt and we should remove it as soon as the backup volume is online.

The procedure to mark the snapshots transferred successfully - is to touch the .success file in the snapshot directoty (close to info.xml). If there is a snapshot directory, but no .success file - we should run the send/receive again.

btrfs subvolume and snapshot notes

BTRFS has a subvolume feature - allows to logically create subvolumes (file systems) within a BTRFS storage pool.
Every subvolume is like a normal filesystem, however it has a default mount path.

r9-008cln ~ # btrfs subv list /mnt/root
ID 620 gen 895 top level 5 path home
ID 621 gen 921 top level 620 path home/.snapshots
ID 622 gen 950 top level 621 path home/.snapshots/1/snapshot
I've got 3 subvolumes here. they are listed as a flat list, however, by default they can be accessed in the directory tree under paths indicated.

When snapper is configured on the volume (home in my example above), it creates one more subvolume .snapshots and puts the default mount just under the managed volume: home/.snapshots.

This .snapshots subvolume holds snapper's directory and xml files with additional information about every snapshot snapper creates.

Subvolumes are really like separate filesystems. The tools like find and rsync have flags to stay within 1 filesystem. Using those flags will keep them within 1 subvolume. Cool!

I'll use rsync to move all snapper directories and xml files to backup volume.


fast backup of my notebook - contains gigabytes of audio/video/photo and VM images

Problem:

  • full backup (close to 1 TB) takes over 5 hours
  • no history (due to limited storage) 
Solution:
  • btrfs + snapper
  • hourly snapshots
  • snapshots before/after install/update of packages (via emerge hooks)
Challenge
  • automated incremental backup of snapper snapshots
  • automated retirement of backup snapshots following the main system snapper retirement
  • automated restore to a fresh volume in case of disaster