brightbits Support

Hallo,

ich habe auf meiner Backupplatte einige alte Dateien in ebenfalls alten Ordnern gefunden, die es am Originalstandort schon lange nicht mehr gibt. Wie kann ich herausfinden, ob diese Dateien in irgendeiner BSH-Sicherung überhaupt noch referenziert werden? Die älteste existierende Sicherung ist nämlich exakt ein Jahr alt, und in dieser tauchen diese alten Ordner gar nicht mehr auf. Heißt das nun, dass diese alten Dateien verwaist sind, d.h. von keiner BSH-Sicherung referenziert werden? Falls dies so ist, kann ich sie dann einfach auf der Backupplatte löschen, oder gibt es in BSH eine Bereinigungsfunktion für solche Dateien? Ich habe meines Wissens die neueste BSH-Release.

Viele Grüße
tkansgar

Hallo tkansgar,

generell ist vom Löschen von Dateien auf dem Sicherungsmedium abzuraten, da BSH die Ordner und Dateien selbst organisiert. Wenn in der Tat keine Referenzierung in einer Sicherung mehr vorliegt, dann löscht BSH die Dateien automatisch.

Du könntest ja mal die Suche nutzen, um zu sehen, ob die Dateien nicht doch in einer Sicherung noch vorhanden sind. Mit den Schaltflächen "früher" und "später" kannst du dann die Suche auf andere Sicherungen ausweiten.

Hallo Alex,

die mit Abstand größte Zip-Datei auf der Backupplatte ist 18GB groß und vom 11.11.2012. Das Original davon gibt es schon lange nicht mehr, und mit der Suchfunktion des BSH-Backupbrowsers ist sie nicht aufzutreiben, andere ältere große Dateien dagegen schon. Irgendwie scheint die automatische Löschung zumindest dieser Zip-Datei durch BSH nicht zu funktionieren. Oder könnte es sein, dass sie erst nach zwei Jahren also frühestens am 11.11.2014 automatisch gelöscht wird? Falls nicht, kann ich sie gefahrlos selbst löschen?

Im selben Backupordner habe ich noch eine knapp 5GB große Datei gefunden, deren Name auf "-xh4as21q.tmp" endet (also keine Zip-Datei). Kann es sein, dass diese ein Rest einer verunglückten Sicherung ist? Kann ich diese Datei gefahrlos löschen?

Gibts nicht eine BSH-Funktion, mit der ich die BSH-Datenbank anhand des Inhalts der Backupplatte neu aufbauen kann? Könnte es sein, dass die beiden genannten Dateien dann (oder kurz danach) automatisch von BSH gelöscht werden?

Viele Grüße
tkansgar

Hallo tkansgar,

also wenn du nicht vor hast die Datei jemals wiederherzustellen, dann kannst du sie natürlich auch manuell per Windows Explorer löschen.

Wie gesagt, BSH sollte alte Sicherungen und deren Dateien definitiv automatisch löschen, wenn du es so eingestellt hast. Hinweis: Bei Vollautomatischen Sicherungen werden die Sicherungen aber nur ausgedünnt und nicht nach einem Jahr gelöscht. Das müsstest du entweder manuell machen oder über die zeitplanbasierten Sicherungen.

Ich hab allerdings die Vermutung, dass irgendetwas die Löschung der Datei blockiert hat, auch aufgrund der dort liegenden tmp.Datei.

Hallo Alex,

ich habe mittels der Suchfunktion des BSH-Backupbrowsers herausgefunden, dass er sämtliche Dateien aus dem besagten Sicherungsordner entweder gar nicht kennt oder nur neuere Versionen davon, die ich dann wiederum auch im entsprechenden Sicherungsordner fand. Ich habe weiterhin eine ganze Menge Dateien mit Endung .tmp auf der Backupplatte gefunden. Aber die allermeisten davon sind von BSH tatsächlich gesicherte Dateien, die so klein waren, dass sich das Zippen wohl nicht gelohnt hatte. Einige wenige aber entsprechen allesamt dem Namensmuster DotNetZip-*.tmp. Und offenbar trifft auf alle Sicherungsordner, in denen es solch eine Datei gibt, das Gleiche zu wie auf den oben genannten, nämlich dass der BSH-Backupbrowser keine einzige dort enthaltene Datei als gesicherte kennt. Und mir ist aufgefallen, dass im Gegensatz zu diesen Ordnern andere ähnlich alte Sichungsordner nur noch sehr sehr wenige Dateien enthalten. Die meisten dort enthaltenen Ordner sind leer. Daraus schließe ich jetzt, dass ich alte verunglückte Sicherungen am Vorhandensein einer Datei DotNetZip-*.tmp und auffallend vielen zip-Dateien erkennen kann.

Ich vermute, diese Sicherungen sind durch Herunterfahren des Rechners während laufender Sicherung verunglückt.

