nervendes Problem mit großen Dateien auf RDX kopieren

    QNAP TS-877XU-RP, Alle Firmwareversionen.


    Wir verwenden ein USB RDX um Acronis Backup Image Dateien vom QNAP zusätzlich auf das Wechselmedium zu spiegeln (für Offline außer Haus Backup). Dabei tritt ein sehr nerviges Problem mit dem Überschreiben vorhandener Dateien auf. Der Job ist so eingestellt, dass das Quellverzeichnis 1:1 auf dem RDX gespiegelt wird. Das Ziel ist ein 3TB RDX Medium. In der Quelle liegen derzeit 2.1TB. Sollte also alles passen nur QNAP macht einem da einen Strich durch die Rechnung.


    Eine der Quelldateien ist jetzt > 1TB. Der Syncjob löscht die alte auf dem RDX vorhandene Datei nicht vorher sondern schreibt die neue Datei erst temporär auf das RDX, löscht dann die alte und benennt die neue Datei dann um. Das führt dazu, das der Job aus Kapazitätsgründen abbricht, da nicht noch einmal > 1TB geschrieben werden können. Würde die alte Datei direkt überschrieben/gelöscht werden würde sie locker auf das Medium passen.


    In den Einstellungen des Sync-Jobs kann ich offenbar dieses Verhalten nicht beeinflussen. Gibt es andere Wege, das Problem zu lösen?


    Gruß Andreas

    Das klingt interessant, ich habe noch nie darauf geachtet wie sich das verhält, wüsste aber auch nicht woran ich das ausmachen könnte... Woran siehst du, dass es genauso läuft? Sind die temporären Dateien im Explorer sichtbar?

    Handelt es sich hierbei um einen Sync oder Backup Job?

    Prinzipiell ist das Verhalten aber richtig finde ich, es wäre ja blöd wenn eine Datei im Backup gelöscht wird, bevor die neue Datei erfolgreich übertragen ist. Eine entsprechende Option kenne ich auch nicht.

    Als Workaround könnte ich mir allenfalls einen vorgelagerten Sync vorstellen, der die Datei auf dem RDX löscht, bevor der eigentliche Job (der dann auch ein Sync sein sollte/muss) gestartet wird.

    Es ist ein Sync Job. Solange der läuft siehst Du im Datei-Explorer auf dem QNAP die temporäre Datei. Grundsätzlich ist die Idee ja richtig die alte Datei solange zu behalten, nur in diesem Fall ist es hinderlich. Es tritt dann meist der Fehler -17 oder -50 auf.


    Während ich das so schreibe ist mir ein anderer Ansatz eingefallen, den ich mal teste. Ich habe Acronis jetzt für dieses spezielle Backup so eingestellt, dass es mir einen 250GB Filesplitt macht. Damit sollte es dann gehen. Ich hoffe das diese Einstellung auch für das 2. Ziel (hier das Verzeichnis, das auf das RDX gespiegelt wird) greift. Das werde ich morgen sehen.


    Lösen tut es aber das eigentliche Problem auf dem QNAP nicht. Das existiert schon seit Anbeginn in allen Versionen. Ein Schalter seitens QNAP wäre schön um die Datei wirklich vorher löschen können. Aber da wird mich wohl keiner Erhören.


    Gruß Andreas

    Zitat von AndreasL

    Ich hoffe das diese Einstellung auch für das 2. Ziel (hier das Verzeichnis, das auf das RDX gespiegelt wird) greift.

    Müsste dann ja klappen, der wird ja sicherlich nicht erst ALLE Daten übertragen bevor die alten gelöscht werden.

    Ansonsten halt mit dem vorgelagerten Sync, der einen leeren Ordner synct und die vorhandene Datei somit löscht. Der eigentliche Job startet dann in Abhängigkeit von dem "lösch-Sync", das ist ja einstellbar.

    Zitat von AndreasL

    Aber da wird mich wohl keiner Erhören.

    Einfach mal ein Feature Request stellen. Kann mir schon vorstellen, dass mancher User früher oder später in das gleiche Problem rennt.

    Zitat von tiermutter

    Ansonsten halt mit dem vorgelagerten Sync, der einen leeren Ordner synct und die vorhandene Datei somit löscht. Der eigentliche Job startet dann in Abhängigkeit von dem "lösch-Sync", das ist ja einstellbar.

    Das ist auch eine Interessante Idee. Manchmal muss man echt um die Ecke denken. Das werde ich auf jeden Fall im Hinterkopf behalten wenn mein Ansatz mit dem Splitt nicht geht. Danke.


    Gruß Andreas

    Hätte nur den Nachteil, dass die Datei auch dann übertragen wird, wenn sie mal nicht geändert wurde... falls es diesen Fall überhaupt geben kann...

    nein, passiert nicht. Es werden immer alle Dateien gespiegelt da die Images von 5 Servern täglich neu erzeugt werden. Da ist noch etwas Kleinkram aber all das zusammen ist kein Gigabyte groß.

    Schon das zugrunde liegende rsync erstellt eine temporäre Kopie, die erst nach erfolgreichem Kopiervorgang umbenannt werden. Bei rsync kann man dieses Verhalten mit --inplace abstellen, aber davon macht Qnap keinen Gebrauch.


    Meiner Ansicht nach ist es absolut richtig, dass Qnap darauf verzichtet, Dateien ohne Kopie zu übertragen. Es besteht sonst die Gefahr, dass die Daten inkonstistent sind. Genaugenommen besteht nicht nur die Gefahr, sondern sie sind eine Zeit lang garantiert inkonstistent. Die Frage ist nur, ob dies zu Problemen führt. Wenn während des Sync-Vorganges auf die Zieldaten zugegriffen wird, sei es durch ein Anwendungsprogramm, sei es durch einen weiteren Backup-Job, dann ist diese Frage zu bejahen. Auch die Man-Pages zu rsync warnen davor.


    Ich verstehe auch nicht, warum gerade hier Festplattenplatz gespart werden soll. Ansonsten wird massig "ungenutzte" Kapazität für Raids verbraucht, aber hier, wo definitiv ein zeitweise inkonsistenter Zustand vorliegt, soll unbedingt Platz gespart werden.


    Ansonsten, falls du unbedingt Platz sparen willst und die Daten nicht so wichtig sind oder die Konsistenz anders gesichert werden kann, würde ich wie folgt vorgehen:

    - Die große Datei nicht mehr syncen, d. h. das Verzeichnis aus dem Sync-Job rausnehmen

    - Die Datei anders kopieren, z. B. mit einem Skript, welches von cron aufgerufen wird

    - Dieses Skript kann dann auch gleich die Datenkonsistenz sicherstellen, z. B. indem nach erfolgreicher Übertragung eine Dummy-Datei geschrieben wird.

    - Die weitere Verarbeitung der großen Datei muss den Konsistenz-Marker des Skriptes beachten.

    Es geht nicht um Platz sparen. Das zugrunde liegende Problem ist das RDX Medium mit 3TB Kapazität. Die Freie Kapazität ist, nachdem alle alle Dateien kopiert sind, 900GB, 2.1TB belegt. Also fast 1/3 frei. Wächst nun die eine große Datei im Quell-Verzeichnis über die Grenze des freien Speichers, schlägt dieses Verhalten überraschend zu und man wundert sich warum es nicht geht und der Sync-Job mit Fehlern abbricht. Hier in diesem Beispiel pendelt die Backupdatei zwischen 850GB und 1,2TB. Solange sie kleiner ist als der freie Speicher auf dem RDX geht alles problemlos obwohl rein Rechnerisch sogar eine eine Datei mit fast 2TB drauf passen würde.


    Es nützt auch nicht für diese eine Datei einen eigenen Job zu machen, das ändert an dem Problem nichts.


    Unter Windows ist man es anders gewohnt, da wird die Datei direkt überschrieben und es geht immer solange der die gesamte Kapazität des Zielmediums nicht überschritten wird.


    Ich versuche derzeit das Problem an der Quelle zu packen und die Sicherungssoftware der Server (Acronis) davon zu überzeugen die Backupfiles zu splitten und in kleinere Parts (250GB) aufzuteilen. Damit wäre mein Problem gelöst. Leider ignoriert der Backupjob derzeit meine Einstellung aber das ist eine andere Baustelle.


    Gruß Andreas