Subversion zur Datensicherung [oder andere Wege, um ein versioniertes Backup zu erstellen]

Hallo,

für unsere Firma suchen wir zur Zeit ein neues System zur Datensicherung.
Aktuell wird auf Tagesbänder (Mo, Di, Mi, Do, Fr) + 2 Monatsbänder gesichert.
Nun möchten wir das ganze jedoch ändern.
Dabei kam mir die Idee das ganze müsse sich doch eigentlich per Subversion erledigen lassen.
Heißt im Klartext:
Unser Standort bekommt eine Standleitung (um die 20Mbit) und ein externer Standort hat die Backup Server. Ein Initialbackup wird durchgeführt (um die 400Gbyte).
Nun wird jeden Tag per commit eine Tagessicherung übertragen, angenommen ca. 1Gb Daten werden geuploaded. Das ganze sichert nun also täglich per commit, hätte man ca. 2Tbyte platten verbaut wäre das genug für 2 Jahre und man könnte zwischendrin immer noch komplett Backups auf Band sichern. Das wiederherstellen sollte ja dann einfach per Version möglich sein, was haltet ihr von dieser Idee?

Für Vorschläge usw. wäre ich dankbar!

Dabei kam mir die Idee das ganze müsse sich doch eigentlich per Subversion erledigen lassen.

Also mal ganz abgesehen davon, dass ich das so in der Form nicht machen würde:

Was möchtest Du denn alles ins Backup aufnehmen? Und welches Betriebssystem kommt zum Einsatz?

Hier mal 2-3 Gedanken z udem Thema:

Noch bis zu Version 1.7 (die hoffentlich bald released wird) benötigt Subversion in jedem unterverzeichnis ein ".svn" Verzeichnis. Bei einem commit und/oder update müssen diese Verzeichnisse m. W. "gelockt" werden, was unter Windows ein seeeeehr teures (Laufzeit) Vergnügen ist (unter Linux isses wesentlich schneller). Also rein aus Laufzeitgründen würde ich mir das gaaanz genau überlegen.

Weiterhin ist der Platzbedarf nicht zu unterschätzen - denn durch die ".svn" Verzeichnisse verdoppelt sich der Platzbedarf (kannst ja mal selber prüfen: mach mal einen Checkout eines Repositories und parallel einen Export).

Unser Standort bekommt eine Standleitung (um die 20Mbit) und ein externer Standort hat die Backup Server. Ein Initialbackup wird durchgeführt (um die 400Gbyte).

Es gibt diverse Anbieter für Online-Backups - ich würde zu einem solchen Anbieter tendieren.

Oder was ich selber mache: Ich habe bei Strato das sog. "HiDrive". Das ist eine Online-Festplatte, die man über diverse Protokolle erreichen kann: rsync, ftp, smb (vie OpenVPN!). Und man kann zu selbst festgelegten Zeitpunkten auch noch ein automatisches Backup seiner Online-Festplatte durchführen lassen (Aufbewahrungszeit bis zu 36 Monate).

Ich sichere jede Nacht automatisch via "rsync" einen Datenbestant von ca. 70 GB. Durch das rsync werden halt nur die neuen/geänderten Dateien übertragen. Durch die verwendete SSL-Verbindung kann auch keiner "mithören". Dann lasse ich weiterhin 1x täglich ein Backup der Online-Festplatte durchführen. Und dann ist die Online-Festplatte auf Strato-Seite eh 2x vorhanden, da Strato zwei RZs betreibt, die sich synchonisieren....

So mache ich das 😉

Strato hat (leider?) noch immer den Ruf eines Billig-Anbieters. Wie dem auch sei, was die technische Infrastruktur betrifft sind die Jungs dem Mitbewerb um einiges voraus (kein anderer von mir seinerzeit evaluierter Mitbewerber betreibt beispielsweise zwei synchronisierte RZs)...

Bye,
MK

P.S.: Das Initialbackup kann bei Strato auch per FedEx-Network durchgeführt werden (die schicken Dir ne Platte zu - vermutlich mit einem TrueCrypt Container - die Du befüllst und dann zu Strato zurückschickst).

