<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"><html><head></head><body>Argh. Not fun. Jump all at once or sit with dead software.<br><br><div class="gmail_quote">On May 17, 2020 8:49:09 AM EDT, Derek Atkins <derek@ihtfp.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div dir="auto">
<div dir="auto">The issue is that rdiff-backup allows you to have a client - server solution where you have a centralized backup server that talks to the individual servers being backed up. All the backup storage is managed by the centralized backup server. </div><div dir="auto"><br></div><div dir="auto">The way this works is that rdiff-backup on one side talks to rdiff-backup on the other. This way you don't need every server to have access to the actual backup storage space (nfs, etc). </div><div dir="auto"><br></div><div dir="auto">Unfortunately this requires both sides to use the same version. And that's the problem. As soon as you install a server newer than the backup server, or upgrade the backup server newer than your target backups, the versions skew and prevent your centralized backups from working.</div><div dir="auto"><br></div><div dir="auto">The only workaround is to have both versions installed in parallel on your central server and call the right version based on the requirements of the other side. </div><div id="aqm-signature" dir="auto" style="color: black;"><div dir="auto"><br></div><div dir="auto">-derek</div><div dir="auto">Sent using my mobile device. Please excuse any typos. </div></div><div dir="auto"><br></div>
<div id="aqm-original" style="color: black;">
<!-- body start -->
<div class="aqm-original-body"><div style="color: black;">
<p style="color: black; font-size: 10pt; font-family: sans-serif; margin: 8pt 0;">On May 17, 2020 8:43:17 AM Jim Kinney via Ale <ale@ale.org> wrote:</p>
<blockquote type="cite" class="gmail_quote" style="margin: 0 0 0 0.75ex; border-left: 1px solid #808080; padding-left: 0.75ex;">
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
<div>_______________________________________________</div>
<div>Ale mailing list</div>
<div><a class="aqm-autolink aqm-autowrap" href="mailto:Ale%40ale.org">Ale@ale.org</a></div>
<div><a class="aqm-autolink aqm-autowrap" href="https://mail.ale.org/mailman/listinfo/ale">https://mail.ale.org/mailman/listinfo/ale</a></div>
<div>See JOBS, ANNOUNCE and SCHOOLS lists at</div>
<div><a class="aqm-autolink aqm-autowrap" href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a></div>
<div><br></div></blockquote>
</div>
</div>
<!-- body end -->
</div><div dir="auto"><br></div>
</div>
</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>