[Borgbackup] Moving from old to new backup server

[Oliver Hoffmann]

Hi all,


so, I decided to do it the boring but save way ;-)

Means no zfs or btrfs and no rsync and VM migration. Instead a raid6
with ext4, a new VM and moving the clients step by step from the old
borg-server to the new one. After 4-6 weeks the backups on the old one
will be obsolete and the whole process is complete.

Thank you for your advise!

Oliver

> Thanks for your reply!
> 
>>> Otherwise I could set up an "empty" borg-VM and move all the clients to
>>> the new one. After a couple of weeks when the backups are old and
>>> obsolete, I could switch off the old borg server.
>>
>> BorgMatic might have an interesting different idea as well: Keep the
>> setup as-is and start to backup into multiple repos, some hosted on
>> your new server. If your old system really can't be used anymore or
>> the backups on the new system are simply enough, just switch your VM.
>>
>> https://torsion.org/borgmatic/docs/how-to/make-backups-redundant/
> 
> I looked into this already. Redundancy would be nice but I think having
> twice as much traffic/backup volume takes too long. So for now it is
> just about moving from one to another.
> 
>> This would prevent RSYNC-times, creating a new VM and your restore
>> etc. could be kept as-is as long as storage is available on the old
>> server. OTOH, backup times increase from my understanding.
> 
> True but then I'd have to change every client plus keeping the old
> scripts and passphrases for a while.
> 
>>> I like the other idea more though. What do you think?
>>
>> The main point might be if RSYNC is able to catch up with changes,
>> like when pruning archives. From my understanding, compacting results
>> in new additional files, which might make RSYNC transfer files today
>> which are ocmpacted and removed tomorrow in favour of additionally to
>> transfer files. If that happens more often than RSYNC is able to
>> transfer data, your migration might never finish at all in theory. :-)
> 
> I'd rather do a first rsync then make sure that no backups are running
> and then a second rsync. That might cost a day without backups but
> therefore no rsync-confusion ;-)
> 
>> Though, I guess that's pretty unlikely. If I was you, I would decide
>> based on how wortht he old backups in the new systems are and how long
>> backing up to two destinations might take. Because it might be of
>> benefit to really start over with new repos with new default settings
>> and stuff.
> 
> I see the advantages but rsync + VM-migration is the easier way. Still
> didn't made up my mind yet.
> 
>> Otherwise, your RSYNC-approach reads fine to me and I would most
>> likely do the same.
>>
>>> Oh, another question. What would be the best file system? Just ext4 or
>>> better something fancier like btfs or xfs? zfs would be nonsense as the
>>> raid is handled by hardware.
>>
>> ZFS is not just about RAID, just as BTRFS is not only about non-RAID.
>> In fact, ZFS seems abit more mature, e.g. cares about things like file
>> name encoding instead of simply storing bytes and stuff like that. In
>> my opinion, it has the better interface and some better concepts like
>> pools vs. datasets vs. snapshots vs. clones etc. as well. There might
>> even be better tooling like zfs-auto-snaps, ZREP and stuff like that.
>> Depending on where you run your hardware, built-in encryption might be
>> a good argument as well, it is for me.
> 
> Yes, I agree.
> 
>> Said that, have a look at your distribution first and which file
>> system it prefers and is best integrated with. Think of updates and
>> problems during those, some distributions integrate tightly with
>> BTRFS, like SUSE, some chose ZFS instead, like Ubuntu, and provide a
>> lot of default tools and setup for either of both. Not only because of
>> updates, but backup as well.
> 
> Unfortunately xcp-ng which is based on centos7.5 doesn't really support
> neither btrfs nor zfs as it looks. I expected at least btrfs or zfs.
> A storage repository (SR) based on zfs is possible though but that's not
> what I have in mind.
> 
>> For me, it's always BTRFS or ZFS these days, depending on the used OS,
>> with ZFS being in favor. XFS is in the process of catching up only and
>> lacks a lot of tooling and features, ext4 lacks essential concepts
>> like snapshots, compression etc. and seems pretty legacy to me. No
>> reason to start new systems with the last two mentioned in my opinion.
> 
> Unless your OS stands in the way...
> 
> I'll do some tests and describe how I eventually succeeded. Might be
> helpful for others.
> 
> Regards,
> 
> Oliver
> 
> 



-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <https://mail.python.org/pipermail/borgbackup/attachments/20210927/369f1ba1/attachment.sig>