Sicherung auf externer Platte

[Macflieger]

Hallo,

ich habe eine DS209 und wollte ab und zu mal eine Sicherung auf einer externen USB-Platte machen.

Jetzt habe ich da drei Fragen.

1. Ist es richtig, dass der USB-Anschluss vorne schneller als der Anschluss hinten ist? Bei ein paar Tests variierte die Geschwindigkeit auch an einem Anschluss für den gleichen Job erheblich. Aber der vordere schien einen Tick schneller zu sein. Täuschung oder echt?

2. Das Backup dauert ja teilweise ziemlich lange. Was ist denn, wenn sich während des Backups Dateien ändern (bei mir machen mehrere Macs zwischenzeitlich TimeMachine-Backups)? Bekommt man dann ein inkonsistentes Backup oder arbeitet die DS intern mit Schattenkopien?

3. Ich habe zwei verschiedene USB-Platten und möchte darauf abwechselnd das Backup machen. Eine wird jeweils ausser Haus woanders gelagert, die andere jeweils, um ein neues Backup anzulegen. Wird das problemlos funktionieren, wenn bei jedem Backup immer die jeweils andere Platte dran steckt?

Tschö, MacFlieger

 

[atmik]

Hallo,

ich habe eine DS209 und wollte ab und zu mal eine Sicherung auf einer externen USB-Platte machen.

Jetzt habe ich da drei Fragen.

1. Ist es richtig, dass der USB-Anschluss vorne schneller als der Anschluss hinten ist? Bei ein paar Tests variierte die Geschwindigkeit auch an einem Anschluss für den gleichen Job erheblich. Aber der vordere schien einen Tick schneller zu sein. Täuschung oder echt?

Grundsätzlich ist das so mit den front- und rückseitigen Steckern: Die Buchse AUF DEM BOARD ist im Grundsatz immer schneller weil die Buchse auf das Board gelötet ist. Die Frontbuchsen von Gehäusen sind in der Regel langsamer und haben nicht diesselbe Spannung/Leistung da quasi ein Adapter zwischen Board und Gehäuse ist= Verlust von Spannung und Leistung. ABER: Es gibt ganz wenige Gehäusebauer die hochwertiger bauen. Generell kann man sagen, dass bei Billiggehäusen die Frontstecker ganz schlecht sind und für grosse Datentransfers nix taugen.

2. Das Backup dauert ja teilweise ziemlich lange. Was ist denn, wenn sich während des Backups Dateien ändern (bei mir machen mehrere Macs zwischenzeitlich TimeMachine-Backups)? Bekommt man dann ein inkonsistentes Backup oder arbeitet die DS intern mit Schattenkopien?

kann ich nicht beantworten

3. Ich habe zwei verschiedene USB-Platten und möchte darauf abwechselnd das Backup machen. Eine wird jeweils ausser Haus woanders gelagert, die andere jeweils, um ein neues Backup anzulegen. Wird das problemlos funktionieren, wenn bei jedem Backup immer die jeweils andere Platte dran steckt?
Sofern in der Verwaltung die Festplatten korrekt mit USBShare1 und USBShare2 erkannt werden kannst du 2 Backupaufträge erstellen mit dem Ziel der jeweiligen Platte und die, die du ausser Haus lagerst nicht automatisiert sondern manuell "anstossen" für das Backup.

...siehe oben

 

[Macflieger]

Danke schon mal für die Antwort.

Grundsätzlich ist das so mit den front- und rückseitigen Steckern:...

Ja, wie das prinzipiell bei vielen von diesen PCs ist, weiß ich. Die Frage ist ja, wie ist es bei der DS209?

Sofern in der Verwaltung die Festplatten korrekt mit USBShare1 und USBShare2 erkannt werden kannst du 2 Backupaufträge erstellen mit dem Ziel der jeweiligen Platte und die, die du ausser Haus lagerst nicht automatisiert sondern manuell "anstossen" für das Backup.

OK, muss ich mal schauen, ob die unterschiedlich erkannt werden.
Manuell muss ich sowieso beide Backups anstossen. Das ist klar.
Du hast mich da auch etwas falsch verstanden. Beide sollen abwechselnd ausser Haus gelagert werden. Also immer eine ausser Haus und die andere hier, auf dem das Backup aktualisiert wird, und danach Tausch. So ist immer ein Backup woanders in Sicherheit.

 