P.P.S.: Die Daten liegen bei Strato verschlüsselt auf den Plattensubsystemen. Die Jungs von Strato kommen selber auch nicht an die Klartextdaten... Auch nicht bei einem richterlichen Beschluss ;->

P.P.P.S.: Durch die ISO27001-Zertifizierung bei Strato sowie dem RZ-Standort DE kommst Du auch nicht in Konflikt mit dem Deutschen Datenschutzgesetz....

P.P.P.P.S.: So jetzt aber genug... und NEIN, ich bekomme von Strato keine Provision - ich halte das HiDrive nur für ein gutes Produkt... nicht mehr und nicht weniger.....

Online Backups wie Strato bietet auch die Datev an, in diesem Falle käme Datev in Frage. Mir ist klar das die .svn Ordner beim Checkout den Doppelten Speicherbedarf benötigen, jedoch habe ich ein Script was diese in Sekunden löschen könnte.
Die Sache ist die, das die Wiederherstellungsdaten nicht auf der Quelle gelagert würden, heißt, wenn man Daten wiederherstellt bleibt die Basis frei von .svn Ordnern. Außerdem wird ja im Falle einer Datenwiederherstellung nicht das komplette Backup neu gezogen sondern nur einzelne Verzeichnisse.
Eingesetzt wird Windows Server 2008 r2, die Sicherung umfasst Datenbanken usw.
Wenn ich mich nicht täusche lädt subversion die Änderungen auf Bitlevel auf den Server? Oder täusche ich da?

Den Vorteil würde ich in der Versionierung sehen, denn so könnte man ohne großen Aufwand quasi jeden Bestand wiederherstellen.

Hallo 1mannlan,

ich rate von Subversion hierbei auch ab. Die Stärke von SVN liegt in textbasierten Dateien, da dort nur das Diff übertragen werden muss. Bei Binärdateien kann dieses afaik nicht ermittelt werden und es wird (basierend auf dem Timestamp) die ganze Datei übertragen. Somit wird ein Vorteil zu nichte gemacht.

Eine vernüftige Alternative kann ich keine vorschlagen.

mfG Gü

Nunja wenn ganze Dateien übertragen würde wäre das nicht so schlimm, ansonsten müsste man eben einen Speziellen Dienst hierfür nutzen. Die Datenmenge außer acht gelassen ließe sich somit eine Menge Geld sparen die Frage ist eher ob das überhaupt möglich wäre, auch wenn das viele Daten rüber müssten, besser als 100 Voll Backups auszulagern meine ich.

@1mannlan
Subversion ist vollkommen ungeeignet für dein Vorhaben.

Du willst doch nicht von den Mitarbeitern verlangen, dass jede Dateioperation über z.B. TortoiseSVN durchgeführt wird, oder?
Wenn Dateien einfach wie gewohnt kopiert, gelöscht und verschoben werden, hast Du bei jedem Commit unzählige Fehler von Hand aufzulösen -> Horror

Gedacht ist das ganze Nachts, wenn keiner mehr Arbeitet durchzuführen, dann werden einfach die bearbeiteten Daten hochgeladen so die Vorstellung.
Vom Prinzip klingt das für mich einfach so als wäre subversion wie dafür gemacht, bis auf das die Daten nicht auf Binärebene abgeglichen werden.

Du musst aber die Inkonsistenzen auflösen wenn die Mitarbeiter den ganzen Tag Dateioperationen OHNE Tortoise ausführen.

Hast Du schonmal mit SVN gearbeitet? Dann versuche es mal.

Es ist ungeeignet für deine Zwecke.

Ich hatte nur mal eine Repo erstellt und an googlecode commited, von inkositenzen u.ä. wusste ich nichts. Wie treten diese auf?
Werden nicht einfach Dateien die z.B. in Rev +1 nicht mehr existieren einfach nicht mehr hochgeladen? (Beispiel)

Oder hättet ihr eine andere Idee wie man das ähnlich mit Versionierung lösen könnte?

Hallo,

