Hallo, ich habe jetzt einige Backupprogramme ausprobiert, taugt aber alles nicht viel. Probleme mit der Rechtverwaltung usw. Ich möchte folgende Backup-Software: Opensource und kostenlos, lauffähig unter Windows, Linux und MacOS, macht Volume Shadow Copy auch inkrementell und differentiell im Hintergrund während das System läuft. Backupprozess soll unterbrechbar (auch unabsichtlich - Laufwerksausfall) und jederzeit an der Stelle fortsetzbar sein. Backupmedium soll flexibel austauschbar sein, d. h. heute hängt die Platte am USB-Port morgen über Netzwerk usw. Backup soll aufgesplittet werden können auf unterschiedliche Medien und Redundanz erlauben (1 Backupmedium von 5 darf verloren gehen) Arbeitsweise blockbasiert, ohne Kenntnis des Dateisystem möglich, Kompression. Backup-Image soll unter Angabe der Snapshot-Version gemounted werden können. Addon soll Backup mounten und bei Bedarf einzelne Versionen einzelner Dateien zurückspielen können. Was nimmt man da heute so?
Stefan Helmert schrieb: > Was nimmt man da heute so? Geh mal zu deinem freundlichen Autohändler und verlange den Super Duper Benz S-Klasse, mit V8 Motor uns allen Assistenzsystemen, aber bitte Stefan Helmert schrieb: > Opensource und kostenlos Merkst du was?
:
Bearbeitet durch User
Stefan Helmert schrieb: > , macht Volume Shadow Copy auch > inkrementell und differentiell im Hintergrund während das System läuft. Stefan Helmert schrieb: > Arbeitsweise blockbasiert, ohne Kenntnis des Dateisystem möglich, Hmm.. verstehe ich deine Anforderungne falsch oder willst du wirklich kaputte Backups schreiben? IMHO machen inkrementaelle Backups keinen Sinn wenn man das Dateisystem nicht vesteht, und eine ganze Partition waehrend des Betriebes blockorientiert zu "kopieren", also wahrend sich Daten (Dateien, Dateitabellen, etc.) aendern, endet doch nur mit Datenmuell.
Mladen G. schrieb: > IMHO machen inkrementaelle Backups keinen Sinn wenn man das Dateisystem > nicht vesteht, und eine ganze Partition waehrend des Betriebes > blockorientiert zu "kopieren", also wahrend sich Daten (Dateien, > Dateitabellen, etc.) aendern, endet doch nur mit Datenmuell. Unter Windows den es "Volume Shadow Copy" geht es ohne wissen über das Dateisystem. Ein inkrementaelle Backup kann man auch auf Blockebene machen. Das Dateisystem wird nur vorher angewiesen eine sinnvollen Zustand wegzuschreiben. Aber so eine Software die das alles kann wird er wohl nicht finden.
Εrnst B✶ schrieb im Beitrag #3476423: > Wie soll das möglich sein? > Ohne Wissen über das Dateisystems kann nur blockbasiert ein Snapshot > gezogen werden. > Wenn das (unbekannte) Dateisystem aber noch in Verwendung ist, fehlen > dem Snapshot alle Daten die noch irgendwo im Ram zwischengespeichert > sind. in dem es eine API gibt wo man dem Dateisystem sagt, das es jetzt bitte alles wegschreiben soll was im ram ist und ab jetzt erstmal nichts schreiben darf. Nach dem man dann ein Image gezogen hat, sagt man über die API dem Dateisystem das es wieder schreiben darf.
Peter II schrieb: > in dem es eine API gibt wo man dem Dateisystem sagt, das es jetzt bitte > alles wegschreiben soll was im ram ist und ab jetzt erstmal nichts > schreiben darf. Oder jedenfalls keine bestehenden Daten überschreiben darf. Techniken dieser Art sind bei modernen Filesystemen grösserer Systeme recht verbreitet.
:
Bearbeitet durch User
Oh ja, das nehme ich auch! Bitte 2x liefern! Du hast vergessen: - Sichere Verschlüsselung, welche aber den Prozessor nicht belastet - WebDAV-Anbindung - Restore einzelner Dateien soll über eine schicke GUI möglich sein - eine Bandbreitenoptimierung soll integriert sein
Mladen G. schrieb: > IMHO machen inkrementaelle Backups keinen Sinn wenn man das Dateisystem > nicht vesteht, und eine ganze Partition waehrend des Betriebes > blockorientiert zu "kopieren", also wahrend sich Daten (Dateien, > Dateitabellen, etc.) aendern, endet doch nur mit Datenmuell. Doch, das ergibt schon Sinn. Besonders dann, wenn der Snapshot auf der Ebene des Storage erfolgt. Das kann dann so aussehen: (1) Storage Snapshot wird initiiert. (2) Optional teilt das Storage-System dem OS mit, dass ebendies geschieht. Das gibt beispielsweise Datenbanksystemen die Chance, günstige Bedingungen herzustellen (z.B. via Snapshot Provider Plugin in Windows). (3) Storage Snapshot wird durchgeführt. Zustand entspricht ohne (2) dem sofortigen Abschalten eines Systems, was bei heutigen Filesystemen mit Journaling keinen Schaden anrichtet. Mit (2) sieht es noch besser aus. (4) Backup-System sichert die Blöcke des Snapshots vom Storage-System. Das kann inkrementell erfolgen, wenn das Storage-System die Änderungen verfolgt. (5) Snapshot aus (1) wird freigegeben. Dieser Storage kann beispielsweise das Storage-System von VMware ESXi sein. Virtuelle Disks lassen sich mit VMwares eigener Software block-inkrementell sichern (allerdings sind das vmtl. nicht 4K Blöcke). Ausserdem beherrschen das auch einige SAN/NAS-Systeme, wie etwa NetAapp. Einschliesslich der Möglichkeit, selektiv Files zu restoren. Und sei es, in dem der Snapshot in einer anderen Maschine r/o gemountet wird, was dem Prinzip nach OS-neutral ist. Die Redundanzforderungen des Backups lassen sich ebenfalls erfüllen. Es gibt Backup-Systeme, die wichtige Sicherungen als Kopie an einen andern Ort auslagern können. Heute ggf. auch mit Medienbruch, d.h. primäre Sicherung auf SATA-Disks, Kopie auf Bändern. Aber das alles dann für lau? Bitte unbedingt mitteilen wenn fündig geworden. Da gibts sicherlich viele Interessenten. ;-)
:
Bearbeitet durch User
Peter II schrieb: > Εrnst B✶ schrieb im Beitrag #3476423: >> Wie soll das möglich sein? >> Ohne Wissen über das Dateisystems kann nur blockbasiert ein Snapshot >> gezogen werden. >> Wenn das (unbekannte) Dateisystem aber noch in Verwendung ist, fehlen >> dem Snapshot alle Daten die noch irgendwo im Ram zwischengespeichert >> sind. > > in dem es eine API gibt wo man dem Dateisystem sagt, das es jetzt bitte > alles wegschreiben soll was im ram ist und ab jetzt erstmal nichts > schreiben darf. > > Nach dem man dann ein Image gezogen hat, sagt man über die API dem > Dateisystem das es wieder schreiben darf. A. K. schrieb: > Doch, das ergibt schon Sinn. Besonders dann, wenn der Snapshot auf der > Ebene des Storage erfolgt. Das kann dann so aussehen: Schon klar, aber das war nicht was der TO wollte: Stefan Helmert schrieb: > ohne Kenntnis des Dateisystem möglich .. eine API Funktion aufrufen schliesst es aus dass die Backup SW nix vom Dateisystem weiss, aber das habe ich ja schon geschrieben. Mladen G. schrieb: > IMHO machen inkrementaelle Backups keinen Sinn wenn man das Dateisystem > nicht vesteht, Ansonsten hilft es dem TO nicht zu wissen wie es auf einem Hypervisor oder rein unter Windows funktionieren koennte..
:
Bearbeitet durch User
Mladen G. schrieb: > .. eine API Funktion aufrufen schliesst es aus dass die Backup SW nix > vom Dateisystem weiss, aber das habe ich ja schon geschrieben. doch macht es. Die API muss ja nicht vom Filesystem sondern vom Betriebssystem breitgestellt werden.
Mladen G. schrieb: > Schon klar, aber das war nicht was der TO wollte: > > Stefan Helmert schrieb: >> ohne Kenntnis des Dateisystem möglich Das was ich schrieb findet bis auf (2) vollständig ohne jede Mitwirkung eines Filesystems statt. Und (2) hatte ich als optional bezeichnet. Sein Ziel lässt sich - gerade weil es mit beliebigen Filesysteme funktioniert soll - nur dann implementieren, wenn man den Storage-Layer von einer simplen Festplatte (oder RAID Gruppe) auf ein komplexeres Storage-System migriert, welches eben die gewünschte Funktion bietet. > .. eine API Funktion aufrufen schliesst es aus dass die Backup SW nix > vom Dateisystem weiss, aber das habe ich ja schon geschrieben. Was ich unter (2) schrieb ist eine Möglichkeit, dem System mitzuteilen, dass es sich einen möglichst konsistenten Zustand herstellen sollte. Das tun heutige Filesysteme schon von sich aus, weshalb plötzliche Stromausfälle üblicherweise keine inkonsistenten Zustände hinterlassen. Ähnlich ist es schon lange bei einigen Datenbanksystemen. Auch die sind auf crash consistency konzipiert, stellen also beim Start nach einem Crash einen aus Sicht des DB-Systems konsistenten Zustand wieder her. Er wäre allerdings vermessen, das von allen DB- oder Anwendungssystemen zu behaupten. Auch DB-Anwendungen sind nur crash consistent, wenn die Anwendung die Mechanismen tatsächlich adäquat nutzt. Wenn eine Anwendung so gebaut ist, dass nach einem Crash immer eine ausgiebige manuelle Reparatur erforderlich ist, dann kann kein Backupsystem dieser Welt es davor bewahren. Der Punkt (2) gibt also optional einem System die Möglichkeit, sämtliche darauf laufenden Layer darüber zu informieren, dass eine solche Operation ansteht. > Ansonsten hilft es dem TO nicht zu wissen wie es auf einem Hypervisor > oder rein unter Windows funktionieren koennte.. Von "rein unter Windows" war bei mir nirgends die Rede, weil die beschriebenen Mechanismen mit vielen Betriebssystemen funktionieren. Der Hypervisor war nur ein Beispiel dafür, wie man den für die Forderungen notwendigen Storage-Layer unter das solcherart zu sicherende System ziehen kann. Solange Festplatten sich nicht wie die Amöben von selbst teilen muss irgendwer das übernehmen, wenn wie oben effektiv gefordert wird, dass es unterhalb des Betriebssystem stattfinden soll. Ich hatte auch erwähnt, dass ein Hypervisor nicht der einzige Weg ist. Einige SAN- wie NAS-Systeme besitzen ebenfalls die dafür nötigen Fähigkeiten. Solche Systeme stellen anderen Servern Speicherplatz entweder als Fileservice (NAS) oder als Disk (SAN) zu Verfügung. Seine Fragestellung ist mir nicht neu. Das, was er schreibt, gehört zu den Aufgaben einer IT mittlerer bis grösserer Unternehmen, die Verfügbarkeit zusammen mit überschaubaren Wiederherstellungszeiten in einer heterogenen Umgebung von verschiedenen Betriebssystemen gewährleisten muss. Etwas hart ist nur die Forderung, das für lau haben zu wollen.
:
Bearbeitet durch User
Peter II schrieb: > doch macht es. Die API muss ja nicht vom Filesystem sondern vom > Betriebssystem breitgestellt werden. Dann bin ich ja mal auf die VSS API funktion gespannt die mir inkrementelle blockbasierte Backups schreibt und gleichzeitig die Details des FS verbirgt.. Irgendwie hab ich den Eindruck das wir aneinander vorbeireden.
Mladen G. schrieb: > Dann bin ich ja mal auf die VSS API funktion gespannt die mir > inkrementelle blockbasierte Backups schreibt und gleichzeitig die > Details des FS verbirgt.. wo sieht du da das Problem? mit der VSS API kann man sogar die Datenspeicher einen SQL-Server sichern ohne den internen Aufbau zu kennen.
Mladen G. schrieb: > Dann bin ich ja mal auf die VSS API funktion gespannt die mir > inkrementelle blockbasierte Backups schreibt und gleichzeitig die > Details des FS verbirgt.. Der VSS-API, auf den ich mich beziehe, dient nur dazu, zeitnah einen möglichst günstigen Zeitpunkt für einen Snapshot zu finden. > Irgendwie hab ich den Eindruck das wir aneinander vorbeireden. Ja, weil du im Windows denkst. Und ich unterhalb davon, unterhalb jedweden Filesystems.
:
Bearbeitet durch User
A. K. schrieb: > Ja, weil du im Windows denkst. Und ich unterhalb davon, unterhalb > jedweden Filesystems. aber dort muss auch eine Rückmeldung zum BS geben, ohne Zusammenarbeit mit dem BS kann es auch auf Storeebene nicht funktionieren.
Peter II schrieb: > aber dort muss auch eine Rückmeldung zum BS geben, ohne Zusammenarbeit > mit dem BS kann es auch auf Storeebene nicht funktionieren. Wenn man auf (2) verzichtet, dann ist eine Zusammenarbeit mit dem OS unnötig. Das Resultat ist dann ein Snapshot, in dem alle Schreiboperationen vor Zeitpunkt "x" durchgeführt wurden, und alle Schreiboperationen nach "x" nicht mehr Teil des Snapshots sind. Das entspricht grob der Situation eines Stromausfalls. Filesysteme wie NTFS, ext3fs und JFS können damit umgehen, DB-Systeme wie Oracle oder SQL Server ebenfalls. Nicht unbedingt völlig verlustfrei, weil das was nach dem letzten konsistenten Punkt kam verloren ist, aber das System ist in sich konsistent. Dass der optionale Punkt (2) eine Mitwirkung des Betriebssystem darstellt, somit nicht ohne es denkbar ist und eine Quittung erfordert, ist eine Binse. Hat bei VMware auch zur Folge, dass Snapshots auch schon mal mit Timeout scheitern können.
:
Bearbeitet durch User
A. K. schrieb: > Wenn man auf (2) verzichtet, dann ist eine Zusammenarbeit mit dem OS > unnötig. Das Resultat ist dann ein Snapshot, in dem alle > Schreiboperationen vor Zeitpunkt "x" durchgeführt wurden, und alle > Schreiboperationen nach "x" nicht mehr Teil des Snapshots sind. ja ok - für den Notfall. Für normale Sicherung würde ich es nicht machen. Das hat bei großen Datenbank dann eine Konsistenzcheck zur folge. Und alte OracleDBs(8) bekommt man teilweise gar nicht mehr online.
Peter II schrieb: > ja ok - für den Notfall. Für normale Sicherung würde ich es nicht > machen. Klar. Deshalb gibts ja einerseits (2) und ausserdem wird man im Bereich jener Systeme tunlichst Oracle beim Backup explizit mitwirken lassen. Aber die Forderung des TO war es, komplett ohne Kenntnis von Inhalten und File- wie Anwendungssystemen zu arbeiten, und das hat nun einmal Konsequenzen. Wunder gibts nicht. Man hat andererseits auch öfter man mit embedded Oracles und SQL Servern (Express) zu tun, bei denen sich der grosse Zirkus nicht lohnt.
:
Bearbeitet durch User
A. K. schrieb: > Ja, weil du im Windows denkst. Eher ungern ;) Nix fuer ungut, ich wirklich wir reden aneinander vorbei. Ich schrieb ja schon in meinem ersten Post dass sich die Dateien waehrendessen nicht aendern duerfen, und genau das beschreibst du und PeterII ja auch. Will ja nicht sagen dass es nicht geht, aber ein RAID, NAS oder zB. eine VM die man einfriert ist nicht das worum es hier ging, oder? Ich habe die Frage des TO so verstanden, dass er ein blockbasiertes, inkrementelles Backup will das soz. unterbrechungsfrei waehrend des Beriebes zuverlaessige Backups zieht ohne Kenntnis des Dateisystems, unter Windows, Linux und MacOS.. Klar, wenn man die Dateien in einen Konsistenenzustand bringt geht das, aber ist das dann Unterbrechungsfrei? Es geht ja auch wenn sie nicht konsistent sind.. nur weiss man dann nicht so genau was man gesichert hat ;) A. K. schrieb: > Seine Fragestellung ist mir nicht neu. Kenne diese Frage aus 2 Kontexten, einmal vom User: Am besten gaaaanz einfach, ohne dass der User was machen muss oder gar merkt.. anstatt selber die wichtigen Dinge zu sichern. Dann von der SysAdmin/Ops Seite aus, aber die stellen nicht solche Fragen in einem Elektronik Forum.
A. K. schrieb: > Wenn eine Anwendung > so gebaut ist, dass nach einem Crash immer eine ausgiebige manuelle > Reparatur erforderlich ist, dann kann kein Backupsystem dieser Welt es > davor bewahren. PS: Mit Virtualisierung geht prinzipiell auch dies, wenn der Snapshot den kompletten Stand der virtuellen Maschine einschliesst. Also inklusive Prozessorzustand und Speicherinhalt. Bei VMware ist das möglich. Nach dem Restore einer solchen VM läuft die nahtlos an genau der Stelle weiter, an der der Snapshot sie memoriert hat.
Mladen G. schrieb: > Ich schrieb ja schon in meinem ersten Post dass sich die Dateien > waehrendessen nicht aendern duerfen, und genau das beschreibst du und > PeterII ja auch. Eine Frage der Perspektive. Die Daten dürfen sich im aktiven System sehr wohl während des Backups ändern. Ein Snapshot in dem Sinn, wie ich ihn gebrauche, schränkt die Nutzbarkeit des Systems in keiner Weise ein. Auch nicht während der Backup des Snapshots weiter läuft. Der Snapshot bleibt unverändert auch wenn das System lustig weiter auf Platte schreibt. Die Daten ändern sich also permanent aus Sicht des laufenden Systems. Sie bleiben aber eingefroren aus Sicht des Backup-Systems, das nur den Snapshot betrachtet. > Ich habe die Frage des TO so verstanden, dass er ein blockbasiertes, > inkrementelles Backup will das soz. unterbrechungsfrei waehrend des > Beriebes zuverlaessige Backups zieht ohne Kenntnis des Dateisystems, > unter Windows, Linux und MacOS.. Ich auch. Und exakt das habe ich beschrieben. > Klar, wenn man die Dateien in einen Konsistenenzustand bringt geht das, > aber ist das dann Unterbrechungsfrei? Ja. Es sei denn du gehst runter auf die Millisekunden. > Dann von der SysAdmin/Ops Seite aus, aber die stellen nicht solche > Fragen in einem Elektronik Forum. Kriegen aber evtl. Antworten von einem Solchen, wenn sich zufällig einer in einem Elektronik-Forum rumtreibt. Falls das nicht schon anklang: Ich bin beruflich für diese Sorte Systeme und Backups zuständig. Die oft keine Pause machen dürfen, bloss weil ein Backup ansteht. Nur waren die nicht billig.
:
Bearbeitet durch User
A. K. schrieb: > Eine Frage der Perspektive. > > Die Daten dürfen sich im aktiven System sehr wohl während des Backups > ändern. Ein Snapshot in dem Sinn, wie ich ihn gebrauche, schränkt die > Nutzbarkeit des Systems in keiner Weise ein. Auch nicht während der > Backup des Snapshots weiter läuft. Der Snapshot bleibt unverändert auch > wenn das System lustig weiter auf Platte schreibt. > > Die Daten ändern sich also permanent aus Sicht des laufenden Systems. > Sie bleiben aber eingefroren aus Sicht des Backup-Systems, das nur den > Snapshot betrachtet. Was ist denn ein Snapshot wie du ihn meinst? Ist es denn ein inkrementelles, blockorientiertes Backup? Nur das wir nicht aneinander vorbei reden ;) A. K. schrieb: > Ich auch. Und exakt das habe ich beschrieben. Eben, ich sehe immer noch keinen Widerspruch zu meiner Aussage.. A. K. schrieb: > Kriegen aber evtl. Antworten von einem Solchen, wenn sich zufällig einer > in einem Elektronik-Forum rumtreibt. Falls das nicht schon anklang: Ich > bin beruflich für diese Sorte Systeme und Backups zuständig. Die oft > keine Pause machen dürfen, bloss weil ein Backup ansteht. Das merkt man und das wollte ich dir auch gar nicht absprechen :)
:
Bearbeitet durch User
Wenn man auf dieser Ebene arbeitet, dann muss man sich von simplen Bild einer Festplatte als streng geordnete Anordnung von Blöcken auf einem Plattenstapel lösen. Für den zu sichernden Server ist eine Festplatte zwar immer noch eine Folge von Blöcken, auf die er über irgendein Netzwerk zugreift (Fibre-Channel, iSCSI, NFS, ...). Aber für das Storage-System, das ihm diese Sicht bietet, ist diese Festplatte auch nur ein grosses File auf seinem eigenen Filesystem (zumindest bei NetApp). Das ermöglicht Freiheiten im Umgang mit Storage, die man von normalen Festplatten nicht gewohnt ist. In VMware ist das nicht anders. Auch da sieht die virtuelle Festplatte unterhalb der VM völlig anders aus als in der VM. Weshalb es in beiden Fällen (NAS/SAN, VMware) durchaus so sein kann, dass 10 direkt nacheinander stattfindende Schreibzugriffe auf den gleichen Block an 10 verschiedenen Stellen auf dem Storage-System landen.
:
Bearbeitet durch User
Mladen G. schrieb: > Was ist denn ein Snapshot wie du ihn meinst? die Daten werden woanders zwischengeparkt. Während das Backup läuft. Die Anwendung merkt also nicht davon. Wenn dann das Backup fertig ist, werde die Änderungen an die richtige stelle geschrieben.
Mladen G. schrieb: > Was ist denn ein Snapshot wie du ihn meinst? Mal sehen ob ich es in wenigen Worten schaffe. Ich beschreibe mal (A) ein modellhaftes Filesystem eines NAS, das in Zügen an NetApps Filesystem erinnert. Weiter unten (B) das Verfahren von VMware. (A) Stell dir vor, ein bestimmtes Filesystem überschreibt nie bestehende Daten auf den Disks. Sondern schreibt sie immer in unbenutzte Blöcke. Und ändert dann die Allokation dieser Blöcke in den Metadaten des Filesystems. Die also auch wiederum in neue Blöcke geschrieben werden und das rauf bis zum Rootblock des Filesystems. Gibt summarum wesentlich mehr Schreibarbeit auf den Disks, und bei random writes eine höllische Fragmentierung, aber umsonst ist der Tod. Solange dieser neue Rootblock nicht geschrieben wurde bleiben sämtliche Änderungen im Filesystem volatil, d.h. gehen mit dem Strom verschütt. Aber dafür ist das Filesystem auf Disk stets konsistent. Wenn man nun den Rootblock eines solchen Filesystems nicht einfach überschreibt, sondern die alte Version zeitweilig aufhebt, dann beschreibt dieser alte Rootblock einen völlig in sich konsistenten Stand zu einem bestimmten Zeitpunkt dieses Filesystems. Wer über den alten Rootblock zugreift, kriegt diesen alten Stand zu sehen. Wer über den aktuellen Rootblock zugreift, kriegt den aktuellen Stand zu sehen. Alles gleichzeitig. Eine Verzögerung tritt in diesem Modell in keiner Weise auf. Die Disk eines Servers kann nun ein NFS-File in diesem Filesystem sein (VMware mit NFS als Datastore), oder ein Containerfile, auf das der Server per Fibre-Channel oder iSCSI zugreift. Wenn dieses System Änderungen an den Blöcken in geeigneter Weise protokolliert, dann ist ein Backup über eine inkrementelle Spiegelung des Systems auf ein anderes solches System problemlos sehr effizient möglich. Da kann es auch sinnvoll sein, auf einem vergleichsweise billigen SATA-Spiegelsystem Snapshots über Monate oder Jahre vorzuhalten, auf dem teueren HA-Cluster mit viel geringerer Kapazität aber nur wenige Tage. (B) VMware wiederum verwaltet die Disks einer VM in einem eigenen Filesystem auf lokalen Disks oder im SAN, oder als NFS-Files auf einem NAS-System. Auch hier wird bei einem VMware-Snapshot zwar der Stand eines solchen Containers eingefroren, das verhindert aber nicht die Arbeit der Maschine. Die schreibt einfach in einen neuen Container daneben rein. Wird dieser temporäre Snapshot nach Abschluss des Backups aufgelöst, dann gibts hier etwas Arbeit für den VMware-Host, um diese Container wieder zusammen zu führen - aber auch dies ist für die VM selbst nicht sichtbar. VMware protokolliert in seinem Filesystem auch, welche Blöcke geändert wurden. Deren eigener Storage-API erlaubt es folglich, die seit der letzten Sicherung geänderte Blöcke zu sichern, und nur die.
:
Bearbeitet durch User
prx, was hälst du von Versioning Dateisystemen, wie z.B. HAMMER in DragonFlyBSD?
Hi prx, jetzt ist der Groschen gefallen! Ich nehme alles zurueck und behaupte das Gegenteil ;) Geht also doch, inkrementelle, blockorientierte Backups, ohne Unterbrechung und mit Konsistenen Dateien. Vielen Dank fuer deine Muehe, Mladen
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.