[Trolli]

Kann sein, dass Du für das Backup so vorgehen musst:
-> http://www.synology-wiki.de/index.php/Alternierendes_Backup

 

[atmik]

Die Frage ist ja, wie ist es bei der DS209?

...onboard immer besser als Front Auch die DS ist nur ein PC Case...ich glaub es hat noch keiner einen Benchmark gemacht...

 

[itari]

Antwort zu 2: Es gibt erst bei der Verwendung des neuen TimeBackup (von Synology) so etwas ähnliches wie Schattenkopien, wobei eigentlich ein LVM-Snapshot gemacht wird ... aber es ist ja auch egal wie man das bezeichnet.

Und auf deine Frage kann ich keine wirkliche Antwort geben, ob bei der Datensicherung einer sehr großen Datei Inkonsistenzen auftreten, weil der rsync ja ggf. auf Blockebene sichert. Ich schätze mal nicht, sonst hätte das hier schon eine Diskussion ausgelöst. Aber wenn du ganz sicher gehen willst, dann frage doch mal per E-Mail beim Synology-Support nach und veröffentliche deren Antwort hier.

Itari

 

[Merthos]

Es kann zu Inkonsistenzen kommen, wenn die Dateien gerade verwendet werden.

http://lists.samba.org/archive/rsync/2001-December/000828.html

 

[Macflieger]

...onboard immer besser als Front Auch die DS ist nur ein PC Case...ich glaub es hat noch keiner einen Benchmark gemacht...

Ja, das dachte ich auch. Wie im Eingangsposting erwähnt, habe ich bei einem kleinen Backup-Test (1x vorne, 2x hinten, 1x vorne) mit einem 14,5GB-Ordner bekommen:
vorne: 10,5 und 12 Minuten
hinten: 13,5 und 14,5 Minuten
Also ziemlich schwankend und vorne scheinbar einen Tick schneller. Deshalb ja meine Ursprungsfrage. Fand ich merkwürdig.
Naja, nicht so wichtig.

Antwort zu 2: Es gibt erst bei der Verwendung des neuen TimeBackup (von Synology) so etwas ähnliches wie Schattenkopien, wobei eigentlich ein LVM-Snapshot gemacht wird ... aber es ist ja auch egal wie man das bezeichnet.

Ist das dann wirklich ein Snapshot, d.h. wenn sich der Inhalt der DS während des Backups (dass ja durchaus 10 und mehr Stunden dauern kann) ändert, wird trotzdem der Zustand zum Zeitpunkt des Snapshots gesichert?
Ist das TimeBackup nicht aktuell eine Beta-Version?

Und auf deine Frage kann ich keine wirkliche Antwort geben, ob bei der Datensicherung einer sehr großen Datei Inkonsistenzen auftreten, weil der rsync ja ggf. auf Blockebene sichert.

Ne, ich meinte nicht Inkosistenzen innerhalb einer Datei (das glaube ich auch nicht), sondern Inkonsistenzen zwischen den Dateien. Das Problem kenne ich nämlich von rsync.
Beispiel:
Ein Ordner mit zwei Dateien A und B. Das Backup wird gestartet. Während Datei A gesichert wird, ändert jemand Datei B oder löscht diese. Was passiert dann?
- Es wird trotzdem die ursprüngliche Datei B gesichert, also der Zustand zum Startzeitpunkt des Backups, d.h. Schattenkopie bzw. Snapshot? Das führt zu einem konsistenten Backup, der dem Zustand zu dem Startpunkt des Backups entspricht. So funktioniert z.B. auch TimeMachine auf dem Mac.
- Oder es wird die geänderte Datei B gesichert bzw. Datei B gar nicht, wenn diese zwischenzeitlich gelöscht wurde. Das kenne ich als normales Verhalten von rsync, als ich das noch vor Erscheinen von TimeMachine auf dem Mac benutzt habe. Das führt aber zu inkosistenten Backups, d.h. Dateien die zuerst gesichert werden stammen von einer anderen Zeit als die, die zuletzt gesichert werden. Das ganze führt um so häufiger zu Problemen, je größer das Backup ist (d.h. je länger der Backup-Vorgang dauert), je häufiger eine Änderung der Daten stattfindet und(!) je mehr Daten man hat, bei denen die Konsistenz aus dem Zusammenspiel von mehreren Dateien her rührt. Und genau das letztere ist bei TimeMachine-Backups der Fall. Diese bestehen aus vielen kleinen Dateien, die zusammen ein Image ergeben, in dem alle Backups eines Macs enthalten sind. Werden von diesen vielen Dateien einige vom Zeitpunkt x und andere vom Zeitpunkt y gemischt, hat man ein defektes Image. D.h. ein solches Backup der DS wäre unbrauchbar.