die Inkosistenzen treten auf, wenn Dateien ganz normal im Windows-Explorer verschoben/gelöscht/angelegt werden.

Neue Dateien müssen z.B. grundsätzlich erstmal zur Versionierung hinzugefügt werden (add), fehelende Dateien (ohne Nutzung eines SVN-Tools gelöscht/verschoben) werden als "missing" markiert und kommen wenn es nicht bestätigt wird beim nächsten Update wieder mit usw.

Es ist halt so: Subversion ist ein Versionierungstool, und für Backups in dieser Form einfach nicht geeignet.

Gruß, MarsStein

Wenn dies so ist, kennt ihr vielleicht Software die nach dem Prinzip Arbeitet die wir suchen?

Hallo 1mannlan,

schau mal was die Forumssuche nach synctoy liefert. Eines davon hat m.knigge ja schon mit rsync genannt.

mfG Gü

Wenn dies so ist, kennt ihr vielleicht Software die nach dem Prinzip Arbeitet die wir suchen?

Für meine Zwecke habe ich kürzlich 7zip entdeckt. Vorher habe ich ntbackup genutzt, dass wegen Probleme beim Erstellen der Schattenkopien rausgeflogen ist. Vielleicht reicht das für deine Zwecke auch. Als Grundlage habe ich diesen Blogeintrag genutzt.

In deinem Fall würde das allerdings bedeuten, dass du (wahrscheinlich) das Vollbackup auf den Clientmaschinen und am Server bereithalten musst. Ansonsten würde der Abgleich was gesichert werden muss viel zu lange dauern. Die inkrementellen "Päckchen" müsstest du dann aber relativ problemlos übertragen können.

Vielleicht einfach mal reinschauen. Ich war überrascht was 7zip so drauf hat.

Hi,

Wenn dies so ist, kennt ihr vielleicht Software die nach dem Prinzip Arbeitet die wir suchen?

Welches "Prinzip" meinst Du denn jetzt? Das Prinzip "es werden nur Unterschiede übertragen" oder das Prinzip "versioniertes Backup"?

Also eigentlich sollte jede vernünftige Backup-Software, die diesen Namen auch verdient hat, beides beherrschen....

Wie gesagt... rsync kann prima nur die Unterschiede übertragen - sogar bei Binärdateien. Und da es OpenSource ist und für diverse Betriebssysteme zur Verfügung steht, steht einem unternehmensweitem Einsatz nix im Wege. Wir setzen beispielsweise ein buntes Potpourri an Systemen ein: Windows, Solaris, AIX, Linux, früher auch mal eine Zeit lang HP-UX und noch z/OS (ok, da verwenden wir kein rsync). Und eben diese bunte Mischung unterstützt(e) keine Backup-Software, die halbwegs bezahlbar ist... daher haben wir uns selber etwas mit rsync gebastelt, das auch noch hervorragend funktioniert...

Wenn Ihr jetzt beispielsweise noch Solaris Know-How im Hause habt, dann wäre eine "Self-Made" Lösung, alles via rsync auf einen Solaris Server zu übertragen, der mit einem ZFS-Dateisystem arbeitet. Dort kann man prima und platzsparend jederzeit einen Snapshot des gesamten Dateisystems machen (der fast keinen Platz benötigt) und kann auf jeden gemachten Snapshot jederzeit wieder zugreifen.

Ich habe vor etwa zwei Jahren mal jedmanden kennengelernt, der alle 2 Sekunden auf seinem Solaris Server einen Snapshot anfertigt und somit mehr oder weniger ein versioniertes Dateisystem hat - und er kann wie gesagt jederzeit auf einen in der Vergangenheit angefertigten Snapshot zugreifen....

Bye,
Michael

Hallo!

In unserer Firma verwenden wir für unsere Kunden Mozy. Das Backup wird online abgelegt (ich vermeide mal das Buzzword Cloud 😄). Zur Verschlüsselung der Daten kann man verschiedenen Mechanismen verwenden.
Initial muss natürlich alles übertragen werden, aber danach werden nur noch Änderungen übertragen, das Programm versucht dabei, die Änderungen auf Sektor-Ebene zu übertragen.

