Datensicherung - Speicherplatz wird nicht freigegeben

[tobi-75]

Kann es sein das es einen BUG in der Datensicherung gibt?

Ich habe eine Datensicherungsaufgabe erstellt und die DS hat munter gesichert. Leider hatte ich einen Gemeinsamen Ordner darin der "etwas" größer als der Speicher der Sicherungsplatte war.
Nun ist mir diese "übergelaufen" und hat nur noch wenige MB frei. Ich hab den ganzen Ordner rausgenommen und die Sicherung erneut angestossen - im Glauben das die "Nichteinbindung" dazu führt das der Speicher wieder freigegeben wird. Aber nix passiert.

Werden die Daten in der Sicherung nur gelöscht wenn sich "innerhalb" eines Gemeinsamen Ordners (als bei den Unterordnern) Veränderungen ergeben - also Verzeichnisse oder Dateien gelöscht werden?

Klar kann ich den Ordner in dem Backup-Verzeichnis XYZ einfach löschen - aber mich interessiert ob dieses "Fehlverhalten" bekannt bzw. beabsichtigt ist.

 

[dil88]

Interessante Beobachtung. Wie ist es denn, wenn Du auf der Sicherungsplatte den gemeinsamen Ordner von Hand löschst, den Du aus der Sicherung entfernt hast?

 

[Xygen]

Ich war der Meinung, dass dieses Verhalten nur dann auftritt, wenn man unter "Task Settings", die Option "Reserve the backed up files at the destination" aktiviert hat.
Schau doch mal bitte, was Du dort aktiviert hast.

 

[tobi-75]

Tja genau diesen Haken habe ich bewusst NICHT gesetzt - wär er aktiv würde ich es verstehen. ich bin voll bei Dir und glaub(t)e auch das dieses Verhalten nur mit Haken eintreten sollte.



Ich habe jetzt mal einen Unterordner des "Gemeinsamen Ordners" eingebunden (ca. 12 MB). Damit hätte er ja "nur" diesen sichern und die "überflüssigen" auch wieder entsorgen müssen. Aber auch hier ist nix passiert.
Den Haken hab ich jetzt mal gesetzt, gespeichert und dann wieder entfernt. Leider auch keine Besserung.

Ich werde mal mit einem weiteren Job testen ob ich das Verhalten nachstellen kann.

 

[Tommes]

Beitrag zurückgezogen, da falsch interpretiert, sorry!

 

[tobi-75]

Hab es jetzt noch ein paar mal durchgetestet. Ob der Haken gesetzt ist oder nicht - völlig wumpe
Es wird immer nur angehängt (als ob der Haken aktiv wäre). Dooooof

Hab die 5.1-5011 U4, frische Installation (ob U4 drin war kann ich jetzt nicht sagen)
Kann das mal einer verifizieren?

Ich habe so getestet:

- Im gemeinsamen Order "G" den Unterordner "U1" ausgewählt, die Maria-DB, Photo und DS Note als Anwendung ebenfalls. KEINEN Haken
- Sicherung gemacht, Es gibt U1 und photo.
- Im gemeinsamen Order "G" den Unterordner "U2" ausgewählt, die Maria-DB, Photo und DS Note als Anwendung ebenfalls. KEINEN Haken
- Sicherung gemacht, Es gibt U1,U2 und photo.

Es ist wohl auch egal ob Anwendungen dabei sind - er hängt immer an.

---------------------------------------------
Nachtrag: offensichtlich "ignoriert" er nicht aktive Ordner - egal ob Unterordner oder gemeinsame Ordner. Passiert etwas unterhalb eines ausgewählten wird auch gelöscht, wird der Ordner "herausgenommen" wird er halt ignoriert. Ob das jetzt ein Bug oder Feature ist muss ich für mich noch definieren - zumindest höchst verwirrend.

 

[Tommes]

Nachtrag: offensichtlich "ignoriert" er nicht aktive Ordner - egal ob Unterordner oder gemeinsame Ordner. Passiert etwas unterhalb eines ausgewählten wird auch gelöscht, wird der Ordner "herausgenommen" wird er halt ignoriert. Ob das jetzt ein Bug oder Feature ist muss ich für mich noch definieren - zumindest höchst verwirrend.

