[ale] Backup software incompatible versions

Jim Kinney jim.kinney at gmail.com
Sun May 17 19:16:16 EDT 2020


Argh. Not fun. Jump all at once or sit with dead software.

On May 17, 2020 8:49:09 AM EDT, 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.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

-- 
"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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.ale.org/pipermail/ale/attachments/20200517/c821133b/attachment.html>


More information about the Ale mailing list