Es kann zu Inkonsistenzen kommen, wenn die Dateien gerade verwendet werden.

ARGH!
Und das normale Backup der DS verwendet rsync? Dann wäre das tatsächlich unbrauchbar für meine Zwecke. Oder ich müsste jedes Mal für viele Stunden die Dateifreigabe deaktivieren. Kann man das scripten?
Oder eben dieses TimeBackup verwenden. Gibt es da genügend positive Erfahrung mit und kann man das auch verschlüsselt machen?

 

[itari]

Es kann zu Inkonsistenzen kommen, wenn die Dateien gerade verwendet werden.

http://lists.samba.org/archive/rsync/2001-December/000828.html

Interessant, das zu lesen. Nun sind schon einge Jahre ins Land gezogen; es könnte also sein, dass man dieses Problem mittlerweile im Griff hat. Ich hab es mir nicht genau angeschaut, aber macht der rsync nicht laufen Abgleiche über inter gehaltene Dateiliesten, ob sich irgendwo etwas verändert hat? Deswegen ist ja der rsync auch immer so trottelig beim Backup ...

Itari

 

[Merthos]

Das Backup wird gestartet. Während Datei A gesichert wird, ändert jemand Datei B oder löscht diese.
...
Dann wäre das tatsächlich unbrauchbar für meine Zwecke.

Es gibt generell kein Backupprogramm, was diese Anforderung direkt erfüllt. Sowas geht immer nur im Zusammenspiel mit der jeweiligen Anwendung. Auch wenn man z.B. Snapshots über das gesamte Dateiset verwendet, müssen diese ja zu einem Zeitpunkt gemacht werden, wo ein konsistenter Zustand über alle Dateien besteht.

Nun sind schon einge Jahre ins Land gezogen; es könnte also sein, dass man dieses Problem mittlerweile im Griff hat. Ich hab es mir nicht genau angeschaut, aber macht der rsync nicht laufen Abgleiche über inter gehaltene Dateiliesten, ob sich irgendwo etwas verändert hat? Deswegen ist ja der rsync auch immer so trottelig beim Backup ...

Ich wüsste nicht, was sich seitdem geändert haben sollte. Für sowas müssten ja dateisystemspezifische Features (z.B. Schattenkopien) herangezogen werden, und das kann ich mir nicht vorstellen, dass solche Extrabehandlungen drin sind. Mal abgesehen davon, dass ext da nicht so viel bietet.

Ansonsten arbeitet rsync für den Änderungsvergleich mittels Hashwerten über die Dateien, bzw. dann über Teile der Dateien. Gespeicherte Listen werden mWn nicht verwendet.

 

[Macflieger]

Es gibt generell kein Backupprogramm, was diese Anforderung direkt erfüllt. Sowas geht immer nur im Zusammenspiel mit der jeweiligen Anwendung. Auch wenn man z.B. Snapshots über das gesamte Dateiset verwendet, müssen diese ja zu einem Zeitpunkt gemacht werden, wo ein konsistenter Zustand über alle Dateien besteht.

Das stimmt. Wobei Time Machine auf dem Mac das anscheinend recht gut im Griff hat. Ob das wirklich alle Probleme abfängt und wie, weiß ich nicht.
Aber um auf die DS zurückzukommen: Da das Backup ja viele viele Stunden dauern kann und z.B. Mac in der Standardeinstellung jede Stunde ein neues TimeMachine-Backup anlegen, ist die Gefahr einer Kollision sehr groß bis sicher.

Muss ich mir was anderes einfallen lassen. Deshalb ja die obigen Fragen zu TimeBackup und ob dort die Probleme auch auftreten können.

Ansonsten arbeitet rsync für den Änderungsvergleich mittels Hashwerten über die Dateien, bzw. dann über Teile der Dateien. Gespeicherte Listen werden mWn nicht verwendet.