Genau dieses Verhalten konnte ich bei mir grade auch nachstellen. Ich hatte nämlich noch einen "alten" gemeinsamen Ordner, den ich irgendwann mal aus dem Backupjob entfernt hatte. Dieser war im Ziel jedoch noch immer vorhanden und mit Daten gefüllt. Da in der Quelle der besagte Ordner jedoch keine Daten mehr enthielt, im Ziel aber schon, habe ich ihn einach mal wieder in den Backupjob aufgenommen und siehe da... im Ziel waren alle Dateien gelöscht.

Ich kann es zwar nicht genau beantworten, halte dieses Verhalten aber eigentlich für ein Feature bzw. für eine Schutzfunktion der eigenen Blödheit. Ob das leztendlich so gewollt ist oder nicht, kann dir wohl nur Synology beantworten. Vielleicht schilderst du denen mal deine gesammelten Erkenntnisse und schau'st was sie dazu zu sagen haben.

Tommes

 

[dil88]

Für mich ist das ganz klar ein Bug, denn es geht dann, wenn man "Gesicherte Dateien am Zielort immer beibehalten" nicht aktiviert, ja darum, synchrone Datenbestände zu erreichen. Das ist eine ganz wichtige Sache, denn auch Löschen/Aufräumen kann mit viel Arbeit verbunden sein, die ich gesichert wissen will.

 

[tobi-75]

Danke für die Rückmeldung!

Ich sagte ja - ob Bug oder Feature bin ich mir selbst noch nicht sicher. Blöd ist halt nur wenn man den gesamten Ordner mit dem Inhalt aus dem Backup loswerden will - in der Quelle aber alles so bleiben soll. Dachte das ginge so einfach.
Ich hab mal eine Bilderserie erstellt und ein paar "wirre englische frasen" dazu abgegeben (mein englisch ist unterirdisch, da schreibend so selten im gebrauch )

Ich hoffe die können dazu eine Auskunft geben - hab (hoffentlich) klar gesagt das ich wissen ob das so gewollt ist und ob es irgendwo mehr infos dazu gibt.

Can you explain me if this is an bug or exactly that was you are wanted? Where can I read this functionality in detail?

@dil88
Tendenz geht auch eher zu BUG, schon allein deswegen weil ich ja darauf hereingefallen bin

Hier mal mein Versuchsbild das ich auch an Synology geschickt hab (ein Bild sagt meist mehr als tausend - fremdsprachige - Wörter)

 

[Puppetmaster]

Imho werden nur Ordner abgeglichen, die auch im Backupjob originär ausgewählt sind. Werden sie - nach Sicherung - abgewählt, interessiert sich rsync nicht mehr für diesen Ordner und ignoriert ihn - auch im Backup - ganz gleich, welche Häkchen im Backupjob gesetzt sind oder nicht.

In meinen Augen kein wirklicher Bug.

Ich behaupte mal, es würden auch keine Daten aus dem Ziel gelöscht, die du händisch, also nicht über einen Backupjob, dort platziert hast. rsync interessiert sich einfach nicht dafür, weil es keine Quelle dazu gibt.

 

[dil88]

Für einen kompletten gemeinsamen Ordner würde ich Dir noch zustimmen, aber für ein Unterverzeichnis ist das m.E. nicht so. Die Logs meiner eigenen rsync-Skripte bestätigen das.

 

[whitbread]

In meinen schon recht lang laufenden Backups befinden sich auch (gemeinsame) Ordner, die schon längst nicht mehr gibt und daher auch nicht mehr gesichert werden. Hinsichtlich des Speicherplatzes wärs mir egal, aber so wird ja bei der Rücksicherung ein Zustand wiederhergestellt, der nicht dem der letzten Sicherung entspricht. Das ist nicht gut!

 

[Puppetmaster]

Hast du das überprüft oder ist das nur deine Hypothese?

 

[whitbread]

Ist eine Tatsache.

 

[b1tchnow]

Für mich ist das ganz klar ein Bug, denn es geht dann, wenn man "Gesicherte Dateien am Zielort immer beibehalten" nicht aktiviert, ja darum, synchrone Datenbestände zu erreichen. Das ist eine ganz wichtige Sache, denn auch Löschen/Aufräumen kann mit viel Arbeit verbunden sein, die ich gesichert wissen will.

Ich sehe das anders, denn die Option bezieht sich auf Dateien, die Teil des aktuellen Backups sind. Wenn Ordner ausgenommen werden aus dem Backup, die vorhin aber Teil des Backups waren, dann weiß die DS nicht mehr was sie tun soll, wenn diese nicht Teil eines noch ausgewählten Ordners sind und das sind sie nicht(!) im genannten Beispiel!

