[GTALUG] On the subject of backups.

[Alvin Starr]

On 5/4/20 12:52 PM, John Sellens wrote:
> On Mon, 2020/05/04 12:03:19PM -0400, Alvin Starr <alvin at netvel.net> wrote:
> | The client really only wants to use Centos/RHEL and ZFS is not part of that
> | mix at the moment.
>
> Well, one could argue that zfs on centos is fairly well supported ...
If it were purely my choice I would agree but the general rule is 
software that can be gotten from Centos/RH and EPEL where necessary.

>
> | The data is actually sitting on a replicated Gluster cluster so trying to
> | replace that with an HA NAS would start to get expensive if it were a
> | commercial product.
>
> Of course "expensive" depends on the client.  An HA truenas that size,
> all flash is (I believe likely well) under $15K USD.
If  things moved to a commercial NAS it would likely be something like 
Equalogic or Netapp and in that world if you have to ask the price you 
cannot afford it.
>
>
> Ah - you didn't mention Gluster.
>
> In theory, Gluster has geographic replication.
It does have replication but replication is not backup.
a little oops like "rm -rf * somefile"  will make for a very bad day if 
you don't catch it before it gets replicated.

>
> And if your bricks are on LVM storage, you can use gluster snapshots as well:
>      https://docs.gluster.org/en/latest/Administrator%20Guide/Managing%20Snapshots/
> to guard against accidental removals, etc.
Gluster snapshots require thinly provisioned LVM.
Which is doable  but will require rebuilding the systems with a 
different LVM config.
>
> (I've not used either, and my glusters are quite old versions at the present time.)
>
> Depending on how it's all configured, you may get better performance
> backing up the bricks, rather than backing up gluster itself.  I have
> a two-node gluster, mirrored, so I can backup the bricks on one of the
> servers and get everything.  Obviously that's a very simple "cluster".
>
> Traditionally, gluster filesystem performance with large numbers of
> small files in a directory is horrible/pathetic.  If you're backing up
> the gluster filesystem, you would almost certainly get better performance
> if your file structure is deeper and narrower, if that's possible.
We are actually backing up the bricks but the they are BIG bricks.
Yes gluster has a high per file open cost but in this application that 
is not an issue during operation.
A backup using a gluster mount would move from the world of days to 
weeks because of the synchronization overhead.

Even with snapshots the length of time for a backup can be outrageously 
long.
>
> Cheers
>
> John

-- 
Alvin Starr                   ||   land:  (647)478-6285
Netvel Inc.                   ||   Cell:  (416)806-0133
alvin at netvel.net              ||