:: Re: [DNG] What not to back up
Top Page
Delete this message
Reply to this message
Author: Olaf Meeuwissen
Date:  
To: Steve Litt
CC: dng
Subject: Re: [DNG] What not to back up
Hi,

Steve Litt writes:

> Dr. Nikolaus Klepp via Dng said on Tue, 23 Nov 2021 20:43:28 +0100
>
>>Anno domini 2021 Tue, 23 Nov 14:27:56 -0500
>> Hendrik Boom scripsit:
>>> I'm setting up a new backup script that will do it all piecemeal so
>>> that if a part of it fails, it can be retried without having to
>>> start *everythng* over from scratch.
>>>
>>> Which top-level filesystems should *not* be backed up.
>>
>>
>>Question is: What do you want the backup for? Recover from a failed
>>disk in 5 minutes or "just" all your settings and user directories? I
>>for myself do not bother to save the OS, a list of all manually
>>installed packages is good enough for me.
>>
>>Nik
>
> I'm the same as Nik. If I can buy it again, or install it again, it's
> not a tragedy if I lose it. For this reason I don't back up /usr.


By the same reasoning, you can exclude /bin, /lib, /lib64 and /sbin.
However, I would back up /usr/local because that may be a real pain
to reconstruct.

> <rant>
> The majority of files in /home/yourname are useless. /home/yourname is
> a mishmash of stuff you created, settings you use, and useless crap
> like cache. It's huge and ugly. For that reason I create other top
> level directories to hold stuff I created myself.


I create dedicated directories below $HOME, version control them with
git and push to an external location. Gives me backups + versioning!

> </rant>
>
> Nevertheless, it really is necessary to back up /home, although
> everything should be done to make sure none of what you back up is
> cache:
>
> ======================================
> [slitt@mydesk ~]$ find .cache | wc -l
> 82571
> [slitt@mydesk ~]$ du -hs .cache
> 2.1G    .cache
> [slitt@mydesk ~]$ find . | grep cache | wc -l
> find: ‘./mail/Maildir/lost+found’: Permission denied
> 173948
> [slitt@mydesk ~]$
> ======================================

>
> Really?


Depending on what software you use, you may have missed a swat of
cache. I'd look for

find $HOME/.[^.]* -iname '*cache' -type d

# The above assumes bash for the .[^.]* shell glob.

At the office I (have to) use M$ Teams and that caches boatloads of
stuff elsewhere. Firefox also creates per site caches.

> Then there's ~/Downloads. The way I see it, if you need things in the
> download directory enough to back them up, those files should have been
> moved somewhere else.


That'd be ${XDG_DOWNLOAD_DIR:-Downloads} for folks that customize.

# Settings in ${XDG_CONFIG_HOME:-$HOME/.config}/user-dirs.dirs.

> I back up /home minus .cache, but I segregate that backup, and when I
> reinstall, instead of restoring to /home, I restore it to
> /scatch/oldhome, and manually transfer things as necessary.


I also do something like that for my $HOME. Now I still have an

$HOME/__ATTIC__/__ATTIC__/__ATTIC__/__ATTIC__/

that needs cleaning out ;-O

> In my opinion, here are some things that are absolutely essential to
> back up:
>
> * The /etc tree
> * The output of the mount command (yeah, I know /etc/fstab, but still)
> * The output of the command telling all the packages that were
> installed manually.


As mentioned in another follow up, you may want a *full* list of
packages installed (with their versions) if only to help trouble
shooting issues after reinstalling the list of previously manually
installed packages.

Even if you installed all 50,000+ Devuan packages, that'd be peanuts
compared to the size of the rest of your backup.

> * The UMENU2 menu structure.


I have no such thing as far as I am aware of.
Don't even know what UMENU2 is :-?

Ah, http://troubleshooters.com/projects/umenu2/ explains. Don't have
it, then. For my needs, dmenu and *sh-completion suffice.

> * All data you created, and I hope it's *not* in /home.
>
> Like Nik says, if your goal is to get it back up in 5 minutes, your
> best bet is to back up the entire system, as well as the mbr or
> whatever you call the UEFI equivalent (both copies). But if your
> intent is just to stay in business after losing a disk, I think a
> data-only backup is superior.


Hope this helps,
--
Olaf Meeuwissen, LPIC-2            FSF Associate Member since 2004-01-27
 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13  F43E B8A4 A88A F84A 2DD9
 Support Free Software                        https://my.fsf.org/donate
 Join the Free Software Foundation              https://my.fsf.org/join