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 <o...@seravo.com> 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
_______________________________________________
rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users
Wiki URL: http://rdiff-backup.solutionsfirst.com.au/index.php/RdiffBackupWiki
