Probleme mit rdiff-backup

[neanderthaler]

Hallo Forum,

heute wollte ich wie gewohnt ein Backup mit rdiff-backup machen. Überraschender Weise erhielt ich die unten stehenden Fehlermeldungen. Das Backup wurde ausgeführt, aber da ich die Fehlermeldungen nicht wirklich verstehe traue ich der Sache nicht. Auch habe ich unter

Code: Alles auswählen

rdiff-backup --help

keine Hinweise gefunden, was ich in Zukunft anders machen sollte. Vielleicht kann mir jemand aus dem Forum das ganze erklären. Tante Google hat leider auch nicht weiter geholfen.

Code: Alles auswählen

root@YY:~# rdiff-backup /home/XX /media/XX/Expansion/XX-backup-2023-12-02
WARNING: this command line interface is deprecated and will disappear, start using the new one as described with '--new --help'.
NOTE: Starting mirror from source path /home/XX to destination path /media/XX/Expansion/XX-backup-2023-12-02
Traceback (most recent call last):
  File "/usr/bin/rdiff-backup", line 33, in <module>
    sys.exit(load_entry_point('rdiff-backup==2.2.2', 'console_scripts', 'rdiff-backup')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/rdiffbackup/run.py", line 37, in main
    sys.exit(main_run(sys.argv[1:]))
             ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/rdiffbackup/run.py", line 105, in main_run
    ret_val |= conn_act.run()
               ^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/rdiffbackup/actions/backup.py", line 159, in run
    backup.mirror_compat200(
  File "/usr/lib/python3/dist-packages/rdiff_backup/backup.py", line 39, in mirror_compat200
    DestS.patch(dest_rpath, source_diffiter)
  File "/usr/lib/python3/dist-packages/rdiff_backup/backup.py", line 197, in patch
    ITR(diff.index, diff)
  File "/usr/lib/python3/dist-packages/rdiff_backup/rorpiter.py", line 146, in __call__
    last_branch.fast_process_file(*args)
  File "/usr/lib/python3/dist-packages/rdiff_backup/backup.py", line 599, in fast_process_file
    tf = mirror_rp.get_temp_rpath(sibling=True)
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/rdiff_backup/rpath.py", line 1095, in get_temp_rpath
    return self.get_parent_rp().get_temp_rpath()
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/rdiff_backup/rpath.py", line 1121, in get_temp_rpath
    if not tf.lstat():
           ^^^^^^^^
AttributeError: 'str' object has no attribute 'lstat'

Herzliche Grüße

Neanderthaler

PS: Ich nutze ein aktuelle Debian 12.2

[kalle123]

Und, was sagt

WARNING: this command line interface is deprecated and will disappear, start using the new one as described with '--new --help'.

denn?

[heisenberg]

Wenn ich danach suche, finde ich Debian Bugreports 310442 (2005) und 397161 (2006) und auf github: https://github.com/rdiff-backup/rdiff-backup/issues/850 (Opened: 02/2013 Closed: 02/2023)

Mit der Reaktion:

Congratulation, you've discovered a two years old bug! This said, it appears only when the target file system is full, so you have another issue.

D. h. wenn ich das richtig verstehe, ist das ein Fehler - der mittlerweile gefixt wurde - wobei das Zielverzeichnis (=Dateisystem des Backuparchivs) voll ist und deswegen irreparabel beschädigt wurde. Der Zeitpunkt des Fixes müsste eigentlich 2012 gewesen sein, weil der obige Kommentar aus 2014 stammt.

Lösung

Lösche Deine Backupdaten und starte mit leerem Backupverzeichnis erneut. Da Du jetzt ein aktuelles Debian hast, ist der Fehler vermutlich mittlerweile in Deiner aktuellen rdiff-backup - Version behoben. Sicherheit darüber würdest Du erlangen, wenn Du prüfst in welcher Version von rdiff-backup genau der Fehler gefixt wurde und welche Version aktuell bei Dir lokal läuft. Im Zweifelsfall wäre es vermutlich gut, dafür zu sorgen, dass bei rdiff-backup das Dateisystem nie voll läuft.

Nachtrag

Da gab es wohl 2019 noch einen Fix dazu. Ist also doch nicht so alt, wie oben steht. Fixed Version müsste rdiff-backup 2.2.4 (02/2023) sein.
Aktuelle Version in Debian Stable (Bookworm) ist rdiff-backup 2.2.2 (10/2022). D. h. der Fix ist noch nicht in Debian angekommen. Auch in keinem anderen Release ist eine neuere Version vorhanden. Der Fix kommt also in absehbarer Zukunft nicht an und das scheint also grundsätzlich einen Totalschaden im Backuparchiv zu verursachen, wenn das Dateisystem da vollläuft und man greift auf das Backuparchiv schreibend zu.

https://github.com/rdiff-backup/rdiff-b ... d00965105a

[neanderthaler]

Hallo Zusammen,

vielen dank für die Antworten. Die externe Festplatte ist eigentlich nur zu 75% gefüllt. Da hätte ein weiteres Backup eigentlich noch locker Platz gehabt. Ich habe jetzt eine fast leere angeschlossen und ein neues Backup gestartet. Da ist als Fehlermeldung wieder die Zeile

Code: Alles auswählen

WARNING: this command line interface is deprecated and will disappear, start using the new one as described with '--new --help'.

gekommen plus einige Zeilen mit Hinweisen was nicht supportet wird und welche Dateien nicht gesichert werden können. So verstehe ich zumindest die Meldungen.

Bei

Code: Alles auswählen

rdiff-update --new --help

wird mir eine Liste mit Argumenten angezeigt, wobei keines davon so aussieht, dass es mir weiterhelfen kann. Das ist nach den Hinweisen von heisenberg wohl auch nicht möglich.

Kann man sich gegenwärtig auf rdiff-backup Version 2.2.2 als Backup-Programm verlassen. Oder sollte man auf ein anderes wechsel. Wenn ja, auf welches?

Herzliche Grüße

Neanderthaler

[heisenberg]

Bei...

Code: Alles auswählen

rdiff-backup --new --help

...wird mir eine Liste mit Argumenten angezeigt, wobei keines davon so aussieht, dass es mir weiterhelfen kann.

Wenn ich nach der Fehlermeldung ...

WARNING: this command line interface is deprecated and will disappear, start using the new one as described with '--new --help'

... suche, dann ist die Ursache dafür - grob gesagt - dass der Server auf der anderen Seite eine neuere Version hat, als der Client, von dem aus rdiff-backup gestartet wird. Das scheint mir jetzt nicht absolut problematisch zu sein. Ich würde vermuten, die Warnung, könnte man ohne weitere Maßnahmen auch einfach so hinnehmen. Wenn auf der Remote-Seite dann mal irgendwann ein Update von rdiff-backup durchgeführt wird, dann wird aus der Warnung irgendwann mal ein Fehler und dann wird man handeln müssen.

Falls man das lösen möchte, wäre die Lösung dafür also entweder eine neuere Client-Version einzusetzen (abseits von Debian-Paketen), oder die neuere API-Version explizit zu konfigurieren, mit diesen Kommandozeilenoptionen vermutlich (ungetestet):

Code: Alles auswählen

rdiff-backup --new --api-version 201 [ ... weitere Optionen ... ] 

Kann man sich gegenwärtig auf rdiff-backup Version 2.2.2 als Backup-Programm verlassen?

Keine Ahnung. Ich benutze es nicht. Aber ich gehe davon aus, dass das schon grundsätzlich gut ist. Das Projekt scheint länger brach gelegen zu haben, aber seit einiger Zeit gibt es wohl wieder jemanden, der sich um die Weiterentwicklung kümmert.

Oder sollte man auf ein anderes wechsel. Wenn ja, auf welches?

Mein Präferenzen sind, je nach Einsatzzweck: rsnaphot, borgbackup, backuppc. Kommt halt drauf an, was Deine Anforderungen sind.

[neanderthaler]

Hallo Heisenberg,

danke für deine Erklärungen. Was versteht man in diesem Zusammenhang unter Server und Client? Ich habe hier einen isolierten Rechner der in keinem Netzwerk hängt, wenn man mal von der Internetverbindung absieht. Eine externe Festplatte macht daraus ja noch kein Netzwerk. Daher kann ich die Hinweise auf Server und Client nicht einordnen.

Die von dir genannten Programme werde ich mir mal näher ansehen, danke auch dafür.

Herzliche Grüße

Neanderthaler

[heisenberg]

Was versteht man in diesem Zusammenhang unter Server und Client?

Im Kontext von rdiff-backup ist, wenn Du rdiff-backup auf Deinem Datensicherungssystem ausführst, und die Daten über dieses Kommando holst, dann ist in dem Fall dein Datensicherungssystem der Client, weil es das Programm startet und das System, auf das rdiff-backup über das Netzwerk zugreift, dann der Server, weil es diese Möglichkeit oder den Service bereitstellt, darüber Daten via rdiff-backup abzurufen.

Ich bin mir allerdings noch nicht sicher, wie rdiff-backup genau funktioniert. Bis jetzt gehe ich davon aus, dass man auch auf dem zu sichernden System einen rdiff-Dienst installieren muss? Oder geht das über SSH?

Auf der anderen Seite kann man Dein Datensicherungssystem auch allgemein als "Backupserver" bezeichnen, weil es die Datensicherung für Deine Umgebung erledigt.

[neanderthaler]

Mein Sicherungsmedium ist via USB mit dem Rechner verbunden. Ich habe da nichts installiert, außer wenn das rdiff-backup bei dem von mir eingegebene Befehl automatisch macht. Ich kann mir nicht vorstellen das da die Verbindung via SSH aufgebaut wird. Ich kenne mich mit dem Programm aber nicht wirklich aus. Vor Jahren habe ich mir das notwendigste im Kofler angelesen. Das hat mir bei einem Datenverlust auch anstandslos mein elektronisches Archiv gerettet.

[AxelMD]

Hallo Forum,

heute habe ich gleiches Problem erlebt.

https://github.com/rdiff-backup/rdiff-backup/issues/925

northnose commented on Sep 23, 2023
@ericzolf #922 is about a local operation. This is about a remote operation where the remote does not support api version 201. Are you saying this is a wontfix and there will not be a way to silence this warning?

@ericzolf
Member
ericzolf commented on Sep 23, 2023
Correct.

Was ist ein wontfix Bug?

Kann ich rdiff-backup weiter "sicher" nutzen, ist es nur ein Schönheitsfehler?

Was passiert mit wontfix Bugs? viewtopic.php?t=181808

Trotz des Threads habe ich es nicht verstanden.

Erklärt es mir jemand, danke.

MfG
AxelMD

[niemand]

Was ist ein wontfix Bug?

Nomen est omen: Will not fix

Was passiert mit wontfix Bugs?

Nichts.

[AxelMD]

https://github.com/rdiff-backup/rdiff-b ... 1714482025

Stupid error on my side, sorry for this, but I won't fix it. It'll disappear with the next version.

Wann fliegt so ein Paket aus den Debian Sourcen?

Kann ich rdiff-backup weiter "sicher" nutzen, ist es nur ein Schönheitsfehler?

[niemand]

Kann ich rdiff-backup weiter "sicher" nutzen, ist es nur ein Schönheitsfehler?

Du hast den Bugreport doch selbst verlinkt – hast du ihn denn nicht gelesen?

Wann fliegt so ein Paket aus Debian Sourcen?

Beim nächsten Releasewechsel.

[juribel]

Meine erste Wahl für die Datensicherung ist ein Skript mit rsync. Es gibt dazu im Ubuntu-Wiki einen guten Artikel: https://wiki.ubuntuusers.de/Skripte/Backup_mit_RSYNC/. Dort wird ein Skript vorgestellt, das ich für mich übernommen, abgespeckt und angepasst habe.

Während die Erstsicherung auf eine USB-SSD zweieinhalb Stunden lief, dauern die nachfolgenden Tagessicherungen so zwischen 2 und 4 Minuten. Für jede Tagessicherung wird ein Tagesordner angelegt, der aus Benutzersicht eine komplette Sicherung darstellt, dank hard links trotzdem absolut Platz sparend.

Hauptvorteil von rsync: um die Daten zu verwenden oder zurückzuspeichern, sind ausser einem Dateimanager oder dem "cp"-Befehl keinerlei Tools erforderlich. Die Sicherung ist "datei-inkrementell": geänderte Dateien werden 1:1 kopiert, unveränderte Dateien werden gelinkt.

[AxelMD]

Beim nächsten Releasewechsel.

Auch bei einem Bug der nicht sicherheitskritisch und nur als Schönheitsfehler zu betrachten ist?

Den Bug scheint es schon länger zu geben.

https://packages.debian.org/bookworm/rdiff-backup

Das Paket ist noch drin.

@juribel
Mit Rsync habe ich schon öfter angefangen, bin dann aber immer bei rdiff-backup hängen geblieben.
Zeigst Du mir deine Scriptvarainte dort? ----> viewtopic.php?p=1360907#p1360907
Danke

[niemand]

Auch bei einem Bug der nicht sicherheitskritisch und nur als Schönheitsfehler zu betrachten ist?

Gerade bei einem Bug, der keinerlei Auswirkung auf die Sicherheit hat. Warum sollte man für eine popelige Meldung von der üblichen Vorgehensweise, keine neuen Versionen in ein Release aufzunehmen, abweichen und das Paket ersetzen? So wichtig ist das nun wirklich nicht.

Oder meintest du das Paket selbst, und nicht nur die betroffene Version? Es sollte klar sein, dass ein Paket wegen eines kleinen Bugs nicht rausfliegen wird. Davon ausgehend, dass keine Software mit einem Umfang von mehr als ein paar Zeilen Code fehlerfrei sein kann, wär’s sonst auch ziemlich leer in den Repos …

[juribel]

@AxelMD: In dem anderen Thread habe ich noch ein paar Takte dazu geschrieben.

Nicht dass ich es für mich behalten wollte, aber es ist mittlerweile ein Perl-Programm geworden (mit rsync natürlich), und so sehr auf meine Belange zugeschnitten, dass es für die Allgemeinheit oder zum Verständnis kaum etwas beitragen kann.