Datensicherung - Speicherplatz wird nicht freigegeben

[b1tchnow]

(...)wie vor für wichtig, dass die Synchronisierung auch die Löschungen einschließt. Und wie schon gesagt: Ein normales rsync-Shellskript arbeitet auch so.

Das stimmt so einfach nicht! Auch rsync wird parallel liegende Verzeichnisse in Ruhe lassen, sofern nicht das Oberverzeichnis synchronisiert wird und Mirroring aktiviert ist!

Folgender Dateibaum:

Host 1:
A
|-B
|-C

Host 2:
BKP

Konfiguration a auf Host 1: Kopiere 1:A/B nach 2:BKP und 1:A/C nach 2:BKP

Resultat:

Host 1:
A
|-B
|-C

Host 2:
BKP
|-B
|-C

Konfiguration b (zeitlich nach a) auf Host 1: Kopiere 1:C nach 2:BKP

Resultat:

Host 1:
A
|-B
|-C

Host 2:
BKP
|-B
|-C

2:BKP/C wird aktualisiert, 2:BKP/B bleibt wie es ist!

Warum sollte hier was gelöscht werden???

Und genau das ist das hier von tobi-75 genannte und gezeigte Beispiel! Löschen würde nur funktionieren, wenn Mirroring aktiviert ist und nicht A/B und A/C einzeln sondern A synchronisiert wird.

Ist der Unterschied zwischen diesen beiden Konfigurationen klar:



Links wird A oder B gelöscht, falls "Gesicherte Dateien am Zielort immer beibehalten" deaktiviert ist, und A oder B irgendwann wieder aus dem Backup entfernt werden, rechts nicht!

Ich verzweifle gerade ein bisschen an dieser Diskussion. Das ist doch nicht so schwer und die Erwartungshaltung von tobi-75 ist einfach falsch!

 

[dil88]

Könnte es sein, dass Du meinen Beitrag 18 nicht gelesen hast? Da steht genau das, was Du geschrieben hast. Und darauf bezieht sich Beitrag 20, den Du zitierst.

 

[b1tchnow]

Könnte es sein, dass Du meinen Beitrag 18 nicht gelesen hast? Da steht genau das, was Du geschrieben hast. Und darauf bezieht sich Beitrag 20, den Du zitierst.

Stimmt, habe ich überlesen.

In dem in Beitrag 18 genannten Stenario hat dann rsync ein Problem, denn mit Deselektieren einzelner Unterverzeichnisse eines vorher komplett für das Backup gewählten Verzeichnisses hast Du die "Parallelsituation" geschaffen und die deselektierten Verzeichnisse werden wahrscheinlich und folgerichtig nicht gelöscht.
Auf Basis welcher Grundlage sollte das IT-System das aber anders entscheiden können? Dazu müsste eine Historie der Konfiguration geführt werden und das passiert noch nicht.

 

[dil88]

Sowas hinzubekommen, ist mit einem vorherigen Vergleich der Verzeichnisbäume kein Problem. Und genau sowas macht rsync m.E. auch. Wie schon geschrieben: Mein rsync-Shellskript löscht gelöschte Unterverzeichnisse, das habe ich schon überprüft. Ich werde, wenn ich einmal Zeit habe, das auch für die Datensicherung und Time Backup genau untersuchen.

 

[b1tchnow]

Sowas hinzubekommen, ist mit einem vorherigen Vergleich der Verzeichnisbäume kein Problem. Und genau sowas macht rsync m.E. auch. Wie schon geschrieben: Mein rsync-Shellskript löscht gelöschte Unterverzeichnisse, das habe ich schon überprüft. Ich werde, wenn ich einmal Zeit habe, das auch für die Datensicherung und Time Backup genau untersuchen.

Natürlich ist das kein Problem und wenn Du in Deinem rsync-Skript auf Ebene der Verzeichnisse nah weiteren Verzeichnissen suchst und diese vergleichst und ggf. löschst, dann ist das aber eine Eigenheit Deines Skripts und von Haus aus wird rsync das nicht tun und das Backuptool der DS sollte das so auch nicht machen, da man keine Kontrolle mehr über das Löschen hat und es ggf. von der Ausführungsreihenfolge der Jobs abhängt, was man am Ende als Ergebnis hat.

Obiges Beispiel (vereinfachter Code):

Host foo:
A
|-B
|-C

