OS Backup - what should and what should not be backup'd?
from tubbadu@lemmy.kde.social to linux@lemmy.ml on 16 Jul 16:29
https://lemmy.kde.social/post/4101758

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?

#linux

threaded - newest

SheeEttin@lemmy.zip on 16 Jul 16:39 next collapse

If you need to restore it, back it up.

How do you plan to restore if the whole drive dies?

tubbadu@lemmy.kde.social on 16 Jul 16:55 collapse

thanks for the reply!

How do you plan to restore if the whole drive dies?

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@sh.itjust.works on 16 Jul 17:07 next collapse

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@lemmy.kde.social on 16 Jul 17:22 collapse

thanks for the reply! Yes for sure I’m backing up all the /home directory, but I’d like to preserve also important configurations like ssh, cronjob etc, but I don’t really know which directories are important for this and which are not

non_burglar@lemmy.world on 17 Jul 15:39 collapse

You’ve just answered your ow question; back up the /etc directory should cover all those.

andrewd18@midwest.social on 16 Jul 17:44 next collapse

Don’t forget to grab any /etc configurations you’ve made to adapt the system to your hardware or services. You don’t need all of /etc, just whatever you’ve changed to not be default.

[deleted] on 16 Jul 18:37 next collapse

.

taters@piefed.social on 16 Jul 19:00 next collapse

I've been working with the rsync command for a while now and I have created a pretty solid backup system on my own with that command. I've had some terrible luck using back/restore programs like Timeshift on Linux Mint and so I went out of my way to learn how to make a "simpler" backup/restore process for myself.

I am using Alpine Linux so the following commands are based around that file system. It's possible to modify the commands to fit your Operating System's file system by using the lsblk command to see all the mountpoints for your OS. Each mountpoint requires a separate rsync command.

For myself, I have four mount points. / for the root directory. For the boot directory, I will need a command for /boot/ and /boot/efi/ directories. Since my home directory is in a separate partition, I also need a command for /home/.

The following are all the expanded commands I use to backup my entire OS which is backed up to the /backup/ directory:

# BACKUP  
# /root/  
`rsync --dry-run --archive --acls --one-file-system --xattrs --hard-links --sparse --verbose --human-readable --partial --progress --compress --delete --numeric-ids '--exclude=/backup/*' '--exclude=/boot/*' '--exclude=home/*' '--exclude=proc/*' '--exclude=sys/*' '--exclude=dev/*' '--exclude=tmp/*' '--exclude=run/*' '--exclude=mnt/*' '--exclude=media/*' / /backup/`  

# /boot/  
`rsync --dry-run --archive --acls --one-file-system --xattrs --hard-links --sparse --verbose --human-readable --partial --progress --compress --delete --numeric-ids '--exclude=lost+found' /boot/ /backup/boot/`  

# /boot/efi/  
`rsync --dry-run --archive --acls --one-file-system --xattrs --hard-links --sparse --verbose --human-readable --partial --progress --compress --delete --numeric-ids '--exclude=lost+found' /boot/efi/ /backup/boot/efi/`  

# /home/  
`rsync --dry-run --archive --acls --one-file-system --xattrs --hard-links --sparse --verbose --human-readable --partial --progress --compress --delete --numeric-ids '--exclude=lost+found' '--exclude=.cache/*' /home/ /backup/home/`  

