[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
- Backward compatibility of next beta, Arrigo Marchiori, 2020/01/22
- Re: Backward compatibility of next beta, Frank Crawford, 2020/01/22
- Re: Backward compatibility of next beta, Frank Crawford, 2020/01/22
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/28
- Re: Backward compatibility of next beta, EricZolf, 2020/01/29
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/30
- Re: Backward compatibility of next beta, Reio Remma, 2020/01/30
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/30
- Re: Backward compatibility of next beta, Arrigo Marchiori, 2020/01/31
- Re: Backward compatibility of next beta, Arrigo Marchiori, 2020/01/30
- Re: Backward compatibility of next beta,
Frank Crawford <=
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/30
- Re: Backward compatibility of next beta, Patrik Dufresne, 2020/01/30
- Re: Backward compatibility of next beta, Derek Atkins, 2020/01/30