Re: Backward compatibility of next beta

Frank Crawford <[email protected]>
Newsgroups gmane.comp.sysutils.backup.rdiff-backup.general
Message-ID <cf1870302cb2e3b46f1282b60a197738693e7b6b.camel@crawford.emu.id.au>
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 <[email protected]> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.