≡ Menü

RSnapshot Backup Fehler „failed to preserve ownership“

Mit Entsetzen habe ich gestern feststellen dürfen, dass das tägliche Backup meines Linux-Servers seit ein paar Tagen Fehler im Logfile produziert. Das ist um so schlimmer, da genau dieser Server ja die Grundlage für meine eigene kleine Cloud ist. Nach eifriger Suche im Netz, habe ich die Ursache und eine Lösung für das Problem gefunden.

Der Fehler

Seit dem 29.10.2013 kann ich folgende Meldung in meinen Logfiles und den Statusmails beobachten:

failed to preserve ownership for '<hier ein Filename>': Invalid argument

Oder, auf deutsch:

/bin/cp: konnte den Eigentümer für '<hier ein Filename>' nicht erhalten: Das Argument ist ungültig

Eigentlich hätte ich das viel früher bemerken müssen, aber wenn über Monate alles gut geht, liest man die täglichen Mails wohl eben doch nicht immer so genau. Vor Allem, wenn sich am System, bzw. der Konfiguration des Linux-Servers gar nichts geändert hat.

Um zu verstehen, was diesen Fehler auslöst und wie man ihn umgeht, muss ich kurz auf die Art des Backups eingehen, die hier betroffen ist.

Das Backup

Ich werde demnächst in einem meiner Cloud-Artikel genauer beschreiben, wie die Einrichtung und Konfiguration meines Backups aussieht. Hier nur so viel:

Ich setze für das tägliche Backup RSnapshot ein. Letztlich handelt es sich dabei um ein auf rsync basierendes File-Backup, dass per Cron stündliche/tägliche/wöchentlich oder auch monatliche differentielle Backups erzeugt.

In meinem Fall schreibe ich die Backups auf ein per NFS gemountetes Volume auf meinem Synology NAS.

Detektivarbeit

Warum also gibt es jetzt plötzlich Fehler, die vorher nicht aufgetreten sind? Irgendetwas muss sich wohl geändert haben. Aber was? Und was bedeutet dieser Fehler denn überhaupt?

Das Log unter /var/log/rsnapshot.log wirft folgende Frage auf:

ERROR: /bin/cp -al /mnt/Backup/daily.0 /mnt/Backup/daily.1 failed (result 256, exit status 1).  Perhaps your cp does not support -al options?

Das heißt, hier werden Hardlinks erzeugt, statt tatsächlich die Dateien zu kopieren, wenn sich nichts geändert hat. Nach einem kurzen Test mit

cp -al /home/karsubke/Datei1.txt /home/karsubke/Datei2.txt

kann ich aber ausschließen, dass „cp“ die Option „-al“ nicht versteht.

Aber:

Führt man den gleichen Befehl testweise in den von RSnapshot angelegten Verzeichnissen aus, taucht der Fehler tatsächlich wieder auf!

Meine erste Vermutung war jetzt, dass ein Debian-Package – ich spiele alle paar Tage die verfügbaren Updates ein – die Probleme verursacht. Die Wahrscheinlichkeit ist zugegebener Maßen gering, da ich keine stabilere Linux Distribution kenne, als Debian. Und zu dem Zeitpunkt um den 29.10. herum habe ich keine Updates eingespielt.

Ach ja… Einen Reboot/Neustart aller beteiligten Komponenten, also Server, Synology, etc.pp. habe ich natürlich auch gemacht 😉

Nach ein wenig Überlegung ist mir noch etwas eingefallen, das sich ungefähr in dem Zeitraum geändert haben könnte. Es gab nämlich eine neue Version des Synology Disk Station Managers und damit auch System-Updates. Ein Blick ins Synology Log bestätigte diese Vermutung. Just am 29.10. habe ich das Update eingespielt. Das ist wohl kaum ein Zufall.

Lösung: NFS

DuckDuckGo hat noch einiges an Suchanfragen schlucken müssen, bevor ich herausgefunden habe, was das eigentliche Problem ist und wie man es löst. Den entscheidenden Hinweis habe ich einem Post im Synology-Forum entnehmen können, der eine zumindest ähnliche Meldung im Wust des eigentlich dort behandelten, anderen Problems versteckt.

Die cp-Fehlermeldung führt dem ersten Anschein nach in die Irre. Das eigentliche Problem ist, dass beim anlegen des Backups alle Dateien ihren ursprünglichen Owner behalten sollen, beim cp also noch ein chown ausgeführt wird. Und genau der geht schief. Das erklärt auch den Text der Meldung.

Schuld daran ist, dass mit dem Synology Update auch die Unterstützung für NFS v4 mit auf das NAS gewandert ist (siehe z.B. das Synology Changelog der DS411j für die Version DSM 4.3-3776). Beim mount des Volumes nutzt Linux die vom mount-Ziel angebotene, höchste Version des NFS, die es findet. Das war vor dem Update v3, nach dem Update aber v4!

Und irgendetwas muss in der Implementierung krumm sein. Ob nun Debian oder Synology den schwarzen Peter hat, mag ich nicht beurteilen.

Fakt ist, das es hilft, wenn man beim mount, zum Beispiel in der /etc/fstab, explizit NFS v3 angibt/nutzt:

diskstation:/volume1/SystemBackup      /mnt/Backup        nfs     rw,<strong>vers=3</strong>       0       0

Anschließend ließ sich der Fehler von mir nicht mehr nachvollziehen und mein RSnapshot-Backup läuft wieder sauber und ohne „Mullen und Knullen“ durch 😀

Fazit

Es bleibt nun abzuwarten, wer mit welchem Update den vermeintlichen Bug behebt. Vorerst kann ich aber gut damit leben, die ältere Version 3 des Network File System zu verwenden.

{ 4 comments… add one }
  • Rainer 16. Juli 2015, 18:34

    Wow, das hat mir einige Stunden Recherche gespart!

    Danke Geiststreicher!

  • Torsten M 12. Juli 2016, 12:34

    Jawollja, selbst wieder ein Jahr später hat mich dieser Effekt erreicht und ich mir über Nacht die Finger wund verkonfiguriert.
    Vielen Dank, weitere Zeitverbrennung ist dadurch behoben! Super 🙂

  • Simon 25. April 2017, 19:47

    DAAANKE!

    Ich fertige Backups meines Ubuntuservers auf ein Synology NAS an und habe mir einen Wolf gesucht. Perfekt! Einfach NFSv4 ausgemacht und es läuft wie’s Lottchen!

  • Thomas 24. April 2022, 10:31

    Auch von mir ein Danke – 2022 besteht das Problem immer noch.

    Nachdem es Dank dieses Beitrags gleich geklärt war, habe ich noch etwas Zeit in die Recherche gesteckt.
    Ursache ist offenbar, das NFSv4 bei den übermittelten uid/gid prüft, ob es diese überhaupt gibt – und das dürfte beim NAS nicht der Fall sein.
    Siehe z.B.: https://ervikrant06.wordpress.com/2015/06/09/how-to-chown-command-work-using-nfsv4/

Trackbacks

Cancel reply

Leave a Comment

*