[ale] Backup software incompatible versions

[Derek Atkins]

The issue is that rdiff-backup allows you to have a client - server 
solution where you have a centralized backup server that talks to the 
individual servers being backed up.  All the backup storage is managed by 
the centralized backup server.

The way this works is that rdiff-backup on one side talks to rdiff-backup 
on the other. This way you don't need every server to have access to the 
actual backup storage space (nfs, etc).

Unfortunately this requires both sides to use the same version.  And that's 
the problem.  As soon as you install a server newer than the backup server, 
or upgrade the backup server newer than your target backups, the versions 
skew and prevent your centralized backups from working.

The only workaround is to have both versions installed in parallel on your 
central server and call the right version based on the requirements of the 
other side.

-derek
Sent using my mobile device. Please excuse any typos.
On May 17, 2020 8:43:17 AM Jim Kinney via Ale <ale at ale.org> wrote:
> I'm confused as to the scope of the problem. The original data format is 
> the same. The stored, backup data is also the same. Only the process that 
> does a diff between orig and backup has changed.
>
> Unless the new version can't diff against the old backups I don't see a 
> problem. Slam in v3 python and don't look back. Unless I've totally 
> misunderstood (likely).
>
> I've been doing large version number changes in my infrastructure first for 
> years. Last upgrade is to user facing systems.
>
>
> On May 17, 2020 8:32:28 AM EDT, DJ-Pfulio via Ale <ale at ale.org> wrote:
>
> I've been stuck on an issue for a few weeks.
>
> For the 15 systems here, I've been using rdiff-backup v1.2.x for years,
> happily. Alas, it is python2-based and newer versions are incompatible.
>
> The current Ubuntu 20.04 includes a much newer rdiff-backup v2.0.0
> which uses python3. The way that python2 and python3 pack data for
> transit is different, incompatible, according to the rdiff-backup
> guys. The underlying storage format for the backup sets haven't
> changed, so it is just the C/S parts.
>
> Most of my systems are running 16.04, so they will likely move to
> 20.04, if that becomes possible, before next April. Some could end up on
> 18.04, which has a different version of rdiff-backup (python2). In
> their infinite developer wisdom, someone decided that a check for
> matching x.y.z rdiff-backup versions was necessary. The 'z' part
> bothers me. The 'x' check makes perfect sense.
>
> I see a number of solutions. Really addicted to the most recent
> backup set effectively being an rsync mirror. I've used
> rsync+hardlinking for versions previously, but got burned due to
> changes in owners and permissions not being versioned too. I'll not be
> returning to the
> D D D D D D F
> schedule like we used in the 1970s that some backup tools still require.
>
> Really would rather not have to install a separate toolchain on each
> system just to support backups between 3+ OS releases, but that is the
> direction I'm heading.
>
> If I wanted these sorts of complexities, I'd be running gentoo. Did
> that for a few months. Never again.
>
> For a few systems, using rsync to mirror the backup data to a location
> on the backup server, then using rdiff-backup to get efficient
> versioning wouldn't be too bad. In general, I only backup what is
> needed to recreate the system, not ALL the bits. My desktop backup is
> just 7GB of source files. 90 days of daily versions is just 8.16GB.
>
> Would love some other ideas.Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>
> --
> "no government by experts in which the masses do not have the chance to 
> inform the experts as to their needs can be anything but an oligarchy 
> managed in the interests of the few.” - John Dewey
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> https://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20200517/252836ba/attachment.html>