[ale] Backup software incompatible versions

[DJ-Pfulio]

A few years ago, I vaguely remember some backup tool, so either rsync
or rdiff-backup, checking that the location for the server and client
programs matched on both sides of the connection.  

Perhaps I'm remembering wrong.  I have slept since then. Memory after
even an hour of sleep is prone to mistakes.


On Sun, 17 May 2020 08:49:09 -0400
Derek Atkins <derek at ihtfp.com> wrote:

> 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.