Was an dem eigentlich Problem nichts ändert, denn dann hat man Datei A in der alten Version und Datei B in der neuen, die zusammen dann ein defektes Image bilden.
Un bei meinen Erfahrungen mit rsync war es so, dass ich für jede Datei, die zwischenzeitlich gelöscht wurde, eine Fehlermeldung bekam, d.h. da muss es so etwas wie eine Liste gegeben haben. Evtl. macht das eine aktuelle rsync-Version aber anders.

 

[itari]

Interessante Diskussion bislang. Ich suche gerade, ob es zu dem rsync etwas Neues gibt hinsichtlich der Datei-Konsistenz. Auf eine Möglichkeit bin ich schon gestossen *lies hier* und ich meine, dass es in ähnlicherweise beim Time Backup auch so gemacht wird.

Offen bleibt, ob man den normalen rsync nur dann machen sollten, wenn die Originale nicht gerade in Bearbeitung sind.

Itari

 

[jahlives]

100% Datenkonsistenz bei einem Backup aus einem laufenden System heraus wird es niemals geben können. Konsistente Backups gibt es wohl nur wenn das betreffende Betriebssystem ned läuft.
Wenn du mit rsync z.B. über die Datenbankfiles gehst und die DB gleichzeitig unter heftigem Zugriff steht, dann kannst du fast zu 100% sicher sein, dass rsync die DB nicht in einem gänzlich konsistenten Zustand haben wird. Wenn du Glück hast, dann hast du "nur" nicht den allerletzten Zustand. Wenn du aber Pech hast, dann stehen in den einzelnen Tabellen dann Werte, welche sich widersprechen und die Applikation auf die Nase fallen lassen.

Gerade bei Datenbanken darf der jeweilige Prozess nicht laufen, wenn man ein filebasiertes Backup machen will. Bei DBs würde ich die Verwendung der DB-dump-Tools empfehlen, weil diese auf DB-Ebene arbeiten und z.B. Tabellen und DBs sperren können. Zudem kann man dann Transaktionen haben, welche garantieren (sollten), dass der Job von A-Z sauber durchgelaufen ist

 

[Macflieger]

Ich gebe Dir ja Recht, vor allem bei dem Spezialfall DB. Dort wird ja auch viel im RAM gehalten und erst bei Bedarf auf Platte geschrieben. Für die DB benutze ich dann eben zusätzlich mysqldump, welches regelmäßig speichert.

Aber wie gesagt, abgesehen davon scheint es Time Machine sehr gut hinzubekommen. Da werden stündlich bei Millionen von Leuten Backups des laufenden Systems gemacht und man kann das komplette System davon wiederherstellen. Warum und wie die das genau machen, keine Ahnung. Ist ja aber auch für die Fragestellung hier egal.

Für mich kristallisiert sich heraus:
Am besten die Freigaben deaktivieren, Backup auf externe Platte machen und danach wieder einschalten. Das sollte die Probleme umgehen.
Kann man halt viele Stunden keine TimeMachine-Backups machen, aber das kann ich ja auch in die Nacht verlegen.

Bliebe noch die Frage, ob und wie man das scripten kann.

 

[itari]

Vielleicht könnte sich ein Mac-User einmal mit dieser Problematik an den Synology-Support wenden, um Klarheit darüber zu erhalten nud es uns hier berichten. Das Datenbank-Backup läuft ja eh auf eine andere Weise (also nicht per rsync).

Itari

 

[Macflieger]

Ja, mache ich. Obwohl wir die Antwort ja schon kennen. Da kein Snapshot gemacht wird, muss es schief gehen.

 

[trevorreznik]

Wenn du Glück hast, dann hast du "nur" nicht den allerletzten Zustand. Wenn du aber Pech hast, dann stehen in den einzelnen Tabellen dann Werte, welche sich widersprechen und die Applikation auf die Nase fallen lassen.

Man darf dabei nicht vergessen, dass rsync ein Tool zum Synchronisieren von Dateien und Verzeichnissen ist und kein Backup-Tool (es heisst ja auch rsync und nicht rback).

Rsync analysiert einzeln jede Quell- und Zieldatei auf Gemeinsamkeiten und Unterschiede und überträgt dann lediglich die Differenzen von der Quelle zum Ziel. Für die Bandbreite ist das sehr gut, für die Verarbeitungsgeschwindigkeit und CPU-Auslastung ist das aller dings nicht so toll. Wer allerdings 20GB Backups hat mit geringen Änderungen bei einem 512kbit upload, der freut sich natürlich.