The root partition is the most involved command so I'll break it down slightly. You can check out the rsync man page for more detailed information about each command option.

  • --dry-run- is used to perform a test run. If you have any verbose options, it can be used to see what files will be moved without performing any actions. This is important for testing but I also use it to view or review any changes before I commit anything. This option must be removed if you want to commit any changes. I'm leaving it here incase anyone decides to blindly run this command. I don't want to be responsible for any lost data.
  • --archive --acls --one-file-system --xattrs --hard-links --sparse are all used to preserve any file/folder attributes and permissions. --archive is commonly used, even for single files while the rest are more important for the operating system in the event of a restore. You can check the man page for more information as I've kind of forgotten their purposes over time.
  • --verbose --human-readable --partial --progress is both for verbose outputs and for continuing in case a previous transfer was incomplete.
  • --delete rsync will compare the source directory and the destination directory for any changes and will delete any files or directories in destination directory to match the source directory.
  • --numeric-ids is used to preserve ownership in number form. I find it useful since I keep multiple device backups on an external SSD.
  • --exclude=... This excludes files or directories from being synced. For the / directory it's important to exclude /backup/. If you don't, you will end up recursively saving to the /backup/* directory until your storage is full. /boot/* home/* are excluded because they will be handled by the following rsync commands. proc/* sys/* dev/* tmp/* run/* mnt/* media/* are directories that are used to run the operating system or devices and will not be required after a system reboot.
  • / /backup/ is two parts. / is the source directory, what you want backed up. /backup/ is the destination directory. It's where you want your data to end up.
  • --exclude=lost+found is not important and can be excluded
  • --exclude=.cache/* can also be excluded from the home directory if you want to save space.

You'll most likely need to create the /backup/ directory in order to perform the backup commands.

tubbadu@lemmy.kde.social on 16 Jul 21:29 collapse

Wow this is amazing! thank you very much for the super detailed answer! exactly what I was looking for!

taters@piefed.social on 16 Jul 22:21 collapse

No worries, glad I can help :)

If you are interested, I made a tool based around rsync. It's what I use to handle my backups plus transferring files and folders between my network connected devices.

https://codeberg.org/taters/rTransfer

With my tool, I'll make the following files in a directory:

.
├── .sync-computer-fs_01_root
├── .sync-computer-fs_02_boot
├── .sync-computer-fs_03_boot-efi
└── .sync-computer-fs_04_home

and then enter the Rsync Backup command information into the appropriate fields of each file. I can run my command with those files and it'll do a dry run followed by a confirmation to continue with the actual transfer.

There's a command option flag to reverse the transfer direction which can act as a "restore" in the case of an OS backup.

If you happen to give it a try, any feedback would be appreciated.

Whatever you choose to do, good luck and be sure to test everything more than you think you should. Both backups and restores. I know it's all to easy to fuck up data transfer in any direction :)

catty@lemmy.world on 16 Jul 20:08 next collapse

everything. download clonezilla, perform a bare-metal backup and if the worst happens, you can reflash your new disk to exactly how the old one was without skipping a beat.

OhVenus_Baby@lemmy.ml on 17 Jul 02:09 next collapse

*most of the time. And test backups to make sure they really work or you have no true backup.

catty@lemmy.world on 17 Jul 08:45 collapse

clonezilla tests it as part of its backup process.

OhVenus_Baby@lemmy.ml on 17 Jul 18:28 collapse

I’ve used clonezilla a bunch, I keep it on a flash drive as I’m always swapping hardware for myself or others or family. There’s issues. It’s as close as one could get to a carbon copy but there sometimes can be flaws that aren’t present in its checks. I find them to be random but possible. It’s fantastic software though. Amazing even.

linuxPIPEpower@discuss.tchncs.de on 17 Jul 17:58 collapse

Dont you have to power off the system and boot from clonezilla image to crea5e the backup?

bjoern_tantau@swg-empire.de on 16 Jul 20:23 next collapse

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 of dpkg --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@lemmings.world on 16 Jul 20:58 next collapse

I recommend Borgmatic, a declarative way to set up borg backups. I find it much nicer than a having a backup.sh script and the configuration is really straight-forward.

tubbadu@lemmy.kde.social on 16 Jul 21:23 collapse

This is actually very interesting! I’ll gladly look into it, thank you very much!

Cricket@lemmy.zip on 17 Jul 18:48 collapse

I want to switch to Borg backup but haven’t found the time yet.

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.

MangoPenguin@lemmy.blahaj.zone on 16 Jul 20:44 next collapse

Backup everything as a bootable system image, that’s the best method for recovery IMO.

tubbadu@lemmy.kde.social on 16 Jul 21:30 collapse

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@lemmy.blahaj.zone on 17 Jul 16:57 collapse

Only the first backup, after that with most backup software it will do incremental backups with delta transfer, so will only send the data that has changed since the last backup.

utopiah@lemmy.ml on 17 Jul 08:18 next collapse

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 use find /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.

digdilem@lemmy.ml on 17 Jul 08:32 next collapse

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.

DieserTypMatthias@lemmy.ml on 17 Jul 08:59 collapse

like docker images

Maybe try setting up a local Gitea instance with a Docker registry.

poinck@lemmy.one on 17 Jul 08:41 next collapse

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@feddit.org on 17 Jul 16:14 next collapse

I usually just use SyncThing and sync the Home directory to another device.

linuxPIPEpower@discuss.tchncs.de on 17 Jul 18:18 next collapse

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:

  1. User files
  2. System files

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.

Cyber@feddit.uk on 17 Jul 20:33 next collapse

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

JTskulk@lemmy.world on 19 Jul 00:24 collapse

Here’s an edited list of what I exclude from my full system backup on my debian machine:

        <Exclude>
            <Item>/.Trash-*/</Item>
            <Item>/.recycle/</Item>
            <Item>/*.pyc</Item>
            <Item>/var/cache/apt/archives</Item>
            <Item>/tmp/</Item>
            <Item>/proc/</Item>
            <Item>/dev/</Item>
            <Item>/sys/</Item>
            <Item>/run/</Item>
            <Item>*/RecentDocuments/</Item>
            <Item>*/.cache/</Item>
            <Item>*/Trash/</Item>
            <Item>*/recentfolders/</Item>
            <Item>*/pictureCache/</Item>
            <Item>*/Crash Reports/</Item>
            <Item>*/GLCache/</Item>
            <Item>*/cache/</Item>
            <Item>*/tmp/</Item>
            <Item>/var/log/</Item>
            <Item>*/.xsession-errors</Item>
            <Item>*.swp</Item>
            <Item>/var/lib/samba/private/msg.sock</Item>
            <Item>/home/jt/.local/share/baloo/</Item>
            <Item>/home/jt/.mozilla/firefox/*/sessionstore-backups/</Item>
            <Item>/home/jt/.mozilla/firefox/*/crashes/</Item>
            <Item>/home/jt/.mozilla/firefox/*/datareporting/</Item>
            <Item>/home/jt/.local/share/Steam</Item>
            <Item>*/.thumbnails/</Item>
            <Item>*/.cache/</Item>
            <Item>*/lost+found/</Item>
            <Item>/mnt/</Item>
            <Item>/*.bash_history</Item>
            <Item>/opt/firefox</Item>
            <Item>/home/jt/.local/share/klipper/history*.lst</Item>
            <Item>*/steam.pipe</Item>
            <Item>*/recently-used.xbel</Item>
            <Item>/home/jt/.mozilla/firefox/*/storage/</Item>
            <Item>/home/jt/.local/share/kpeoplevcard</Item>
        </Exclude>