Re: [PLUG] Best Solution for Multiple Volume Backups

[Rich Freeman via plug <plug@lists.phillylinux.org>]

On Mon, Jul 13, 2020 at 5:21 PM Mark Bergman via plug
<plug@lists.phillylinux.org> wrote:
>
> In the message dated: Mon, 13 Jul 2020 14:09:46 -0400,
> The pithy ruminations from Rich Freeman via plug on
> [[PLUG] Best Solution for Multiple Volume Backups] were:
>
> => * Backup solution is itself easy to backup/restore (might just do this
> => by running it in a container and sticking a tarball on the backup
> => drive)
>
> Not a good idea with most databases.

Yeah, that is why I had the next point.  Any databases must be
disposable, but as you suggest I'm fine with having a backup of the
database.

My main issue is that if I lose the backup server I don't want the
backups to be useless, or to require excessive effort to restore.

And I suggested a tarball because it is easy to restore.

> => Backup sizes are going to be large - 10+TB.  It wouldn't hurt if this
>
> Is that a full, a differential, or an incremental? How often do you anticipate running a backup of that size?

That would be a full.  I don't see a need to re-create one often, but
maybe every few months I might to reduce the size of differentials or
consolidate space.

> => I'm pretty sure Bacula could do the job, but it is a bit heavyweight
>
> I run a moderate Bacula environment (a "full" backup would be ~350TB,
> if I did something insane like having a single 'fileset' for the whole
> filesystem). Bacula could do everything you want. There is quite a bit
> of learning curve.

Yeah, I've used it before.  That's why I'm a bit reluctant to use it
unless it really is the best option.  That said, if I containerize it
I'm less worried about the effort to do restores.

> Not as bad as you think. I don't backup to disk, but many bacula users do, and it's got a lot of features that allow
> volumes on a disk to emulate a tape -- mount/umount additional disks to do a full backup, set retention policies to
> overwrite existing backups as needed to save media, etc.

That's good to know.

>         dump the bacula database (postgres, mysql, mariadb) to disk
>         write that backup to tape
>
> That's a very common solution to the 'bacula self-backup' dilema.

Sure, but you still need the bacula software and config as well.  I
wouldn't use bacula to save that, hence a tarball/etc.  It need not be
updated often as long as it works.

Also, I'm pretty sure that you can regenerate a bacula index using
bscan.  Obviously a backup of the index is better, but it is good to
have the option.

And really all backups need an index one way or another.  They might
or might not be in separate files/databases/whatever, but to do an
incremental without rescanning the last full the backup software needs
to have some idea what has already been backed up.  I definitely want
a backup solution where the full backup doesn't need to be accessed to
perform an incremental.

-- 
Rich
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug