Aufmacher News

storeBackup 2.0

Heinz-Josef Claes
09.10.2008

Von dem hier vor einiger Zeit von mir vorgestellten Backup Programm ist jetzt die Version 2.0 als Release Candidate 2 erschienen, der sehr nahe (wenn nicht identisch) zur endgültigen Version sein wird. Um es kurz zu beschreiben - StoreBackup bietet bereits in Version 1.19:

  • Sicherung von einem Verzeichnis in ein anderes (d.h. sinnvollerweise auf eine andere Festplatte).
  • Einfaches Zurücksichern aus dem Backup. Die Daten liegen in einem transparenten Format als Dateien im Backup Verzeichnis.
  • Die Dateien können im Backup (falls gewünscht) komprimiert werden, was Plattenplatz spart.
  • Schon im Backup befindliche Dateien werden über Hardlinks miteinander verbunden. Dieses erfolgt nach dem Inhalt der Dateien, daher wird z.B. das Kopieren oder Umbennen von Dateien oder Pfaden berücksichtigt.
  • Mehrere unabhängige Backups können auf Dateien identischen Inhalts verweisen.
  • StoreBackup ist schnell und kann auch für große Datenmengen eingesetzt werden.

Es gibt noch viele weitere Features, die ich hier aber nicht aufzählen will. Ich möchte hier beschreiben, was in der Version 2 grundsätzlich neu ist (nur die wichtigsten Unterschiede):

  • Bei einem neuen Backup ändern sich normalerweise nur sehr wenige Dateien. Diese müssen dann kopiert bzw. komprimiert werden. Da storeBackup immer vollständige Backups erzeugt (was diverse Vorteile hat), müssen die restlichen Dateien als Hard Links angelegt werden. Dieses ist zwar sehr schnell, dauert jedoch - insbesondere über NFS - bei sehr vielen Dateien / Hard Links seine Zeit. Die neue Option "lateLinks" ermöglicht es nun, ein Backup ohne die oben erwähnten Hard Links zu erzeugen. Diese werden mit einem mitgelieferten Tool dann später auf dem Server aus einer Protokolldatei konstruiert. Das Ganze bedeutet eine Performancesteigerung um einen Faktor 2-4 im LAN für das direkte Backup. Auf WAN Verbindungen (VPN) habe ich eine Verbesserung um bis zu einem Faktor 70 messen können.
  • Mit der Option "lateCompress" kann das Komprimieren von neuen Dateien ebenfalls auf den Server verlagert werden.
  • Mit einem neuen Suchprogramm kann in den Backups nach Regeln gesucht werden. Diese Regeln sind eine beliebige Kombination von Dateigröße, UID, GID, Datei/Pfadname, Alter einer Datei (relativ oder absolut), Rechte oder Dateityp.
  • Das Sichern von special files (wie Device Nodes) ist jetzt ebenfalls möglich.
  • Die Einstellungen in der Konfigurationsdatei können jetzt in der Kommandozeile überschrieben werden.
  • Es gibt endlich eine ausführliche Dokumentation, sowohl über eine Homepage, als auch herunterladbar als pdf Datei

Was kommt danach?
Momentan befindet sich schon Version 3.0 in Arbeit.
Sie wird es als neues Feature ermöglichen, Dateien blockweise (also nicht als Ganzes wie bisher) zu untersuchen und zu sichern. Dieses ist z.B. für Image Dateien interessant. Es wird auch hier weiterhin möglich sein, die Daten aus dem Backup völlig ohne Tools zu restaurieren. (Natürlich wird das restore-Tool das auch unterstützen.)
Über die oben beschriebenen Regeln wird es möglich sein, die Dateien, die blockweise untersucht werden sollen zu spezifizieren, z.B. alle Dateien im Verzeichnis /opt/vmware, die größer als 100MB sind.

Neues zu storeBackup wird wie schon vorher über freshmeat.net publiziert, die Webseite hat sich allerdings geändert!

Ähnliche Artikel

Kommentare
Danke
Felix (unangemeldet), Sonntag, 27. Dezember 2009 23:22:45
Ein/Ausklappen

Wollte einfach nur Danke sagen für das tolle Programm.
Hat mir sehr geholfen, nachdem ich (aus Dummheit :) mein /home beschädigt hatte.
Sehr durchdachtes Konzept.


Bewertung: 271 Punkte bei 65 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
Re: storeBackup 2.0
Ulf B., Donnerstag, 09. Oktober 2008 23:17:02
Ein/Ausklappen

Ich verwende storeBackup schon seit Jahren und möchte es nicht mehr missen. Es ist mit ein Grund weshalb ich mein Home auf einen 24/7 Server habe und nur via NFS Mounte. Das Backup (damals noch auf einen 166-er P1) lief dann bei ca. 100GB - 16 Stunden. Heute schafft mein AMD BE2300 und 64bit OS ca. 200GB Täglich unter 1 Stunde.

Dieses Backup über mehrere Tage hat mir schon beim langsamen Tod einer Festplatte geholfen Dateien zu Retten, da in den letzten Backups dann schon die defekten Dateien gesichert wurden (war auch beim ersten Auftreten eine HD-Fehlers schon so - und hat letztendlich zur Auswahl von storeBackup geführt. Auch beim verändern und rückgängig machen einer Datei (z.B. einer Konfinguration) war storeBackup schon sehr hilfreich. Momentan ersetzt storeBackup damit auch ein RAID welches die Daten nur spiegelt, aber nicht archiviert.

Momentan kämpfe ich noch mit zwei Problemen die ich mit storeBackup noch nicht lösen konnte. Wie kopiere ich die Daten der alten Sicherung (mit den Teilweise geretteten Dateien) incl. Hardlinks auf eine andere HD? Und als zweites wie finde ich die veränderten Dateien aus meinem Bestand heraus (ich will ja nicht jede Datei einzeln Prüfen - da fiele Fotos dabei sind die man ja nicht verlieren möchte)?

Mein Ansatz für die letzte Frage wäre, nach Dateien zu suchen die sich geändert haben ohne dass sich das Änderungsdatum im Header ändert. Aber liege ich da richtig und kann ich das in der storeBackup Sicherung noch herauslesen?

Wäre nett wenn jemand schon mit einem ähnlichen Problem, seine Lösung hier posten könnte. Evtl. wäre das auch ein Feature für die Version 3.0 (oder ist die Lösung schon 1in der bisherigen Version enthalten und ich habe sie noch nicht gefunden).

PS: Evtl. wäre ein Flag (Datei) hilfreich, mit der man das löschen alter Sicherungen verhindern könnte. Dieses Flag könnte dann auch beim erkennen eines Hardwaredefekts oder ähnlichen, automatisch von einer anderen Aplikation gesetzt werden.

Ciao
Ulf




Bewertung: 309 Punkte bei 78 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
-
Re: storeBackup 2.0
Heinz-Josef Claes, Freitag, 10. Oktober 2008 09:41:05
Ein/Ausklappen

Wie kopiere ich die Daten der alten Sicherung (mit den Teilweise geretteten Dateien) incl. Hardlinks auf eine andere HD?
Mir ist nicht ganz klar, was gemeint ist. Wenn einfach das Backup Directory (in Version 1.x "targetDir", jetzt in 2.0 "backupDir") gemeint ist, dann geht es ganz einfach, z.B. entweder mit tar oder auch mit cp:
# tar cvf - | (cd ; tar xpf -)
# cp -av
Hierbei bedeuten der Pfad zum vorhandenen Backup und der Pfad (auf einer anderen Platte) zur zu erstellenden Kopie.

Falls gemeint sein sollte, ein Backup so zurückzusichern, das im Original vorhandene Hardlinks wiederhergestellt werden, dann einfach storeBackupRecover.pl verwenden, das stellt die Hard Links wieder her, entpackt und setzt Zeiten, Rechte und uid / gid auf die alten Werte.

Und als zweites wie finde ich die veränderten Dateien aus meinem Bestand heraus (ich will ja nicht jede Datei einzeln Prüfen - da fiele Fotos dabei sind die man ja nicht verlieren möchte)?
In ein Backup gehen (cd ...). Dann aufrufen:
# storeBackupVersion.pl -f
ist der Name der zu untersuchenden Datei und zwar so, wie er im Backup steht (also eventuell mit .bz2). (So kann man einfach die Pfadnamen Ergänzung der Shell nutzen.)

Evtl. wäre ein Flag (Datei) hilfreich, mit der man das löschen alter Sicherungen verhindern könnte. Dieses Flag könnte dann auch beim erkennen eines Hardwaredefekts oder ähnlichen, automatisch von einer anderen Aplikation gesetzt werden.
Das geht auch schon seit langem; beschrieben ist es jetzt z.B. hier. Kurz gesagt, man kann das Backup Verzeichnis (das mit Datum_Uhrzeit) einfach umbenennen oder das "archive flag" verwenden.

In der neuen Dokumentation wird noch wesentlich mehr ausführlich erklärt, z.B. welche Dateien und ASCII Formate intern verwendet werden, wie man die NFS Performance verbessert etc.

Gruß, HJC


Bewertung: 308 Punkte bei 75 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
-
Re: storeBackup 2.0
Ulf B., Freitag, 10. Oktober 2008 20:53:31
Ein/Ausklappen

Erst mal Danke für Deine Antwort.

Zu Deiner Antwort zu: Wie kopiere ich die Daten der alten Sicherung (mit den Teilweise geretteten Dateien) incl. Hardlinks auf eine andere HD?

Es ist tatsächlich das Verschieben gemeint. Ich habe die Daten auch per
# cp -av
Verschoben. Bis meine bisher 150GB Sicherung meine 300GB HD gefüllt hatte. Ein kurzes überprüfen zeigte dann auch, dass beim einfachen cp bzw. mv die Hardlinks durch Kopien ersetzt werden. Was dann zu diesem Überlaufen führte. Ich habe dann anschließend mit einem kleinem Script und freedup -0 < Pfad_N+1> die Hardlinks wieder herstellen lassen. Aber hat einige Zeit gedauert und ich habe manchmal auch Fehlermeldungen alla Linking failed.: Too many links erhalten.

Zu Deiner Antwort zu: Und als zweites wie finde ich die veränderten Dateien aus meinem Bestand heraus (ich will ja nicht jede Datei einzeln Prüfen - da fiele Fotos dabei sind die man ja nicht verlieren möchte)?

Dazu müsste ich aber schon vorher wissen welche Datei beschädigt ist. Aber genau die Info fehlt mir ja bzw. will ich finden. Dazu evtl. ein Beispiel, ich habe ein Verzeichnis mit etwa 50 Unterverzeichnissen mit jeweils über 1000 Fotos (also zusammen über 50'000 Bilder). Davon sind ca. 0,1% beschädigt - ich weiß aber nicht welche. Wie finde ich jetzt die beschädigten Bilder heraus? Wie ich diese dann wieder herstellen kann ist dann relativ einfach (eben z.B. via storeBackupVersion.pl und anschließenden wiederherstellen des Originals).

Meine Idee wäre eben nach einer zwischen zwei Sicherungen geänderten Datei zu suchen, bei welcher aber nicht das Änderungsdatum geändert wurde. Die Änderung der Daten ruht ja von fehlenhaften Speicherstellen und nicht einer echten Änderung her. Oder liege ich da falsch?

Zu Deiner Antwort zu: Evtl. wäre ein Flag (Datei) hilfreich, mit der man das löschen alter Sicherungen verhindern könnte. Dieses Flag könnte dann auch beim erkennen eines Hardwaredefekts oder ähnlichen, automatisch von einer anderen Aplikation gesetzt werden.

Leider gibt es storeBackupUpdateBackup.pl bei meiner storeBackup-1.19-111.1 von openSUSE 11.0 nicht. Aber ansonsten ist die vorgeschlagene Lösungen mit dem umbenennen eigentlich einfach und naheliegend. Muss gestehen, da bin ich nicht drauf gekommen.

Noch mal danke für Deine Info's und natürlich insbesondere für Dein tolles Tool. Ich hatte schon vorher angefangen etwas ähnliches zu basteln (per Bash-Script) aber Deine Lösung ist einfach genial und gleichzeitig genial einfach (da ich auch ohne installiertes storeBackup noch etwas mit den Daten anfangen kann - weil es sich ja um keine exotischen Archiv-Formate handelt). Siehe auch meine Gedanken auf [1] (noch in Arbeit).

Ciao
Ulf



[1] http://lug-vs.endlose-rekursion.de/index.php/Backup



Bewertung: 310 Punkte bei 87 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
-
Re: storeBackup 2.0
Heinz-Josef Claes, Freitag, 10. Oktober 2008 22:31:05
Ein/Ausklappen

Erst mal Danke für Deine Antwort.
Gerne.

und ich habe manchmal auch Fehlermeldungen alla Linking failed.: Too many links erhalten.
Das kann ich mir nur so erklären, dass unterschiedliche Filesysteme auf den Partitionen waren - und Du dann von einem Filesystem, das viele Hardlinks pro Inode unterstützt (z.B. Reiserfs mit 64535) auf eins mit weniger Hardlinks (z.B. ext2 mit 32000) kopiert hast (bei 32 Bit Linux). (Eine weitere Erklärungsmöglichkeit ist natürlich ein korruptes Dateisystem.) StoreBackup berücksichtigt das Problem mit der begrenzten Anzahl Hardlinks und legt dann eine neue Kopie an, auf die dann wiederum verlinkt wird. Eine Lösung wäre also, alle Backups wiederum als neues Backup woanders hin zu packen. Das "Header Directory" kann man später ja einfach weglöschen. Das dürfte allerdings langsamer sein, als mit tar. StoreBackup würde dabei alle md5 Summen neu berechnen.
Mit cp (gnu-cp!) funktioniert bei mir das Kopieren von Hard Links. Wieso gibt es da Probleme? (Ich verwende normalerweise jedoch immer tar, da gibt es definitiv keine.)

Wie finde ich jetzt die beschädigten Bilder heraus?
Mir ist nicht ganz klar, wo das Problem liegt. Es gibt zwei Möglichkeiten. Wenn ich es richtig verstehe, waren die Bilder schon vor dem Backup kaputt. Dann liefert storeBackup natürlich keinerlei Informationen. Eventuell kann man aber mit einem Tool für jpegs die Dateien lesen und dabei feststellen (exit-Status), ob sie defekt sind. Die jpegs werden ja wahrscheinlich als einfache Dateien in Deinen Backups vorliegen. Eigentlich müsste das mit ein paar relativ einfachen Skripten machbar sein!?
Wenn die Bilder im Backup (z.B. aufgrund Plattenfehlers) defekt sind, ist es prinzipiell möglich, festzustellen, welche defekt sind. In der Datei .md5CheckSums.bz2 steht die md5 Summe jeder Datei (und zwar die von der ev. unkomprimierten Originaldatei). Hiermit könnte man feststellen, ob die Datei nachträglich beschädigt wurde. (Ein solches Skript zur Konsistenzprüfung wäre wahrscheinlich keine schlechte Idee, vielleicht besteht da ja Bedarf.) Es stehen auch noch andere Informationen darin, siehe Link oben.

Leider gibt es storeBackupUpdateBackup.pl bei meiner storeBackup-1.19-111.1 von openSUSE 11.0 nicht.
Das ist kein Problem. Pack das tar archiv einfach irgendwo aus und damit hast Du die neue Version installiert. Die Parametrierung musste ich allerdings teilweise etwas ändern - hier sind also kleinere Anpassungen nötig.
Nebenbei bemerkt hat weder das Umbenennen noch das "archive flag" etwas mit der 2.0er Version zu tun, das geht auch bei der 1.19 und früher.
Falls Du umbenennen willst, solltest Du darauf achten, es in Datum_Uhrzeit- zu ändern, ansonsten durchsucht storeBackupUpdateBackup.pl (falls Du es mal verwenden solltest) das gesamte Backup, was sinnlos Zeit kostet.

Siehe auch meine Gedanken auf [1] (noch in Arbeit)
Kannst Du die Links auf die neue Web Site setzen? Ich habe mich von sourceforge verabschiedet, weil der Administrationsaufwand für ein kleines Projekt einfach zu hoch ist. Leider dauert es ziemlich lange, bis die Suchmaschinen umschwenken.

Ich weiß nicht, ob das hier noch von allgemeinen Interesse ist, im Zweifelsfall schick einfach eine E-Mail.

Gruß, HJC


Bewertung: 292 Punkte bei 69 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
-
Re: storeBackup 2.0
Ulf B., Samstag, 11. Oktober 2008 19:13:41
Ein/Ausklappen

Zu: ...das viele Hardlinks pro Inode unterstützt (z.B. Reiserfs mit 64535) auf eins mit weniger Hardlinks (z.B. ext2 mit 32000) kopiert hast (bei 32 Bit Linux).

Das kann es gewesen sein, Quelle war tatsächlich eine ReiserFS-Partition und ziel ein externes Laufwerk welches mit ext3 formatiert war. Evtl. sind dann die darüber hinaus gehenden Hardlinks durch Kopien ersetzt worden (wie gesagt, handelt es sich schon um riesen Datenmengen).

Zu: ...In der Datei .md5CheckSums.bz2 steht die md5 Summe jeder Datei (und zwar die von der ev. unkomprimierten Originaldatei). Hiermit könnte man feststellen, ob die Datei nachträglich beschädigt wurde.

Werde ich mal versuchen. Außerdem ist mir eingefallen, dass evtl. ein diff auf die ältesten Dateien helfen könnte, da sich diese bei Fotos bei mir normalerweise nicht ändern (editierte Bilder bekommen einen neuen Namen).

Zu: Nebenbei bemerkt hat weder das Umbenennen noch das "archive flag" etwas mit der 2.0er Version zu tun, das geht auch bei der 1.19 und früher.

OK, hatte ich schon in der Doku gesehen. Habe es aber irgendwie überlesen (englisch ist nicht so meine Stärke, auch wenn ich es eigentlich täglich benutze/benötige).

Zu: Falls Du umbenennen willst, solltest Du darauf achten, es in Datum_Uhrzeit- zu ändern, ansonsten durchsucht storeBackupUpdateBackup.pl (falls Du es mal verwenden solltest) das gesamte Backup, was sinnlos Zeit kostet.

So ganz verstehe ich nicht, wozu storeBackupUpdateBackup.pl eigentlich benötigt wird. Was verstehst Du unter lateLinks, bzw. sind diese default seitig verwendet oder muss ich dazu eine Option setzen/aktivieren?

Zu: Kannst Du die Links auf die neue Web Site setzen?

Habe den Link auf die savannah.nongnu.org Seiten umgestellt, oder soll ich lieber den anderen nehmen? Zu: Ich weiß nicht, ob das hier noch von allgemeinen Interesse ist, im Zweifelsfall schick einfach eine E-Mail.

Ich denke, dass es hier gut aufgehoben ist, da jemand mit ähnlichen Gedanken Problemen, es dann nachlesen kann. Bei Problemen bin häufig auf die Seiten der LC gelandet (bei einer Suche auf diversen Suchmaschinen) und dann ist es schade wenn nicht alle Informationen oder gar eine Lösung bei Problemen hier zu finden sind. Ich sehe die Seiten hier mittlerweile als große Wissensdatenbank unabhängig von den Spezialseiten und Foren.

Ciao
Ulf




Bewertung: 295 Punkte bei 69 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
-
Re: storeBackup 2.0
Heinz-Josef Claes, Sonntag, 12. Oktober 2008 01:03:23
Ein/Ausklappen

Hiermit könnte man feststellen, ob die Datei nachträglich beschädigt wurde.
Werde ich mal versuchen. Außerdem ist mir eingefallen, dass evtl. ein diff auf die ältesten Dateien helfen könnte, . . .
storeBackup arbeitet folgendermaßen:
Es überprüft, ob sich gegenüber dem vorherigen Backup für eine Datei Größe oder die Uhrzeit (ctime, mtime) geändert hat. Wenn nicht, dann wird die md5 Summe vom vorigen Backup übernommen und ein Hard Link gesetzt (die md5 Summe spielt in diesem Fall also eigentlich keine Rolle).
Wenn sich Größe oder Uhrzeit geändert haben oder exakt diese Datei vorher nicht existiert hat, wird die md5 Summe berechnet und überprüft, ob eine Datei mit exakt dieser md5 Summe schon im Backup existiert. Wenn ja, wird ein Link darauf gesetzt, wenn nicht, wird die Datei kopiert bzw. komprimiert.
Hierdurch ergibt sich eine minimal Anzahl von md5 Summen Berechnungen und Kompressionsvorgängen, was der Performance gut tut.
Ich verstehe nicht, was die diffs bringen sollten. Nur mit der Überprüfung der md5 Summen kann man Fehler finden, die nacheinem Backup durch Plattenfehler entstanden sind!?

So ganz verstehe ich nicht, wozu storeBackupUpdateBackup.pl eigentlich benötigt wird. Was verstehst Du unter lateLinks, bzw. sind diese default seitig verwendet oder muss ich dazu eine Option setzen/aktivieren?
Wenn man die neue Option lateLinks nicht verwendet, kann man storeBackupUpdateBackup.pl vergessen. Die Option lateLinks dient dazu, die Performance teilweise dramatisch zu verbessern. Es gibt Anwender, die mit storeBackup Millionen von Dateien über nfs sichern (schreiben). Je nach Netzwerk und nfs-Einstellungen kann das Setzen der hard links und der Rechte dann in Summe ziemlich lange dauern. Da sich normalerweise nur wenige Dateien von Backup zu Backup ändern, wird die Dauer des Backups im Wesentlichen von der Dauer des Schreibens der hard links bestimmt.
Mit der Option lateLinks werden beim Lauf von storeBackup.pl überhaupt keine hard links mehr gesetzt, sondern nur noch eine Protokolldatei geschrieben, in der steht, welche Links eigentlich hätten gesetzt werden müssen. Hierdurch wird die Dauer des Backups im Wesentlichen von der Lesegeschwindigkeit auf der lokalen Festplatte bestimmt. Und das bringt nach meinen Messungen auf einem flotten LAN einen Faktor 4-16 (je nach nfs Konfiguration).
Die hierbei entstehenden Backups sind natürlich nicht "fertig". Zur Fertigstellung dient storeBackupUpdateBackups.pl. Auch das Löschen von alten Backups (welches über nfs auch einige Zeit benötigt, kann man mit storeBackupDel.pl später auf dem Server laufen lassen. Das ging aber schon vor Version 2.0,
Die Option lateLinks bringt bei einem lokalen Backup ungefähr einen Faktor 2; da später storeBackupUpdateBackup.pl laufen muss, ist es zusammen dann ungefähr ein Nullsummenspiel. Wenn der Server als Nachts ein Backup zieht (wie bei mir auch), bringt die Option nichts (außer es müssen für das Backup Services heruntergefahren werden). Ich verwende lateLinks jetzt seit einige Monaten für die Sicherung der Arbeitsplätze und Laptops. Nachts auf dem Server läuft dann storeBackupUpdateBackup, storeBackupDel und zwei lokale Sicherungen ohne lateLinks mit unterschiedlichen Aufbewahrungsfristen.

Habe den Link auf die savannah.nongnu.org Seiten umgestellt, oder soll ich lieber den anderen nehmen?
Das ist die zentrale Anlaufstelle. Die Ankündigung von neuen Version läuft über freshmeat, auf savannah gibt in der Doku aber inzwischen auch einen Link darauf.
Bisher habe ich mich noch nicht dazu durchringen können, eine Mailingliste auf savannah freizuschalten. Ich hatte das auf sourceforge gemacht und werde noch heute darüber täglich mit spam überschwemmt. Abschalten kann man die Mailinglisten scheinbar nicht. Die Site auf sourceforge will ich noch nicht plattmachen, da die Suchmaschienen noch darauf verweisen.

Ich denke, dass es hier gut aufgehoben ist, . . .
Da hast Du wahrscheinlich recht ;-)


Die Beschreibungen der Funktionalität oben sind grundsätzlich richtig, es werden aber nicht alle "Schmutzeffekte", die berücksichtigt werden, erwähnt.

Für die, die das später lesen sollten: Es kann sein, dass die Links dann falsch sind, da die Dokumentation generiert wird. Ich muss 'mal überprüfen, ob man den Kapibeln feste Namen zuweisen kann (sorry).

Noch eine Ergänzung:
Die Konsistenzprüfung des Backups (md5 Summen neu rechnen) werde ich wahrscheinlich bei der nächsten Version von storeBackup hinzufügen. Ich arbeite momentan (wenn ich Zeit habe) an der Version 3.0, die (wie oben im Artikel erwähnt), große Image Dateien stückchenweise analysieren kann. Grundsätzlich scheint das seit heute bei mir zu funktionieren :-) . (StoreBackup ist dann für fast alles gut geeignet, nicht nur für viele kleine Dateien, sondern z.B. auch für VMware Image Files, Datenbankdateien, Gigabyte große Outlook pst-Dateien (igitt).). Bevor ich diese Konsistenzprüfung jetzt mache und dann wieder anpassen muss, ist es effektiver, diese gleich für v3 zu schreiben.

Gruß, HJC


Bewertung: 291 Punkte bei 79 Stimmen.
Den Beitrag bewerten: Gut / Schlecht
-
Re: storeBackup 2.0
Ulf B., Sonntag, 12. Oktober 2008 18:22:21
Ein/Ausklappen

Hallo Heinz-Josef,

erstmal ein herzliches Dankeschön, für Deine ausführlichen Antworten. Diese Persönliche aufgeschlossene Art der meisten Entwickler im Linux Umfeld, macht meiner Meinung nach einen großen Teil seines Charmes aus :-)

Ich Danke Dir erst mal für die Antworten und das Hervoragende und meiner Ansicht nach konkurrenzlose Datensicherungs-Tool!

Ciao
Ulf




Bewertung: 292 Punkte bei 72 Stimmen.
Den Beitrag bewerten: Gut / Schlecht

Aktuelle Fragen

EasyBCD/NeoGrub
Wolfgang Conrad, 17.12.2017 11:40, 0 Antworten
Hallo zusammen, benutze unter Windows 7 den EasyBCD bzw. NEOgrub, um LinuxMint aus einer ISO Dat...
Huawei
Pit Hampelmann, 13.12.2017 11:35, 2 Antworten
Welches Smartphone ist für euch momentan das beste? Sehe ja die Huawei gerade ganz weit vorne. Bi...
Fernstudium Informatik
Joe Cole, 12.12.2017 10:36, 2 Antworten
Hallo! habe früher als ich 13 Jahre angefangen mit HTML und später Java zu programmieren. Weit...
Installation Linux mint auf stick
Reiner Schulz, 10.12.2017 17:34, 3 Antworten
Hallo, ich hab ein ISO-image mit Linux Mint auf einem Stick untergebracht Jetzt kann ich auch...
Canon Maxify 2750 oder ähnlicher Drucker
Hannes Richert, 05.12.2017 20:14, 4 Antworten
Hallo, leider hat Canon mich weiterverwiesen, weil sie Linux nicht supporten.. deshalb hier die...