OS Backup - what should and what should not be backup'd?
Hello there! Here's the thing: I got some old HDD for my Debian home server, and now that I have plenty of disk space I want to keep a backup of the OS, so that if something accidentally breaks (either SW or HW) I can quickly fix it.
now the question is: which directory should I include and which should I exclude from the backup? I use docker a lot, is there any docker-specific directory that I should back up?
like this
SheeEttin
in reply to tubbadu • • •If you need to restore it, back it up.
How do you plan to restore if the whole drive dies?
tubbadu
in reply to SheeEttin • • •thanks for the reply!
good point: I guess if the problem is that I messed something up I may just run the backup script in reverse? if the problem is HW then I'd have to reinstall and then restore the backupped directory probably
is there a "standard" way?
CocaineShrimp
in reply to tubbadu • • •I usually only keep documents and media. Programs can be redownloaded and reinstalled (and it might be better to reinstall them in case you move to a new OS anyway to ensure compatibility).
For docker specifically, only keep stuff that's specific for your instance; which you normally setup as an external volume anyway. Docker is designed such that you should be able to nuke the container, and all persistent data is restored via an external volume on the host. If you're not doing that, you should immediately go and set that up now (to get the data out safely, setup a volume connection such that the container path is new - that way you don't accidentally destroy what's there, copy the stuff you need out, then readjust the path so it's correct)
tubbadu
in reply to CocaineShrimp • • •andrewd18
in reply to tubbadu • • •Björn Tantau
in reply to tubbadu • • •I back up all user data, for me that's some folders in
/var
, all of/etc
(don't need everything, but it's small enough), mysqldumps and pgsqldumps of my databases and the output ofdpkg --get-selections
. And the backup script itself.Everything is rsynced to a server in another location.
I want to switch to Borg backup but haven't found the time yet.
TurboLag
in reply to Björn Tantau • • •backup.sh
script and the configuration is really straight-forward.borgmatic
torsion.orgtubbadu
in reply to TurboLag • • •Cricket [he/him]
in reply to Björn Tantau • • •Since you haven't switched yet, perhaps consider restic too. I looked into Borg when I was trying to decide which backup software to use, but ended up deciding on restic instead and using resticprofile to ease implementation.
resticprofile
resticprofileMangoPenguin
in reply to tubbadu • • •tubbadu
in reply to MangoPenguin • • •wouldn't this take a lot of time? but I can see the advantage, being able to just roll back whatever happened
I'll think about it, thank you very much!
MangoPenguin
in reply to tubbadu • • •utopiah
in reply to tubbadu • • •Why? I have a hard time imagine a use case where restoring the OS itself would be appropriate.
I can imagine restoring data, obviously, and services running with their personalization ... but the OS is something generic that should be discarded at whim IMHO. You probably chance few basic configuration of some services and most likely that's stored in
/etc
but even then 99% is default.You can identify what you modified via shell history, e.g.
history | grep /etc
and potentially save them or you can also usefind /etc -type f -newerXY
with a date later than the OS installation and you should find what you modified. That's probably just a few files.If you do back up anything beyond
/home
(which should be on another partition or even disk than the OS anyway) you'll most likely save garbage like/dev
that might actually hinder your ability to restore.So... sure, image the OS if you actually have a good reason for it but unless you work on archiving and restoring legacy hardware for a museum then I doubt you do need that.
DigitalDilemma
in reply to tubbadu • • •You need to make your own plan about what's important to you. Don't waste time backing up stuff you can quickly download again - like docker images. Just know where the stuff is that you care about (such as any mounted volumes in docker with your own data on) and back that up, and make everything automated. If you do it manually, chances are you'll gradually stop doing them.
I wrote some things about properly backing up data that may be of use.
Backing Up Important Data :: Digital Dilemma
Digital DilemmaMatt
in reply to DigitalDilemma • • •Maybe try setting up a local Gitea instance with a Docker registry.
poinck
in reply to tubbadu • • •I have used a combination of rsync and borg to backup to an external drive. Then I was feeling adventurous and tried borgbackup2. It was a mistake. Then I learned of rdiff-backup. Easy to setup, but even incremental backups of my home dir took many hours to complete. This is no solution to have regular backups for me.
I decided to go with btrfs snapshots instead. I recently reinstalled everything and I have finally btrfs. I bought a new external NVME drive for my backups where all the snapshots will go. Btrfs has even a parent-option to copy incremental snapshots to another filesystem (the parent snapshots being on both filesystems).
I did not finish my setup, so I cannot share any scripts yet.
Ulrich
in reply to tubbadu • • •linuxPIPEpower
in reply to tubbadu • • •It is a question I've spent a lot of time trying to work out. Can't speak to docker.
Some of the specifics of Keeps and Dontkeeps depend on details of your system. You have to find out where the distro, DM and other apps keep the following:
Dontkeeps:
- trashes
- temp files
- file indexes .. IMHO these dont backup properly if you leave them in and will prevent you from completing the task
- device files
Keeps:
- list of installed packages --- explicit and deps separate if possible
- config files: /etc, ~/.config, ~/.* on a case by case basis... I say remove the obvious large temp dirs and keep the rest by default for simplicity
- for the system configs I've had a tool called etckeeper running for a while because it was highly recommended but I've never actually restored from it...
- personal documents and other files such as typically kept in the home directory
- /root occasionally has something you need
Ways to investigate:
- use a disk usage utility to find out where your storage is being used up ... It'll help you find large Dontkeeps
- watch for recently modified files
- dirs and files that are modified all the time are usually temp dirs. But sometimes they have something useful like your firefox profile.
Most backup solutions are ONE of the following:
Don't spend too much time crying about needing two solutions. Just make your backup today and reach perfection later.
Remember: sync isn't backup. Test your backup if you can (but its not as easy as it sounds). Off site your most precious files.
SayCyberOnceMore
in reply to tubbadu • • •I think most options have been covered here, but I'd like to consider some other bits...
User accounts & file permissions:- if you have >1 account, note that the UserID is internally numbered (starting from 1000, so Bob=1000, Sue=1001) and your file system is probably setup using the numerical UserID... so re-creating the users in a different order would give Sue access to Bob's files and vice versa.
Similarly, backing up /etc /var etc... you should check if any applications (ie databases) need specific chmod and chown settings
Rsync, tar, etc can cover some of this, you just need to check you rebuild users in the correct order.
Maybe Ansible is another approach? So your disaster recovery would be:
1. Install plain OS on new drive
2. Get Ansible access to it (ie basic netwroking)
3. Rebuild OS and instsll applicstions automatically with Ansible
4. Restore application & home folders (again with Ansible)
When you get this working, it's amazing to watch an entire system being rebuilt