Es geht wenn da nicht richtig klar wurde um Versionierte Backups. Heißt:
Tag 1:
Es wird ein Vollbackup angelegt alle Daten die gesichert werden sollen werden übertragen.
Tag 2-crash:
Es werden alle Änderungen zum vorherigen bzw Hauptbackup übertragen, jedes Teilbackup erhält eine einzelne Versionierung.
Tritt nun am Tag X, sagen wir 634, ein Fehler auf, welcher Daten von Tag 267 benötigt wird folgende Version herausgesucht und wiederhergestellt.
Deshalb kam mir ja auch die Idee mit Subversion was ja im Prinzip genau sowas bietet.

Hallo 1mannlan,

die c't hat mal ein sehr einfaches Verfahren beschrieben, das auf Hardlinks basierte. Dabei wurde jeden Tag die komplette Verzeichnisstruktur kopiert, aber wenn sich eine Datei gegenüber den letzten Stand nicht verändert hatte, wurde in der neuen Verzeichnisstruktur nur ein Hardlink auf die bestehende Datei gesetzt. Ein Backup, bei dem sich wenige Dateien geändert haben, hat daher nur ein Bruchteil des Platzes gekostet, war aber genauso komplett und übersichtlich, wie ein vollständiges Backup.

herbivore

Warum denn alles so kompliziert?
Dieses "Problem" hat so ziemlich jede Firma mit einer IT Infrastruktur.

Wir verwenden Acronis True Image Echo Server. Und an 300€ für die Datensicherheit sollte es nun wirklich nicht scheitern.

@mo#
Wie es scheint erstellt das aber keine Versionsabfolge. Das rsync jedoch klingt wirklich nach der Lösung, der einzige wenn auch fatale Haken ist eben das man keine geöffneten Dateien sichern kann, ob das so funktioniert muss ich mal schauen.
Im Notfall wird eben der Gesamte Bestand erst umkopiert und dann gesichert.

Was verstehst du unter Versionsabfolge?
True Image kann (wie jedes andere Backup-Programm) diffentielle Backups machen.
Also eine Vollsicherung und dann jeden Intervall nur die geänderten Dateien.

Man kann somit relativ einfach und selektiv Emails, Dateien, DB etc. nach Datum wiederherstellen (natürlich auch den kompletten Sicherungsstand)...

Hallo mo#,

die Kosten für das Backup-Programm wird wohl wirklich keine Rolle spielen. Die Kosten für das Handling und evtl. den Speicherplatz schon eher. Am meisten Speicherplatz spart man durch inkrementelle Backups. Und sicher sollte jedes professionelle Backup-Programm inkrementelle (und differenzielle) Backups unterstützen. Keine Frage. Aber das bedeutet noch nicht, dass Handling praktikabel ist. Gerade bei inkrementellen Backups (um die es hier ja geht) kann es zur Sisyphusarbeit werden, die Sicherung ausfindig zu machen, in der sich der aktuelle Stand einer bestimmten Datei befindet. Das Problem hat man bei dem Vorschlag der c't gerade nicht.

Trotzdem wird man das Geld für ein Backup-Programm gerne ausgeben, aber eben nur wenn es wirklich leistet, was man braucht. Das ist leider nicht selbstverständlich.

herbivore

PS:

... diffentielle Backups machen. Also eine Vollsicherung und dann jeden Intervall nur die geänderten Dateien.

Das nennt man inkrementell, nicht differenziell. Differenziell wäre es, wenn man alle seit der letzten Vollsicherung geänderten Dateien sichert und nicht nur die, die sich im letzten Intervall geändert haben.

Also in Backup exec was wir hier haben gibt es eine solche Funktion, wie gut das funktioniert muss ich mal testen, das mit den Ordner die direkt alle als Voll-Backup angezeigt werden sieht halt gut aus.
Ein differentielles Backup wäre denke ich schon das sinnvollste, es werden alle Veränderungen zum Voll-Backup gesichert right?