Kannst du meine Vermutungen bestätigen?

Das klingt tatsächlich danach, als wäre die Sicherung schon nicht korrekt durchgelaufen bzw. das Zippen der Dateien klappte nicht.

Ich schau mir das heute Abend mal genauer an. Erste Suche nach dem Fehler ergab tatsächlich ein Problem mit der verwendeten Zip-Bibliothek (DotNetZip), deswegen auch der Name der Datei.

Ach ja: Kannst du vielleicht mal schauen, ob du in der Ereignisanzeige im Protokoll "Backup Service Home" irgendeine Fehlermeldung finden kannst? Das wäre sehr hilfreich.

So habe tatsächlich in Erfahrung bringen können, dass unter bestimmten Umständen die Zip-Funktion die Dateien nicht vollständig und korrekt komprimiert. Eine fehlerbereinigte Betaversion steht im Betaforum bereit.

Das hilft dir natürlich weniger weiter.
Du könntest nachschauen, ob noch weitere Dateien betroffen sind. Dann liegt in dem jeweiligem Ordner eine DotNetZip.xxxx.tmp Datei.

Alex hat geschrieben:Ach ja: Kannst du vielleicht mal schauen, ob du in der Ereignisanzeige im Protokoll "Backup Service Home" irgendeine Fehlermeldung finden kannst? Das wäre sehr hilfreich.

Geschaut habe ich. Ich muss dich aber leider enttäuschen. Die derzeit jüngste DotNetZip-*.tmp ist vom 20.10.2014. Das Protokoll von dem Tag ist aber leider schon weg (es sei denn du kennst ein Versteck, wo es noch zu finden sein könnte, vielleicht in einem BSH-Backup?). Ich könnte natürlich mal eine laufende Sicherung durch Herunterfahren des Rechners absichtlich verunglücken lassen, in der Annahme, dass dies die Ursache des Verunglückens ist.

So habe tatsächlich in Erfahrung bringen können, dass unter bestimmten Umständen die Zip-Funktion die Dateien nicht vollständig und korrekt komprimiert. Eine fehlerbereinigte Betaversion steht im Betaforum bereit.

Mit einer neuen Version habe ich jetzt so flott noch gar nicht gerechnet, vielen Dank! Auch freut es mich, dass ich wieder zur Fehlerbereinigung beitragen konnte. Allerdings, da ich prinzipiell kein Freund von Betaversionen bin, warte ich lieber auf die neue reguläre BSH-Release, in der dann diese Fehlerbehebung hoffentlich enthalten sein wird, wenn sie sich bewährt.

Das hilft dir natürlich weniger weiter.
Du könntest nachschauen, ob noch weitere Dateien betroffen sind. Dann liegt in dem jeweiligem Ordner eine DotNetZip.xxxx.tmp Datei.

Derzeit gibt es im Backupordner meines Rechners außer der zuerst gefundenen noch insgesamt 5 weitere DotNetZip-*.tmp, noch zwei von 2012 und drei von diesem Jahr. In dem für unser Notebook sind es 6 und in dem meiner XP-VM sogar 18 Stück. Ist es richtig, dass ich solche Ordner derzeit manuell löschen muss und dies auch bedenkenlos tun kann?

tkansgar hat geschrieben:... Ich könnte natürlich mal eine laufende Sicherung durch Herunterfahren des Rechners absichtlich verunglücken lassen, in der Annahme, dass dies die Ursache des Verunglückens ist.

Hab das gerade mal gemacht. Die Sicherung ist zwar verunglückt, denn der neue Sicherungsordner existiert und enthält Zip-Dateien, und der Backupbrowser kennt sie nicht. Aber leider gibt es keine neue DotNetZip-*.tmp, nur einen leeren Unterordner. Das könnte damit zusammenhängen, dass ich die Erstellung einer Volumenschattenkopie abgewürgt habe und daher offenbar gerade kein Zipping lief. Und leider gibt es zum Abbruch der Sicherung auch keinerlei Hinweise im Protokoll, nur als letztes die Erwähnung des Versuchs eine Volumenschattenkopie zu erstellen. Der nächste Eintrag ist schon der Neustart von BSH nach dem Reboot.

Das liefert jetzt eine weitere neue Erkenntnis: Es gibt auch verunglückte Sicherungen, die keine DotNetZip-*.tmp hinterlassen. Fragt sich nun also, wie man diese später wiederfindet. Denn sie haben m.E. keine sicheren Merkmale. Leere Ordner gibt es schließlich in älteren nicht verunglückten Sicherungen öfter mal (s. oben).

Die einzige Möglichkeit die "verunglückten" Sicherungen zu finden ist sich die Datenbank anzuschauen. Falls du dir die Mühe machen willst, kannst du ein beliebiges SQLite Datenbanktool verwenden. In der VersionTable findest du alle die Sicherungen, die vollständig abgeschlossen wurden.