Host bar:
BKP
rsync foo:A/B bar:BKP (1)
rsync foo:A/C bar:BKP (2)

Und wenn jetzt Dein Skript auf Ebene BKP prüft, ob neben dem Zielverzeichnis B oder C noch andere Verzeichnisse liegen und diese ggf. löscht, hängt es davon ab, ob (1) oder (2) zuerst ausgeführt wird und am Ende B oder C übrig bleibt.

Das kann man machen, sollte aber m. M. n. die Automatik nicht tun!

Per default halte ich es für wirklich falsch, dass auf Ebene des Verzeichnisses A respektive BKP ein Vergleich durchgeführt wird, da ich sonst ungewollte Löschaktionen durchführe und obiges Szenario aus dem Beispiel nicht möglich wäre.

Ich kenne rsync nicht im Detail, kann mir aber gut vorstellen, dass das Verhalten über einen Parameter steuerbar, das Defaultverhalten aber das der passiven Art ist.

Nachtrag: Gesucht und gefunden! Es gibt sogar einen ganzen Stall an Parametern, der dies steuert:

--delete delete extraneous files from dest dirs
--delete-before receiver deletes before xfer, not during
--delete-during receiver deletes during the transfer
--delete-delay find deletions during, delete after
--delete-after receiver deletes after transfer, not during
--delete-excluded also delete excluded files from dest dirs
--ignore-missing-args ignore missing source args without error

Da gibt es sicher noch mehr und was da jetzt im Falle der verschiedenen vorgefertigten Tools auf der DS eingestellt ist, weiß ich nicht. Wäre ich DS-Entwickler würde ich es aber passiv einstellen, um nicht mit Supportanfragen überrannt zu werden: "Hilfe, mein Backup wurde gelöscht!"

 

[dil88]

Nein, das erledigt rsync, nicht mein Skript.

 

[b1tchnow]

Nein, das erledigt rsync, nicht mein Skript.

Ha, und jetzt hast Du Beitrag 25 nicht aufmerksam genug gelesen.

 

[whitbread]

Heisst für den Alltagsgebrauch also: 1. Gemeinsamen Order leeren, 2. Backup machen (Dateien werden am Ziel gelöscht) 3. Gemeinsamen Ordner löschen.

Bisserl umständlich, aber wenn man es weiss...

 

[dil88]

Ha, und jetzt hast Du Beitrag 25 nicht aufmerksam genug gelesen.

Du änderst Deinen Beitrag nach meinem (oder während ich meinen verfasste) und schreibst dann das hier? Guter Spaß.

Es läuft über den Parameter --delete. Letztlich ist es bei einem Directory-Scan und -Abgleich auch kein Unterschied, ob eine Datei oder ein (Unter-)Verzeichnis an der Quelle fehlt und im Backup noch existiert. Nur die Aktionen, die rsync dann auslöst, dürften sich unterscheiden. Sicherheitshalber nochmal: Ich rede nicht von einem Verzeichnis Deines Typs A, sondern von Typ B und C. Und nochmal: Ich teste nichts in meinem Skript, ich rufe nur rsync mit dem Parameter --delete auf mit ein bisschen Loglogik drumherum. Und Synology wird genau das Gleiche machen, wenn man die Option abwählt, dass Daten behalten werden sollen, wenn sie an der Quelle gelöscht werden.

@whitbread: Ganz genau, das wäre eine Lösung.

 

[b1tchnow]

Und Synology wird genau das Gleiche machen, wenn man die Option abwählt, dass Daten behalten werden sollen, wenn sie an der Quelle gelöscht werden.

Ja, dann haben wir es ja zusammen und es passt auch alles zum von tobi-75 gezeigten Verhalten.

 

[dil88]

Ich habe mir das Thema jetzt einmal genau unter Time Backup angesehen. Unterverzeichnisse, die auf der Quelle entfernt wurden, werden auf dem Backupziel ebenfalls gelöscht.

 

[tobi-75]

Sorry, ich hatte die letzten Tage wenig zeit um mich um das Problem zu kümmern.

Fakt ist jedenfalls das sich - aufgrund meiner Supportanfrage - ein Techniker aus Düsseldorf gemeldet und ein Telefonat angeboten hat.
Dazu ist es leider bisher noch nicht gekommen, wir wollen aber nachher - gegen 17:00 Uhr telefonieren.

Ich berichte dann...