Aber das bedeutet noch nicht, dass Handling praktikabel ist. Gerade bei inkrementellen Backups (um die es hier ja geht) kann es zur Sisyphusarbeit werden, die Sicherung ausfindig zu machen, in der sich der aktuelle Stand einer bestimmten Datei befindet.

Ich muss nochmal mit unseren Admins reden, aber so wie ich das im Kopf habe ist bei unserem Backuptool der Restore nicht dateiabhängig (also nicht wie früher einzelne Archive) sonder man läd alle Back-Dateien in das Restoretool und kann dann explizit Dateien eines spezielen Standes wiederherstellen und zwar alle Dateien aller Stände welche in allen geladenen Backups enthalten sind.
Somit lassen sich meiner Meinung nach sehr effektiv und selektiv Dateistände restoren.
In der Bedienung ja fast wie ein SVN mit Versionhistorie und Changesets....

Es gibt da auch kostenlose Testversionen wo man soetwas mal durchspielen kann...

Das nennt man inkrementell, nicht differenziell.

Inkrementell, mein ich doch 😉

Die Sache ist die, das beim Inkrementellen Backup alle vorhergehenden Sicherungen benötigt werden. Backup Excec beschreibt: "Inkrementell - Seit letzem vollständigen oder inkrementellen Backup geänderte Dateien sichern".
Klingt für mich nach, es wird immer das letzte Backup hergenommen, denn eine zweite Box was man nun möchte ist dort nicht.
Zum Thema differentiell bin ich auf das hier gestoßen:
Backup-Archivbit-Problem (umbenannte oder verschobene Verzeichnisse)
Ist dies bei Windows Server 2008 r2 auch so? Dann wäre ja die Datensicherheit nicht gewährleistet.

Die Sache ist die, das beim Inkrementellen Backup alle vorhergehenden Sicherungen benötigt werden.

Das geht ja auch nicht anders. Sonst musst du ja Vollbackups machen wenn du jedes Backup komplett eigenständig willst?

Hallo zusammen,

Backup-Archivbit-Problem (umbenannte oder verschobene Verzeichnisse)

Sonst musst du ja Vollbackups machen wenn du jedes Backup komplett eigenständig willst

vielleicht wird bei diesen ganzen Problem doch langsam klarer, was das geniale an dem Vorschlag der c't ist. 😃 Man hat (virtuell) immer ein Vollbackup, aber trotzdem nur die Datenmenge eines inkrementellen. Ich will ja nicht behaupten, dass ein gutes Backup-Programm das nicht auch hinbekommt - aber selbstverständlich ist das eben leider nicht.

herbivore

Klar das nicht jedes Backup eigenständig sein kann, aber rsync gaukelt genau das vor, heißt man sieht für jedes Teilbackup ein Vollbackup. Interessanter wäre jedoch das mit dem Archivbit, klingt nämlich nach einem nicht zu unterschätzendem Problem.
Das Problem an der Lösung an c't ist eben der Zugriff auf die Daten, wie siehts dort mit Archivbit aus?

Hallo 1mannlan,

Das Problem an der Lösung an c't ist eben der Zugriff auf die Daten,

nein, im Gegenteil. Der einfache Zugriff auf die Daten ist das gute an der Lösung.

wie siehts dort mit Archivbit aus?

kann ich nicht genau sagen. Letztlich ist es aber wohl ein Script, das man selber anpassen kann. Ob man also das Archivbit verwendet oder nicht, ist die eigene Entscheidung.

herbivore

nein, im Gegenteil. Der einfache Zugriff auf die Daten ist das gute an der Lösung.

Damit meinte ich den Bug, das geöffnete Dateien nicht kopiert werden können.

Hallo 1mannlan,

==> Schattenkopien.

herbivore

Hm...
ich wüsste nicht was mir Schattenkopien bringen sollten, dadurch wird die Datei zum Lesen auch nicht freigegeben.

Hallo 1mannlan,

du kannst aber wenigstens einen halbwegs aktuellen und konsistenten Stand der Datei - eben die Schattenkopie derselben - sichern.

herbivore

