[gentoo-user] Re: Backup [Was: Old Firefox ebuild?]

[Kai Krakow]

Am Sat, 15 Oct 2016 07:22:06 -0400
schrieb Rich Freeman <rich0@g.o>:

> On Sat, Oct 15, 2016 at 1:35 AM, Ian Zimmerman <itz@×××××××.net>
> wrote:
> > On 2016-10-15 05:42, Kai Krakow wrote:
> >
> >> The backup source is my btrfs subvol 0. I can put the systemd units
> >> for backup to github if you're interested.
> >
> > I'm not a systemd fan, so they wouldn't help me, but thanks for
> > offering.
>
> I'd be curious to see them; whether you use systemd or not units are
> pretty trivial to read and make use of in scripts, cron entries, etc.

https://gist.github.com/kakra/7637555528a54a0c7aaca6f68338418c

My system automatically sleeps after 2 hours, so I'm using WakeSystem
to wake it up at night for backup.

/mnt/btrfs-pool is my pool. I also create the list of subvolumes on the
backup drive to more easily recreate all subvolumes before restoring the
backup.

My initial backup took around 24 hours, successive backups run 15
minutes. I'm using bcache for both my system storage and backup storage
to speed up the process but it includes Eric Wheelers ionice patches to
reduce SSD wear and improve overall performance:

"bcache: introduce per-process ioprio-based bypass/writeback hints"

Also, you can change the environment settings to support encrypted
backups. I'm not using them as I only use trusted storage and don't
want to bother keeping the crypt key in a safe place.

If I reintroduce duplicating to a remote location, I'd simply rsync the
backup archive to a remote location with an additional ExecStartPost
line. My diff is around 500 MB to 2 GB per day. (my external USB disk
died, I'll get a NAS sometime later instead)

Actually, I'm doing this with a remote location which is rsync'ed to my
local backup every night.

> I just use snapper to manage snapshots if all I'm worried about is
> casual deletion of files.  Since I don't fully trust btrfs I also keep
> a full rsnapshot (basically an rsync wrapper) of my btrfs volumes on a
> local ext4.

That is why I chose borgbackup. But I prefer XFS as a more reliable and
faster file system for backup storage. Also, I used the systemd
automounter so it won't be mounted all the time but just on demand.

> > My priorities are different, and there are constraints resulting
> > from my priorities as well as others.
> >
> > I am mostly worried about physical catastrophic damage (I live in
> > earthquake country) and losing my personal data, which could not be
> > recreated.  So it has to be offsite, and because it's personal data
> > it has to be encrypted.  And I cannot make the trip to where it's
> > stored every day.
> >
> > Given the time (including the trip) it takes to restore, I don't
> > see the point of backing up static files which can be reinstalled
> > from the distribution.  Of course, I'm still learning gentoo and so
> > it was easy for me to make the mistake of forgetting that files
> > under /usr/portage aren't really in that catagory.
> >
>
> ++
>
> What I really consider my "backups" are stored encrypted on amazon s3
> using duplicity (which I highly recommend for this purpose).

Borgbackup supports strong encryption. I'm pretty sure you could even
manage storing to amazon s3 directly.

> Basically it amounts to /etc, and /home, with a number of exclusions
> (media and cache).  For media I care about like photos I include new
> stuff in m duplicity backups, but as I accumulate reasonable chunks of
> it I make a separate backup and store it offsite, and remove that
> chunk from my duplicity backup.  This prevents the daily-updated
> backup pool from getting insanely large, while still maintaining an
> offsite copy (since these files don't change over time).

Borgbackup supports cache tags to exclude cache directories. I placed
some of them manually in e.g. $HOME/.cache. Borgbackup deduplication
makes full backup snapshots insanely small: 30 TB of backups are stored
in 1.8 TB for me. So it also detects file moves which rsync doesn't
(and deduplicity probably also doesn't).

> I'd never spend the money to be doing cloud backup of /usr (other than
> /usr/local).  I have all my static configuration backed up, so I could
> just restore that onto a stage 3 and run emerge -uDN world to get all
> of that back.

I figured that reinstallation plus restoring is much more time
consuming than just simply put it back. Reinstalling Gentoo from
scratch will take me 3-4 days until everything is back in place
normally. Restoring my data from borgbackup takes around 24 hours last
time I had to do it.

Restoring onto a stage3 may also introduce orphan files because you are
overwriting what the package manager thinks is installed. And by the
way: How big could /usr be usually (excluding portage)? Maybe a few
tiny gigabytes. It's a tiny fragment of my complete backup.

Instead, I'm using a tiny USB stick with an sdcard and a rescue system
that I keep updated from time to time (simply by booting a
systemd-nspawn container from it). That USB stick is just as small as
the Logitech nano receivers (the sdcard is inserted within the
connector), so I keep it plugged in all the time. This installation
also includes a script to recreate my btrfs including it's subvolumes,
and then restore the backup upon that. It also works as a backup for
my /boot partition as it essentially has a copy of that (to be
bootable).

> If I did have an offsite server somewhere where storage costs weren't
> a big deal then I'd probably be setting up replicas using
> btrfs+zfs-send/receive.  You can do that at minimal cost with
> incrementals, and I could probably do the first clone on the local
> LAN.

I'd take a look at borgbackups remote capabilities also. I'm backing up
some remote machines by simply using the prebuilt single binary from
the website (so versions easily stay in sync). Borgbackup uses ssh
tunnels for transferring data and a remote cache for speeding up delta
transfers. It's much much faster than rsync. I never tried btrfs
send/receive and it's probably still less space efficient than
borgbackup.


-- 
Regards,
Kai

Replies to list-only preferred.