<html><head></head><body>I'm confused as to the scope of the problem. The original data format is the same. The stored, backup data is also the same. Only the process that does a diff between orig and backup has changed.<br><br>Unless the new version can't diff against the old backups I don't see a problem. Slam in v3 python and don't look back. Unless I've totally misunderstood (likely).<br><br>I've been doing large version number changes in my infrastructure first for years. Last upgrade is to user facing systems.<br><br><div class="gmail_quote">On May 17, 2020 8:32:28 AM EDT, DJ-Pfulio via Ale <ale@ale.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><br>I've been stuck on an issue for a few weeks.<br><br>For the 15 systems here, I've been using rdiff-backup v1.2.x for years,<br>happily. Alas, it is python2-based and newer versions are incompatible.<br><br>The current Ubuntu 20.04 includes a much newer rdiff-backup v2.0.0<br>which uses python3. The way that python2 and python3 pack data for<br>transit is different, incompatible, according to the rdiff-backup<br>guys. The underlying storage format for the backup sets haven't<br>changed, so it is just the C/S parts.<br><br>Most of my systems are running 16.04, so they will likely move to<br>20.04, if that becomes possible, before next April. Some could end up on<br>18.04, which has a different version of rdiff-backup (python2). In<br>their infinite developer wisdom, someone decided that a check for<br>matching x.y.z rdiff-backup versions was necessary. The 'z' part<br>bothers me. The 'x' check makes perfect sense.<br><br>I see a number of solutions. Really addicted to the most recent<br>backup set effectively being an rsync mirror. I've used<br>rsync+hardlinking for versions previously, but got burned due to<br>changes in owners and permissions not being versioned too. I'll not be<br>returning to the <br>D D D D D D F<br>schedule like we used in the 1970s that some backup tools still require.<br><br>Really would rather not have to install a separate toolchain on each<br>system just to support backups between 3+ OS releases, but that is the<br>direction I'm heading.<br><br>If I wanted these sorts of complexities, I'd be running gentoo. Did<br>that for a few months. Never again.<br><br>For a few systems, using rsync to mirror the backup data to a location<br>on the backup server, then using rdiff-backup to get efficient<br>versioning wouldn't be too bad. In general, I only backup what is<br>needed to recreate the system, not ALL the bits. My desktop backup is<br>just 7GB of source files. 90 days of daily versions is just 8.16GB.<br><br>Would love some other ideas.<hr>Ale mailing list<br>Ale@ale.org<br><a href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a><br>See JOBS, ANNOUNCE and SCHOOLS lists at<br><a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a><br></pre></blockquote></div><br>-- <br>"no government by experts in which the masses do not have the chance to inform the experts as to their needs can be anything but an oligarchy managed in the interests of the few.” - John Dewey</body></html>