BackInTime erzeugt auf NAS keine hardlinks für unveränderte Dateien

    Meine verwendeten Geräte: PC mit Linux Mint (akt. Version) als Backup-Quelle und ein QNAP TS-133 als Ziel der Backups.


    Mein Problem: Zum Sichern meines home-Verzeichnisses auf das NAS nutze ich die Backup-Software BackInTime, die wiederum auf rsync basiert. BackInTime kopiert eigentlich bei jedem Snapshot nur die veränderten Dateien zum Ziel. Für die unveränderten Dateien wird einfach ein hardlink auf die Datei im letzten Snapshot geschrieben.

    Wenn das Ziel auf einer lokalen Platte liegt, funktioniert das genau so. Wenn das Ziel auf dem NAS liegt, dann werden jedesmal alle Dateien übertragen und keine hardlinks genutzt.


    Mir fehlt da eine Idee, woran das liegen könnte. Kann es irgendwas mit Rechte-Vergabe sein? Aber schreiben kann ich ja, nur keine hardlinks setzen.


    Ein Tipp wäre nett!

    Ich sehe das Problem jetzt weniger beim NAS, sondern eher bei der Quelle... und hier sieht es ja ähnlich aus:

    Zitat von Linuxmint Forum

    Im Prinzip hast du keinen Fehler gemacht, nur rsync überfordert.
    rsync kann auf dem Dateisystem deines NAS keine Hardlinks erzeugen.

    ... wobei ich dem nicht ganz Traue...


    Testweise mal mit dem User admin probiert?

    Was macht Dich so sicher, dass es nicht wirklich Hardlinks sind? Weil...

    Zitat von Walltraube

    dann werden jedesmal alle Dateien übertragen

    ... bedeutet ja nicht, dass separate Dateien geschrieben werden...


    Anthracite wäre hier sicherlich hilfreich

    Man ruft mich?


    Bei mir läuft Back-in-Time einwandfrei. Hardlinks werden genutzt wie sie sollen. Ich habe Kubuntu im Einsatz, nicht Linux Mint, aber das sollte keinen Unterschied machen.


    Den User Admin braucht es nicht. Ich habe einen eigenen User nur für das Backup angelegt. Auf dem PC muss Back-in-Time von Root aufgerufen werden (wird in der .desktop-Datei zum Programmsymbol eingestellt), da sonst kein Zugriff auf alle lokalen Dateien besteht.


    Ob Hardlinks geschrieben werden, kann man leicht prüfen, wenn man sich eine beliebige Datei (kein Verzeichnis) im Backupverzeichnis anschaut, z. B. hier:

    Code
    ls -l
