I've long been putting this project off, but I have finally started on it.
My goal is to do all this automatically;
I will be doing this on my both server and my desktop, but developing and testing on my desktop. I rarely write scripts well enough to be "transportable" to other systems, so if you want to use any of these you'll need to edit.
"Bootstrapping" your system:
The scripts will require running as root and that your BTRFS root filesystem is mounted so the subvolumes can be accessed. Fortunately this part is simple.
Mounting your root BTRFS filesystem;
Make a target folder (I use /subvol). Edit fstab, copy the line that mounts your root file system, delete the subvolume reference, and mount at the new location. Here's mine for an example;
Notice I added the "auto" option to the /subvol mount. This mounts /subvol at boot time. The "/" mount doesn't need the auto option because it has to be mounted to boot.
If you would prefer to not mount /subvol at boot and would rather have the script mount it when needed, don't use "auto". You could allow the script to do the whole mounting process, but I find defining it in fstab to be easier to control the mount.
TIP: In my opinion, having your BTRFS root file system mounted (or mountable) at a specific location is a good practice. This allows easier access to your subvolumes so you can do maintenance or random snapshots when needed. If you want this access but still don't want it mounted at boot time, add the "user" option so you can mount and umount it without "sudo".
A backup location;
We'll be using BTRFS send|receive to make these backups. You will need to have a BTRFS backup location either on another drive on your PC, a removable drive, or a networked location. I do not recommend using a separate partition on the same drive as that wouldn't be much of a backup.
I have a desktop PC and a server so my scripts will use a local drive and a networked drive for backups. If you wish to use a removable device such as a thumb drive or USB drive, it is recommended to use BTRFS send to a file and copy the file to the USB device rather than formatting the USB device to BTRFS. The reason is USB devices can too easily drop off during a long access process and if this happens during a BTRFS receive operation the backup can be incomplete and you may not get a warning that this has occurred, whereas a simple file copy operation will handle a momentary pause with much better chance of success. If anyone is interested in how using a USB device this way might be done, ask and I will expand on it.
Automation;
To ensure the scripts run, I use anacron and cron for script launch.
Installing anacron will ensure these tasks are run if the computer not available during the specified times. I'm not going to explain cron or anacron here, but if you're unsure of how they work, I encourage you to read up on them.
Finally, I have several installs on my single btrfs file system so I can multi-boot. To do this (topic of another post) I have renamed my subvolumes from the defaults of "@" and "@home" and you will see this in my scripts. I also run stand-alone grub from a subvolume as well. Most of these will be included in my snapshot and backup routines.
On to the scripts. I will post them separately and only once I've tested them fully. Remember these are designed to work on my setup so modifications will be needed if you are considering adapt them to your system. I welcome input about anything in the scripts that might make them better, faster, or more robust.
My goal is to do all this automatically;
- Make a daily snapshot of any/all subvolumes and keep a rotating seven days' worth.
- Make a weekly backup and keep the last two.
- Keep a monthly backup for three months.
I will be doing this on my both server and my desktop, but developing and testing on my desktop. I rarely write scripts well enough to be "transportable" to other systems, so if you want to use any of these you'll need to edit.
"Bootstrapping" your system:
The scripts will require running as root and that your BTRFS root filesystem is mounted so the subvolumes can be accessed. Fortunately this part is simple.
Mounting your root BTRFS filesystem;
Make a target folder (I use /subvol). Edit fstab, copy the line that mounts your root file system, delete the subvolume reference, and mount at the new location. Here's mine for an example;
Code:
UUID=60834933-1e99-4d5c-922c-9abbc373e172 / btrfs rw,noatime,space_cache,compress=lzo,autodefrag,subvol=@ 0 1 UUID=60834933-1e99-4d5c-922c-9abbc373e172 /subvol btrfs rw,auto,noatime,space_cache,compress=lzo,autodefrag 0 0
If you would prefer to not mount /subvol at boot and would rather have the script mount it when needed, don't use "auto". You could allow the script to do the whole mounting process, but I find defining it in fstab to be easier to control the mount.
TIP: In my opinion, having your BTRFS root file system mounted (or mountable) at a specific location is a good practice. This allows easier access to your subvolumes so you can do maintenance or random snapshots when needed. If you want this access but still don't want it mounted at boot time, add the "user" option so you can mount and umount it without "sudo".
A backup location;
We'll be using BTRFS send|receive to make these backups. You will need to have a BTRFS backup location either on another drive on your PC, a removable drive, or a networked location. I do not recommend using a separate partition on the same drive as that wouldn't be much of a backup.
I have a desktop PC and a server so my scripts will use a local drive and a networked drive for backups. If you wish to use a removable device such as a thumb drive or USB drive, it is recommended to use BTRFS send to a file and copy the file to the USB device rather than formatting the USB device to BTRFS. The reason is USB devices can too easily drop off during a long access process and if this happens during a BTRFS receive operation the backup can be incomplete and you may not get a warning that this has occurred, whereas a simple file copy operation will handle a momentary pause with much better chance of success. If anyone is interested in how using a USB device this way might be done, ask and I will expand on it.
Automation;
To ensure the scripts run, I use anacron and cron for script launch.
- cron.daily will run the snapshot script - task #1.
- cron.weekly will run task #2
- cron.monthly will run task #3
Installing anacron will ensure these tasks are run if the computer not available during the specified times. I'm not going to explain cron or anacron here, but if you're unsure of how they work, I encourage you to read up on them.
Finally, I have several installs on my single btrfs file system so I can multi-boot. To do this (topic of another post) I have renamed my subvolumes from the defaults of "@" and "@home" and you will see this in my scripts. I also run stand-alone grub from a subvolume as well. Most of these will be included in my snapshot and backup routines.
On to the scripts. I will post them separately and only once I've tested them fully. Remember these are designed to work on my setup so modifications will be needed if you are considering adapt them to your system. I welcome input about anything in the scripts that might make them better, faster, or more robust.
Comment