I also understand the pain regarding non-backward compatibility between the
two versions. In terms of migration, it becomes a lot more complex if both
ends need to run the same version.
I didn't take a look at the technical details behind the incompatibility.
I'm trusting Frank and Eric on this topic and understand it's not an easy
fix to make v2.0.0 compatible with v1.2.8. You must understand it's a draw
back of a bad design in rdiff-backup from the start.
I'm in the same boat as many of you, I have more than two hundred servers
using rdiff-backup directly or through Minarca and it's impossible to
migrate all of them at once. I've been thinking about a migration plan for
some time now and I have a general idea that I can't wait to put in place.
I'm planning to work on a solution end-February. The general idea is to
pre-compile rdiff-backup 1.2.8 and 2.0.0 as individual executable and
deploy both of them on the central server as rdiff-backup-1.2.8 and
rdiff-backup-2.0.0. Then reconfigure the SSH server using a script to
either call rdiff-backup-1.2.8 by default and call rdiff-backup-2.0.0 based
on some condition.
On Thu, Jan 30, 2020 at 10:03 AM Derek Atkins <[email protected]> wrote:
> Frank Crawford <[email protected]> writes:
>
> > 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.
>
> So what data specifically changed?
>
> > Regards
> > Frank
>
> -derek
>
> --
> Derek Atkins 617-623-3745
> [email protected] www.ihtfp.com
> Computer and Internet Security Consultant
>
>
--
Patrik Dufresne <[email protected]>
