You are not logged in.
Hi everyone! First post here.
I recently installed Arch Linux on my new laptop and I'm trying to set up regular backups. I'm pretty new to this, though, so I would love advice on my planned setup. Here's what I'm thinking:
---
1. Full system backups on external hard drive
It seems like it would be a good idea to have a full bootable backup on an external device. I figure this is mostly useful if my laptop hardware gets damaged.
- Question A: Is this a mistake? Would it make more sense to have separate backups for the files vs. the whole system? Or, instead of backing up the whole system, should I only back up specific data about the system (package lists, config files, etc.) and assume I can rebuild the rest in an install?
I'm using LVM on my laptop, so it seems like I can set up partitions on my external hard drive to match those I'm backing up and make an rsync script which I could regularly use to copy my whole filesystem over. The Arch Wiki has specific instructions about copying boot partitions with LVM so I figure I can just follow those to make my external drive bootable.
- Question B: Does what I'm describing make sense? I.e. is rsync the right tool to use, am I missing any major steps, should I be making a compressed backup instead?
---
2. Temporary backups with on-device LVM snapshot
I'm shakier on this concept, but from what I've read on the Arch Wiki and elsewhere, it seems like LVM snapshots are useful for quick rollbacks. As I understand it, I would write a script to make a snapshot every time I boot. If I make changes which break my system in some way, I can revert to the old version (since all those files are still on the original decide). Otherwise, if the changes are stable, I would merge the snapshot with the original device.
- Question C: Is this a reasonable use of LVM snapshots, or am I off base? Is any of my terminology wrong?
To do this, it seems like I need to make a new block device for those snapshots and set up a script to make a new snapshot on startup (as well as figuring out how to revert from and merge snapshots).
- Question D: Is that about right, or will setup require something different?
I also had a question (Question E) about something the wiki says. From https://wiki.archlinux.org/title/LVM#Snapshots
(3.2: Backups) : "A snapshot provides a frozen copy of a file system to make backups. For example, a backup taking two hours provides a more consistent image of the file system than directly backing up the partition.
The snapshot can be mounted and backed up with dd or tar. The size of the backup file done with dd will be the size of the files residing on the snapshot volume. To restore just create a snapshot, mount it, and write or extract the backup to it. And then merge it with the origin. "
I'm confused, because it seems like this is saying that backing up a snapshot only gives you the files on the snapshot itself--the diff, in other words. But that isn't a full system backup, right? So wouldn't you need to back up the system some other way? And why is backing up from a snapshot better than from the partition directly? I don't understand what that passage is saying about a snapshot being a "frozen copy" because I thought snapshots just had pointers to the existing data.
---
Question F: are there any other types of backups I'm not considering? Is there a strong argument for setting up cloud backup for my files as well?
I'll keep googling to try and figure out the answers, but in the meantime, if anybody has an answer to any of those questions I would really appreciate hearing it!
Offline
I only bother backing up data and configs. Installing Arch is pretty painless, so I see no need to back up the entire system.
I backup daily to a server in my garage, and also use tarsnap for periodic snapshots to AWS. My desktop and server are both LUKS/LVM/Raid 1 and, despite several disk failures over the last decade or so, I have yet to lose a single byte of data (*touches wood*).
Backups, both local and tarsnap, have saved my bacon a couple of times over that period when I deleted something inadvertently.
FWIW, I assume that if there is going to be a failure, it will be catastrophic; local backups make no sense. Go hard, or live with your regrets.
Offline
@jasonwran Thanks for the quick reply! One (super basic) question:
I backup daily to a server in my garage, and also use tarsnap for periodic snapshots to AWS.
What programs do you use for the server backups? Is there one to copy the files and other to compress them, or do you back them up uncompressed?
Offline
I just use rsync: I'm not concerned about space.
Offline
I have a spinning drive attached to my router set up as a NAS. I use Rsync to backup /home on both my systems to it weekly. Monthly, I physically swap that drive with another that I keep in my desk at work (including verifying the volume on a different computer before it goes in the drawer). I buy a new drive every year and swap each drive out after two years. Retired drives are thrown in a box in the shed.
I also keep a fair amount of stuff in Google's offerings (mail, photos, and some things in Drive) -- But I don't consider those to be a proper backup. Legal documents (estate, trust, insurance, investment) along with passwords and account recovery information have been provided to interested parties.
If things go pear shaped, I will happily rebuild my install and reload files from backups. As to configurations -- I get better every time I need to re do them.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
The shortest way to ruin a country is to give power to demagogues.— Dionysius of Halicarnassus
---
How to Ask Questions the Smart Way
Offline
Note that there are different goals of backups and each goal is best met with different strategies which I'd break into the categories of data archiving and stupid-mistake-mitigation.
The local snapshot approach is absolutely pointless for archiving important data against hardware failure, house fire, or similar disaster. However, while I don't do local snapshots, I have occasionally wished I did as it is an excellent approach for dealing with "oh s*** I just deleted the wrong file" moments which I've had a few of (and when that file was not yet on a real backup and / or was never destined to be kept around long but was still needed a few minutes longer). So snapshots can save your tail when you make foolish mistake.
Data archiving must be on a totally different device, and some would argue in a completely different location - otherwise it's just not really meeting the goal it is meant to achieve.
So the first question, is which of these flavors of protection do you need? For my purposes, I archive important data files and really nothing else. As JWR noted, reinstalling arch is pretty trivial if it comes to it. I don't even need to maintain a package list as I know what I want installed on top of a base system. Config files don't get specifically archived either but this is primarily because I tend to use very similar configs on multiple systems - so if one system fails, I can grab the configs from another one of my machines and perhaps just do a little minor tweaking.
As for my backup tools / strategy ... I could really do better. I don't have a consistent approach, but rather end up relying on what I'd call data-promiscuity. Important data tends to get copied to several machines / servers I run, so just like the above-mentioned config files, if disaster happens, I'll be able to find the needed data somewhere. This is certainly error-prone and not advisable; it's not a very deliberate or planned strategy - but it is quite easy for me.
Last edited by Trilby (2023-03-02 17:43:14)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
For the last 6 years, I have happily used Borg backup + local Arch ARM Raspberry Pi NAS + rclone to extremely cheap remote B2 storage, as I described here.
Offline
Thank you all for the thoughtful responses! This will help a ton.
Offline