rdiff-backup-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Backward compatibility of next beta


From: Frank Crawford
Subject: Re: Backward compatibility of next beta
Date: Thu, 30 Jan 2020 22:57:09 +1100
User-agent: Evolution 3.34.3 (3.34.3-1.fc31)

On Thu, 2020-01-30 at 11:40 +0100, Arrigo Marchiori wrote:
> Hello,
> On Tue, Jan 28, 2020 at 03:45:19PM -0500, Derek Atkins wrote:
> > Hi,
> > Frank Crawford <address@hidden> writes:
> > > (Sorry about the previous formatting I'm resending this
> > > formattedcorrectly)
> > > Rigo,
> > > It depends on what you mean by compatible.
> > > Python3 version of rdiff-backup is not interoperable for
> > > remoteoperations with python2 rdiff-backup, so v2.0.0 will not
> > > work withv1.2.8 or v1.3.3.  This is a python3 vs python2 issue
> > > and could not befixed without major changes to both versions.
> > 
> > So just to be clear, the version of "rdiff-backup --server" must
> > matchthe other version?  Right now I have a backup server that
> > basicallyruns:
> > rdiff-backup <excludelist> hostname_backup::<dir>
> > <targetdir>/hostname
> > Where "hostname_backup" is an SSH configuration, and it then uses
> > SSH toconnect to "hostname" where it creates and mounts an LVM
> > snapshot andthen runs "rdiff-backup --server --restrict-read-only
> > /mnt/snap"
> > Having said all this, what you're saying is that once ANY of my
> > targethosts get upgraded to a point where they can only runrdiff-
> > backup-2.0.0, then I must upgrade ALL most hosts (and backupserver)
> > to be running rdiff-backup-2.0.0?
> > IMHO, that is a VERY VERY BAD THING.
> > > However, the backup archives that are created are compatible, so
> > > if youdid a backup with an older version, you can continue using
> > > it with noissues.
> > > In fact, while this isn't in the planned distribution, there is
> > > somecomment by someone who has written a wrapper that invokes
> > > either apython2 or python3 version, depending on what it is
> > > talking to.  Ofcourse the python2 version is either v1.2.8 or
> > > v1.3.3, not v2.0.0.
> > 
> > I think this is extremely important to get into the release in
> > order tohandle the use case stated above!  I certainly can't
> > believe that I amthe only person who uses rdiff-backup this way to
> > back up remotemachines.
> 
> Maybe you could find a solution by using the --remote-
> schemaparameter? If I understood correctly, it should allow you to
> keep twoversions of rdiff-backup side-by-side, rather than upgrading
> theprogram at ``system-level''.
> I cannot try this, but I would suggest:
>  1- on the client _and_ server, install the new version in ~/rdiff-
> backup-2 2- run the version 2 client with the parameter:      
> --remote-schema 'ssh -C %s ~/rdiff-backup-2/rdiff-backup --
> server'    I hope this helps,

No, the use of "--remote-schema" is the issue as it passes data between
the two programs in a specific format that has changed between python2
and python3 because of internal variations.

Regards
Frank


reply via email to

[Prev in Thread] Current Thread [Next in Thread]