HBS 3: Datei(en) werden immer und immer wieder nicht zu Ende geschrieben

    Ah.. ok, jetzt wird es schon etwas deutlicher.


    Ich habe seither so um die 12 TB mit einem 11 Jahre alten i7 Laptop erledigt. Ein Raspi 3, der 24/7 wegen Pihole online ist, hat ihn täglich aufgeweckt und somit das Backup angestoßen. lvm2 auf dem Debianbasierten System war ja schnell installiert.


    Suboptimal daran war, dass dieser alte i7 ausschließlich über USB 2 und ausschließlich über Fast Ethernet verfügte.


    Also bin ich umgestiegen auf einen Pi 4 mit 8 GB, 1Gbit und 2 x USB 3: Viel schneller.


    Achtung, jetzt kommt der Aufreger mit dem ich mich disqualifiziere: Ich arbeite tatsächliche gerne :X mit systemd timer units.


    Der Raspi 4 startet automatisch durch eine 9,90 Euro Tapo Steckdose, arbeitet den systemd-timer ab, der den Raspi das eigentliche rsync - Script starten lässt.


    Die rsync Logdatei schreibt er in ein Verzeichnis auf dem NAS, sodass ich täglich kontrollieren kann ob und was er gesichert hat. Danach hängt er sowohl die eigenen LVM, als auch die NAS-Ordner, die er natürlich gemounted hat, aus. Und dann kommt der shutdown -h 0.


    Die 9,90 Euro Tapo schaltet den Strom der 3 HDDs des LVM und den Raspi 4 zeitverzögert nach 1 Stunde wieder ab. Am nächsten Tag gehts wieder von vorne los. Selbst wenn die Stunde mal zu knapp wäre, würde er das unvollendete Backup vom Vortag vervollständigen. Am Anfang waren es 2 Stunden. Heute braucht er aber maximal 10 Minuten.


    Wirklich wichtige Daten wie Dokumente bspw, sichere ich doppelt und dreifach.


    Läuft seit Jahren (inklusive Restore!) absolut zuverlässig, schnell (1 Gbit/ USB 3) und für mich wichtig: Nicht die Quelle startet das Backup und schiebt Dateien auf den Backup-Server, sondern der Backup-Raspi übernimmt die Kontrolle des Backups, holt sich die Dateien.


    [Edit] Dem Backup Raspi habe ich komplett den Ínternetzugang gesperrt, wird regelmäßig für ein update kurz aufgehoben. Ich will auch , dass die Backup-LVM nicht nur via umount vom System getrennt werden, sondern komplett, wie der ganze Raspi vom Strom/LAN getrennt sind. Andere würden mit Sicherheit auch noch die Platten verschlüsseln. Warum auch nicht!? Ich mach es halt nicht. [/EDIT]

    2 Mal editiert, zuletzt von eol92 ()

    ich hatte schoneinmal ähnliche Probleme beim Backup mit Qnap, da lag es an einem insgesamten zu langen Dateipfad, und zusätzlichem langen Dateinamen ;)

    Mod: Unnötiges Volltext-/Direktzitat entfernt! :handbuch::arrow: Forenregeln beachten und Die Zitat Funktion des Forums richtig nutzen


    Das konnte ich hier ausschließen, da eine Datei mit bis auf die Dateiendung identischen Pfad und Dateinamen anstandslos kopiert wurde. Nur die große Datei nicht.


    Eine andere habe ich in 1GB Stücke zerlegt, was den Dateinamen ja jeweils noch größer macht. Die wurden alle kopiert.


    Ich vermute den Fehler am Ziel-WebDAV. Das habe ich zwar ohnehin verworfen,

    aber warum meldet HBS3 keinen Fehler, anstatt unendlich oft zu probieren? 🤷‍♀️ (war 'ne rhetorische Frage ;) )

    Zitat von VoErHei
    [...]

    und für mich wichtig: Nicht die Quelle startet das Backup und schiebt Dateien auf den Backup-Server, sondern der Backup-Raspi übernimmt die Kontrolle des Backups, holt sich die Dateien.

    [...]

    Das mache ich jetzt im Moment auch so, aber ich hätte die Kontrolle lieber am QNAP gelassen. Für sowas habe ich ja das NAS.

    Wie dem auch sei, ich bin aus der Testphase noch nicht raus ... ;)

    Einmal editiert, zuletzt von ChristianKnorr () aus folgendem Grund: Ein Beitrag von ChristianKnorr mit diesem Beitrag zusammengefügt.

    Um dem einen Abschluss zu geben: ich habe auf dem QNAP-NAS OpenMediaVault installiert, genau wie auf dem DIY Zweitnas (letzteres nur für Backups).

    Ich sehe dennoch immer noch einen Fehler in HBS 3.


    Tschö ;)