[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Backward compatibility of next beta
From: |
Arrigo Marchiori |
Subject: |
Re: Backward compatibility of next beta |
Date: |
Thu, 30 Jan 2020 11:40:10 +0100 |
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 formatted
> > correctly)
> >
> > Rigo,
> >
> > It depends on what you mean by compatible.
> >
> > Python3 version of rdiff-backup is not interoperable for remote
> > operations with python2 rdiff-backup, so v2.0.0 will not work with
> > v1.2.8 or v1.3.3. This is a python3 vs python2 issue and could not be
> > fixed without major changes to both versions.
>
> So just to be clear, the version of "rdiff-backup --server" must match
> the other version? Right now I have a backup server that basically
> runs:
>
> rdiff-backup <excludelist> hostname_backup::<dir> <targetdir>/hostname
>
> Where "hostname_backup" is an SSH configuration, and it then uses SSH to
> connect to "hostname" where it creates and mounts an LVM snapshot and
> then runs "rdiff-backup --server --restrict-read-only /mnt/snap"
>
> Having said all this, what you're saying is that once ANY of my target
> hosts get upgraded to a point where they can only run
> rdiff-backup-2.0.0, then I must upgrade ALL most hosts (and backup
> server) 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 you
> > did a backup with an older version, you can continue using it with no
> > issues.
> >
> > In fact, while this isn't in the planned distribution, there is some
> > comment by someone who has written a wrapper that invokes either a
> > python2 or python3 version, depending on what it is talking to. Of
> > course 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 to
> handle the use case stated above! I certainly can't believe that I am
> the only person who uses rdiff-backup this way to back up remote
> machines.
Maybe you could find a solution by using the --remote-schema
parameter? If I understood correctly, it should allow you to keep two
versions of rdiff-backup side-by-side, rather than upgrading the
program 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,
--
rigo
http://rigo.altervista.org
- 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 <=
- Re: Backward compatibility of next beta, Frank Crawford, 2020/01/30
- 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