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

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

Re: [rdiff-backup-users] Bump major release version for rdiff-backup?


From: EricZolf
Subject: Re: [rdiff-backup-users] Bump major release version for rdiff-backup?
Date: Fri, 2 Aug 2019 20:11:16 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0

Hi,

I have also an issue with the move to librsync 2: it isn't packaged for Fedora.

This said, looking at [1], it seems that the move from MD4 to BLAKE2 happened in 1.0, and only with 2.0.1 does MD4 disappear.

Couldn't we use a version to support both approaches before we make a cut?

OK, I see that 0.9.7 is packaged for Debian and jumps directly to 2.0.2 in sid. Fantastic... That's quite a mess. Not sure how we can bring all requirements together.

KR, Eric

[1] https://github.com/librsync/librsync/blob/master/NEWS.md

On 02/08/2019 15:23, Derek Atkins wrote:
Hi,

I have some questions about these changes:

Otto Kekäläinen <address@hidden> writes:

Hello!

With the adoption of librsync2 the old MD4 hash is no longer supported
and thus a non-backwards compatible change is introduced. All backups
must therefore start from "scratch".
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776246
I use rdiff-backup over SSH to back up a bunch of machines from a single
backup server; how will this change affect the version skew of a client
still running 1.2.8 and the server running version 3?  Or alternately,
how will it work in the other direction?  I.e., will the two versions be
able to work properly together?

Also, will I be able to restore from older backups on incrementals?
I've got a year of incrementals for each system.  It would suck if there
were a flag day where those incrementals stopped working, or if I had to
start over from scratch and lose a year's worth of history.

-derek



reply via email to

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