Nun das ist aber absolut nicht das was man sich unter einem Backup vorstellt 😉.
Ich muss mal schauen, entweder ich finde eine Lösung zum entsperren der Daten oder nutze differentielle Backups.

Hallo 1mannlan,

Nun das ist aber absolut nicht das was man sich unter einem Backup vorstellt 😉.

du vielleicht nicht, man schon. 😃 Jedenfalls sind Schattenkopie genau dafür gemacht. Eine optimale, jedem denkbaren Fall abdeckende Lösung ist schon theoretisch ausgeschlossen. Da musst du dich mit den Realitäten abfinden.

entweder ich finde eine Lösung zum entsperren der Daten

Entsperren geht schon mal gar nicht, außer man schließt den Prozessen die offenen Dateien unter dem Hintern weg, was unvorhersehbaren Auswirkungen auf die Stabilität der Anwendung, des Systems und der Konsistenz der Dateien hat und sich deshalb von vornherein verbietet oder man verwendet den passenden FileShare-Mode (oft genug besprochen), was aber nur geht, wenn die Anwendung, die die Datei offen hat, auch den passenden FileShare-Modus verwendet hat, also kooperativ ist. Wenn nicht, helfen nur Schattenkopien.

oder nutze differentielle Backups.

Ob differenziell, inkrementell oder Vollbackup, macht allenfalls einen Unterschied bezüglich der Wahrscheinlichkeit, auf gesperrte Dateien zu treffen, löst aber das Problem nicht prinzipiell. Das tut der FileShare-Modus (aber eben auch nur begrenzt) und eben die Schattenkopien.

Ich denke, wir haben jetzt alle relevanten Punkte beleuchtet und kommen außerdem zunehmend vom Thema ab. Wir sollten zum Ende kommen.

herbivore

...kommen außerdem zunehmend vom Thema ab.

Dann komme ich mal zum Thema zurück. Ich mache meine Backups mit QdtSync, das funktioniert im Prinzip wie der oben erwähnte Skript aus der c't, aber halt ohne die ganzen Unix-Tools.

Sorry das ich jetzt erst wieder schreibe, war zu beschäftigt.
@MrSparkle
Das Tool von dir setzt auch auf rsync und hat deshalb den gleichen Bug, dennoch bietet es ein schöneres GUI Planung usw. an.
Ich habe im Tool die Funktion Synchronisation entdeckt, wenn ich damit in einem Temp Verzeichnis immer alle aktuellen Dateien bereithalte lässt sich dieser vielleicht umgehen. Werde das mal Testen und dann hier berichten.

Hallo 1mannlan,

dass geöffnete Dateien nicht (ohne Weiteres) kopiert werden können, ist kein Bug, sondern ein Feature! Das ist weitgehend anerkannt. Auch professionelle (Backup-)Programme können sich nicht über die Gegebenheiten hinwegsetzen. Hier gilt also "Works as designed".

Wie schon weiter oben gesagt, können die beteiligten Prozesse über den FileShare-Modus steuern, ob bzw. in welchen Situationen ein Kopieren möglich ist. Standardmäßig können Dateien von mehreren Prozessen gleichzeitig gelesen werden, aber wenn ein Prozess auf die Datei schreibt, dann ist es gut, dass standardmäßig das Lesen durch andere Prozesse verhindert wird, damit diese keine inkonsistenten Stand auslesen. Könnte sich ein (Backup-)Programm darüber hinwegsetzen, würde wäre der Teufel mit dem Beelzebub ausgetrieben werden, statt leicht zu erkennende Inkonsistenzen durch fehlend Dateien bekäme man schwer zu erkennende Inkonsistenzen im Dateiinhalt. Die schon genannten Schattenkopieren sind ein Kompromiss, um einen zwar nicht 100%ig aktuellen, aber in sich konsistenten Stand einer (zum Schreiben) geöffneten Datei zu erhalten.

Es ist wichtig, diese Aussagen deiner Einschätzung gegenüber zu setzen. Weiter diskutieren sollten wir das bitte nicht, weil wir sonst wieder von Thema abkommen. Jeder kann und soll sich da seine eigene Meinung bilden.

herbivore