Wenn während der Synchronisierung von Datei A zum Zeitpunkt x die Datei B verändert wird, dann hat man A(x) und B(x+1). Wenn man ein konsistentes Backup möchte, muss man eine Backupsoftware verwenden, die einen Systemsnapshot sichert. Das daraus entstehene Backup kann man dann wunderbar mit rsync auf einen anderen Rechner synchronisieren.*

Ob die DS solche Backupfähigkeiten hat, weiß ich (noch) nicht.



* Das macht allerdings nur Sinn, wenn man immer nur EIN Backup hat. Hat man ein Basis-Backup und fügt lediglih neue inkrementelle Backups hinzu, brint rsync nichts.

 

[itari]

Wenn man ein konsistentes Backup möchte, muss man eine Backupsoftware verwenden, die einen Systemsnapshot sichert.

Oder man muss dafür sorgen, dass die zum Backup anstehenden Dateien nicht durch anderweitige Programm modifiziert werden (also ein 'lock' drauf gesetzt wird). Alternativ, kann man sich zu Beginn des Backups eine Liste über alle zur Sihcerung gehörenden Dateien anfertigen, in der der Zustand (z.B. Änderungsdatum, md5-Hash) festgehalten wird und pro Dateikopie aktuell halten und am Ende der Sicherung noch einmal eine Review machen und die zwischenzeitlich geänderten Dateien nachkopieren. Das kann ein unendliches iterative Verfahren sein, wird aber hinsichtlich des Deltas immer überschaubarer und könnte auch durch einen Grenzwert abbrechen und dann einen Fehler ausgeben, wenn das Delta größer 0 ist. Dann würde man das Gefühl haben, dass das Backup halt nicht ganz erfolgreich wäre und könnte es als ungültig markieren. Solche oder ähnliche Verfahren sind denkbar und werden in der Praxis auch verwendet.

Noch Bemerkungen:
- rsync arbeitet meist differenziell, nicht inkrementell
- Systemsnapshots sind auch nur eine Krücke, denn wenn du eine Snapshot machst, aber Dateitransaktionen aus Anwenderprogrammen noch offen sind und die Transaktionssteuerung nicht auch mitgesichert wird (und das wird sie leider nicht ... auch das Lock-Table wird nicht gesichert), hast oft auch einen Datensalat. Also die einfachste und sicherste Methode ist und bleibt, alle potentiell modifizierenden Programme während der Sicherungszeit auszuschließen/anzuhalten - oder halt die Daten in einer Datenbank vorzuhalten, die sich auf alle diese Spezialitäten kapriziert.

Itari

 

[Macflieger]

Ich habe jetzt die Antwort vom Support bekommen.

Wie ja mittlerweile hier Einigkeit ist, erzeugt das normale Backup inkonsistente Backups, wenn während des Backups die Daten auf der Platte geändert werden.

Es wurde empfohlen TimeBackup zu verwenden, weil das mit Snapshots arbeiten würde und somit das Problem nicht haben würde. TimeBackup kann aber nicht mit verschlüsselten Ordnern oder Platten umgehen und eine Nachfrage bei den Entwicklern seitens des Supports ergab, dass das auch aktuell nicht geplant ist. Sie haben diesen Wunsch aber in eine Liste von Wünschen aufgenommen, die sich die Entwickler anschauen.

Für mich heisst das aktuell:
Wenn ich ein Backup mache, dann klemme ich die Dateifreigabe ab, damit keiner von aussen die Dateien ändert. Ist zwar nicht schön, dürfte aber gehen.
Daher immer noch meine offene Frage: Kann man das An- und Abschalten der Freigaben skripten?

Bezgl der alternierenden Backups habe ich ein paar Tests gemacht und es sieht so aus, als ob das Problem, was in dem zugehörigen Thread diskutiert wurde, nicht mehr besteht. Ich werde das noch weiter testen und dann in dem anderen Thread posten.

 

[itari]

Daher immer noch meine offene Frage: Kann man das An- und Abschalten der Freigaben skripten?

Im Grunde geht es um die Server, die sich der Daten in bestimmten Verzeichnissen bedienen. Wenn du die Server ausschaltest (/usr/syno/etc/rc.d enthält die Skripte hierfür), dann dürfte es weitgehend so laufen, wie du es brauchst.

Itari