Ein Beispiel: Backup läuft über die Ordner A und B. Du nimmst nach einem Backup B heraus. Backup startet und bewertet A auf Änderungen, etc. Dabei wird auch die optionale Regel "Gesicherte Dateien am Zielort immer beibehalten" angewandt oder nicht.Was aber nicht passiert, ist, auf dem Zielmedium zu schauen, ob da noch was ist, was nicht Teil des Backups ist und das zu löschen.

Und im grafischen Beispiel von tobi-75 sind Folder A und Folder B keine Unterordner eines gesicherten Ordners, sondern ein Ordner auf gleicher Ebene. So funktioniert rsync nicht.

Noch ein Beispiel: Ordner A enthält Ordner B und C. B und C sind als zu sichernde Ordner definiert. Ein Backup wird erstellt und C wird aus der Backupkonfiguration entfernt. Und jetzt erwartet ihr, dass C auf dem Backup beim nächsten Backuplauf gelöscht wird?

Das wäre meiner Meinung nach fatal falsch!

Stellt euch einen Logmechanismus vor, der tägliche Verzeichnisse erstellt. Auf dem Betriebsrechner werden diese rollierend 10 Tage lang geführt und dann gelöscht. Bei eurem "Feature" würden diese auch aus dem Backup beim nächsten Lauf gelöscht werden.

Wenn ihr wollt, dass C auch im Backup entfernt wird, dann müsst ihr A als zu sicherndes Objekt definieren und dann mit der Option "Gesicherte Dateien am Zielort immer beibehalten" arbeiten. Im Beispiel von tobi-75 muss "testordner" als Backupobjekt definiert sein, dann funktioniert es auch.

Ich verstehe auch das Problem von whitbread, aber ich bin eher für eine defensive Löschstrategie der Automatik, die im Bedarfsfall mehr manuellen Aufwand bei der Wiederherstellung bedeutet, als eine aggressive Löschstrategie, die mir etwas löscht, was ich noch bräuchte.

Die Regel "Aus dem Backup entfernte Ordner werden nicht gelöscht, sofern sie keine Unterordner von noch im Backup befindlichen Ordnern sind" finde ich explizit gut! Sonst kann man z. B. ja auch keine Backups mehrere Quellen an einem Ziel sammeln, wenn das eine Backup von System X alle anderen Backups des Systems Y löschen würde, weil sie auf X nicht existieren.

 

[dil88]

Ich sehe das anders, denn die Option bezieht sich auf Dateien, die Teil des aktuellen Backups sind. Wenn Ordner ausgenommen werden aus dem Backup, die vorhin aber Teil des Backups waren, dann weiß die DS nicht mehr was sie tun soll, wenn diese nicht Teil eines noch ausgewählten Ordners sind und das sind sie nicht(!) im genannten Beispiel!

Für gemeinsame Ordner stimme ich zu, für Unterordner nicht. Aber ich werde das bei mir nochmal überprüfen, wie es sich denn tatsächlich verhält. Das Spekulieren bringt ja am Ende nichts.

 

[b1tchnow]

Für gemeinsame Ordner stimme ich zu, für Unterordner nicht. Aber ich werde das bei mir nochmal überprüfen, wie es sich denn tatsächlich verhält. Das Spekulieren bringt ja am Ende nichts.

Ich gehe davon aus, dass dies für Unterordner nicht gilt!

 

[dil88]

Dann sind wir uns in der Erwartungshaltung ja einig. Ich verstehe aber beispielsweise Beitrag #6 so, dass auch das Deselektieren von Unterverzeichnissen eines gemeinsamen Ordners nicht die Löschung dieser Unterverzeichnisse zur Folge hat. Und das wäre aus meiner Sicht ein Problem, sollte es zutreffen.

 

[Puppetmaster]

Und das wäre aus meiner Sicht ein Problem, sollte es zutreffen.

Darüber kann man trefflich diskutieren. Ein Problem sähe ich z.B. dann darin, wenn es beim Wiederherstellen des Jobs, in dem der Ordner nicht vorkommt, eine Wiederherstellung dieses Ordners gäbe. Ansonsten sehe ich da kein Problem.

 

[dil88]

Für mich ist ein Kriterium für ein gutes Backuptool, dass sich die Daten auch ohne dieses Tool korrekt restaurieren lassen. Deshalb bevorzuge ich Programme, die ins Filesystem sichern. Insofern halte ich es nach 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.