-rwxr-xr-x 29 backup-user everyone 2703156 2023-06-23 09:52 HG-JKA_2172.jpg

    Es gibt 29 Hardlinks auf diese Datei, und das passt, weil ich 29 Backupstände habe.


    Die Anmeldung von Back-in-Time läuft bei mir über einen privaten ssh-Schlüssel mit RSA. Der Schlüssel hat keine Passphrase, funktioniert sonst nicht mit der Speicherung derselben in Back-in-Time. (Daher sollte auf dem NAS ein eigener Benutzer genommen werden, der keine weiteren Rechte außer Lese-und Schreibberechtigung auf das Backup-Verzeichnis hat sowie eine Anwendungsberechtigung für den FTP-Server.)

    Zitat von Anthracite

    Die Anmeldung von Back-in-Time läuft bei mir über einen privaten ssh-Schlüssel mit RSA. Der Schlüssel hat keine Passphrase, funktioniert sonst nicht mit der Speicherung derselben in Back-in-Time. (Daher sollte auf dem NAS ein eigener Benutzer genommen werden, der keine weiteren Rechte außer Lese-und Schreibberechtigung auf das Backup-Verzeichnis hat sowie eine Anwendungsberechtigung für den FTP-Server.)

    Da ist offensichtlich so einiges anders, als ich das mache:

    In den Einstellungen von BackInTime verwende ich Modus: Lokal und Speicherort für Schnappschüsse: /media/QNAPbackup und habe dementsprechend dieses Zielverzeichnis in der /etc/fstab gemountet mit:

    Code
    //192.168.0.190/Backups /media/QNAPbackup cifs _netdev,rw,credentials=/home/wal/.smbQNAPbackup 0 0

    Der user in .smbQNAPbackup ist der owner des Zielverzeichnisses bzw. Freigabeordners Backups, der in ssh unter /share/Backups zu erreichen ist.


    Egal ob ich mit ls -i nach den inode-Nummern suche und diese für unveränderte Dateien über die Snapshots hinweg vergleiche oder mit ls -l die Zahl der hardlinks anschaue: da sind leider keine zu finden.


    Anthracite

    Muss ich für ein Sichern vom PC auf das NAS in BackInTime den Modus SSH bzw. SSH verschlüsselt verwenden oder ist das nur eine andere Art der Verwendung von BackInTime?

    Und wozu dient in diesem Zusammenhang der FTP-Server? Meines Wissens nutzt BackInTime rsync und das hat sein eigenes Übertragungsprotokoll, nutzt also kein FTP.

    (Mein NAS wird nur lokal verwendet und ist vom Internet getrennt. Verschlüsselung bei der Übertragung ist da wohl nicht so wichtig.)

    Zitat von Walltraube

    Muss ich für ein Sichern vom PC auf das NAS in BackInTime den Modus SSH bzw. SSH verschlüsselt verwenden oder ist das nur eine andere Art der Verwendung von BackInTime?

    Ob du lokal über SMB gehst oder über ssh, das sind erst einmal nur zwei verschienene Arten. "lokal" ist gedacht für die Backups auf demselben Rechner, einschließlich gemounteter Freigaben, "ssh" für Backups auf andere Rechner.


    Auf meinem Linux-PC nutze ich Back-in-time mit ssh übrigens auch nur innerhalb des lokalen Netzwerkes. Der Grund, hier ssh statt lokal zu nehmen, war, dass Root - Back-in-Time muss von Root gestatet werden, da sonst lokale Zugriffe fehlen - bei Start des Backups das Backup-Verzeichnis nicht gemountet hat. Ein Backup-Verzeichnis möchte ich aus Sicherheitsgründen, auch wenn Schadprogramme unter Linux selten sind, nicht immer gemountet haben.


    Auf einer Linux-VM, welche auf dem QNAP-NAS läuft, nutze ich hingegen Back-in-Time mit "lokal" auf ein gemountetes Netzlaufwerk. Dort werden die Hardlinks korrekt gesetzt. Allerdings ist das Netzlaufwerk mit nfs gemountet, und das kann einen Unterschied machen.


    Es ist möglich, dass Back-in-Time auf SMB-Freigaben keine Hardlinks setzt. Ich habe das noch nicht ausprobiert. Mounte deine Freigaben mal mit nfs, dann müsste es funktionieren.

    Zitat von Walltraube

    Und wozu dient in diesem Zusammenhang der FTP-Server?

    Gute Frage. Ich kann es dir nicht sagen. Ich hatte beim Schreiben des vorangegangenen Beitrages nur geschaut, welche Rechte der Benutzer hat, Möglicherweise ist das Recht für ftp überflüssig. Probier es aus.

    Zitat von Walltraube

    (Mein NAS wird nur lokal verwendet und ist vom Internet getrennt. Verschlüsselung bei der Übertragung ist da wohl nicht so wichtig.)

    Wenn nicht "lokal" verwendet wird, dann ist nur ssh in der Auswahl, und somit ist die Übertragung immer verschlüsselt, ob man will oder nicht. Das "verschlüsselt" hinter der zweiten ssh-Auswahl bezieht sich nicht auf die Übertragung, sondern die Veschlüsselung im Zielverzeichis.