Warum klappt das? Ganz einfach, die Datenbank wird erst ab Ende des Sicherungsvorgangs beschrieben.

OK, Alex, das könnte ich tun, übersteigt aber den Aufwand, den ich bereit bin, für dieses kleine Problem aufzubringen. Solange die Dateien in solchen verwaisten Ordnern nicht allzu groß sind, stören sie ja kaum. Falls die Platte mal wieder zu voll werden sollte, kann ich ja nach großen Dateien suchen und dann im Browser nachsehen, ob er die betreffende Sicherung kennt. Mit dem Dateinamen der großen Datei ist das ja ganz einfach. Und erstmal kann ich ja alle Sicherungsordner mit einer DotNetZip-*.tmp löschen, sofern du meiner Frage zustimmst:

tkansgar hat geschrieben:... Ist es richtig, dass ich solche Ordner derzeit manuell löschen muss und dies auch bedenkenlos tun kann?

Du schreibst:

Alex hat geschrieben:... also wenn du nicht vor hast die Datei jemals wiederherzustellen, dann kannst du sie natürlich auch manuell per Windows Explorer löschen.

Den hiesigen Erkenntnissen zufolge könnte ich die Dateien in solchen Ordnern allenfalls wiederherstellen, indem ich sie selbst wieder entzippe, da der Browser sie ja nicht kennt. Das sehe ich doch richtig, oder? Und wenn ich ganz sicher bin, dass ich sie nicht mehr brauche, kann ich doch den kompletten Sicherungsordner löschen, richtig?

Den hiesigen Erkenntnissen zufolge könnte ich die Dateien in solchen Ordnern allenfalls wiederherstellen, indem ich sie selbst wieder entzippe, da der Browser sie ja nicht kennt. Das sehe ich doch richtig, oder?

Das ist korrekt.

Und wenn ich ganz sicher bin, dass ich sie nicht mehr brauche, kann ich doch den kompletten Sicherungsordner löschen, richtig?

Wie gesagt, der erste Anlaufpunkt zum Löschen von Sicherungen sollte der Backupbrowser sein. Aber wenn du absolut sicher bist, dass alle Dateien in der Sicherung nie mehr wiederhergestellt werden, dann kannst du sie löschen.
Trotzdem möchte ich hier erwähnen, dass das nicht die empfohlene Vorgehensweise ist.

Alex hat geschrieben:Wie gesagt, der erste Anlaufpunkt zum Löschen von Sicherungen sollte der Backupbrowser sein. Aber wenn du absolut sicher bist, dass alle Dateien in der Sicherung nie mehr wiederhergestellt werden, dann kannst du sie löschen.
Trotzdem möchte ich hier erwähnen, dass das nicht die empfohlene Vorgehensweise ist.

Das habe ich schon verstanden. Mir gehts ja um die Sicherungen (genauer gesagt die Sicherungsordner), die der Backupbrowser nicht kennt. Denn wenn er sie nicht kennt, kann ich sie ja nur manuell löschen, wie du selbst bestätigst.

In dem Zusammenhang habe ich noch eine Frage: Wenn man im Backupbrowser eine beliebige Datei einer beliebigen Sicherung markiert und sich die Eigenschaften ansieht, werden unter "Sicherungen" manchmal mehrere, manchmal nur eine und manchmal auch gar keine Sicherungen angezeigt. Welche werden hier angezeigt und welche nicht? Ich habe z.B. von einer Datei, die sich relativ häufig ändert, mit meinem Dateisuchprogramm insgesamt 22 von BSH gesicherte Versionen gefunden. Und der Backupbrowser zeigt die jeweilige Sicherung dieser Datei auch an, wenn ich links im Navigationsteil die Sicherung anklicke. Aber wenn ich mir dann die Eigenschaften der Datei ansehe, wird dort unter "Sicherungen" nur die letzte Sicherung von gestern angezeigt, warum nicht auch die übrigen 21?

Denn wenn er sie nicht kennt, kann ich sie ja nur manuell löschen, wie du selbst bestätigst.

Das ist leider nicht ganz richtig. Ich war da wohl etwas unpräzise.
Es werden auch die Sicherungen nicht mehr angezeigt, die du über den Backupbrowser gelöscht hast. Trotzdem sind die entsprechenden Ordner mit dem Sicherungsdatum noch notwendig, um andere Sicherungen wiederherzustellen. Das liegt am inkrementellen Sichern von Dateien.

Welche werden hier angezeigt und welche nicht?

Hier werden alle die Sicherungen angezeigt, in der die Datei auch tatsächlich gesichert wurde. Wurde die entsprechende Sicherung gelöscht, dann taucht sie hier auch nicht mehr auf. Es kann aber durchaus noch andere Sicherungen geben, die auf diese Version der Datei verweisen. In sofern ist die Anzeige nicht ganz präzise.