Hallo zusammen,
ich habe schonmal gehört, dass man rsync dazu benutzen kann, eine gemountete Festplatte auf einen anderen Rechner (z.B. eine VM) zu kopieren, und dann mit einem zweiten Lauf nach dem Herunterfahren die letzten Änderungen synchronisieren kann.
Hat das von euch schonmal jemand gemacht? Könnt ihr mir die Parameter für rsync dazu nennen?
Ich habe es bereits mit --device , --special, -H , -a versucht und mir die manpage bestimmt schon 10x durchgelesen, komme aber nicht auf die richtige Kombi.
Ich wäre über Hilfe sehr dankbar.
Gruß, Andre
Hallo Andre,
Aus Deinem Beitrag wird die Problemstellung nicht ganz klar: ich benutze i.d.R. rsync -aHEAX --numeric-ids $QUELLE $ZIEL, wenn nun eines der beteiligten FileSysteme kein ACL oder Ähnliches unterstützt, sagt dir rsync das sofort und Du musst dann den entsprechenden Schalte (z.B. "A" für ACL) weglassen. So mache ich Backups, zu denen die restores nachweislich funktionieren. Viel mehr braucht es aus der Schalterflut meiner Meinung nach nicht.
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Hallo Ronny,
On Sat, Jun 11, 2011 at 09:54:54PM +0200, Ronny Seffner wrote:
Aus Deinem Beitrag wird die Problemstellung nicht ganz klar
das konkretisiere ich gerne: ich möchte die Festplatte nicht als Stapel Dateien haben, sondern als binären Blob, so dass ein dd if=/image.hddraw of=/dev/platte reicht, um das komplette System wie es zu dem Zeitpunkt war wieder zu haben.
Der praktische Nutzen für mich wäre, dass ich zur Laufzeit mit rsync die Festplatte auf einen Virtualisierungs-Server kopieren kann, dann nach Beginn der Downtime die letzten veränderten MB kopiere, und die neue VM dann einfach hochfahren kann, mit einer minimalen Downtime.
Wöllte ich das mit dd erreichen, muss ich die Festplatten aushängen um keinen Datenverlust zu bekommen. So dagegen kann das zeitaufwendigste noch Online erfolgen.
Ich hoffe, es ist jetzt etwas klarer geworden.
Danke und Gruß, Andre
das konkretisiere ich gerne: ich möchte die Festplatte nicht als Stapel Dateien haben, sondern als binären Blob, so dass ein dd if=/image.hddraw of=/dev/platte reicht, um das komplette System wie es zu dem Zeitpunkt war wieder zu haben.
Der praktische Nutzen für mich wäre, dass ich zur Laufzeit mit rsync die Festplatte auf einen Virtualisierungs-Server kopieren kann, dann nach Beginn der Downtime die letzten veränderten MB kopiere,
Wenn die Down-Time durch einen Systemabsturz (-> inkonsistentes FS) verursacht wird, dann hilft dir das nicht wirklich weiter, um wieder auf die Füße zu kommen.
Eine "richtige" Lösung für das Problem ist wohl Folgendes: Mittels LVM werden Snapshots angelegt. Diese werden gemountet und via rsync auf einen anderen Server gespiegelt -> konsistentes Backup (bis auf ein paar lock-files). VM-Ware und Co beinhalten derartige Features auch auf Virtualisierungsebene (allerdings funktionierte das vor Jahren bei VM-Ware zumindest in der kostefreien Version nicht zuverlässig).
Eine einfache Lösung sieht so aus: Der Server ist eine kleine VM (mit großem gemountetem Datenshare von sonstwo). Die VM wird regelmäßig runtergefahren, kopiert, wieder gestartet und dann die Kopie synchronisiert. Die Daten vom großen Share können genau wie die Kopie vom Image via rsync synchronisiert werden. Wenn Platz knapp ist, kann rsync auch auf das VM-Image losgelassen werden, während die VM läuft (dann aber nach dem Runterfahren nochmal die letzten Änderungen synchronisieren lassen).
Viele Grüße Fabian
Hallo zusammen,
On Sat, Jun 11, 2011 at 10:36:01PM +0200, Fabian Hänsel wrote:
Wenn die Down-Time durch einen Systemabsturz (-> inkonsistentes FS) verursacht wird, dann hilft dir das nicht wirklich weiter, um wieder auf die Füße zu kommen.
Downtime = nicht nutzbares System, in diesem Fall geplant und geregelt. Ausfallzeit wäre der ungünstige Fall, Downtime ist die schöne Variante ;)
Eine "richtige" Lösung für das Problem ist wohl Folgendes: Mittels LVM werden Snapshots angelegt. Diese werden gemountet und via rsync auf einen anderen Server gespiegelt -> konsistentes Backup (bis auf ein paar lock-files). VM-Ware und Co beinhalten derartige Features auch auf Virtualisierungsebene (allerdings funktionierte das vor Jahren bei VM-Ware zumindest in der kostefreien Version nicht zuverlässig).
In meinem Fall geht es wie gesagt um eine alte Laptop-Platte, kein cooles frisches System von 2011 mit LVM und Snapshots..
[…] kann rsync auch auf das VM-Image losgelassen werden, während die VM läuft (dann aber nach dem Runterfahren nochmal die letzten Änderungen synchronisieren lassen).
Okay, genau das, nur mit echten Platten.. ;)
Mir ist für heute zumindest die Konservierung der alten HDD im bitgenauen Zustand relevant. Notfalls würde ich sogar das Image in einen Archivar mit 50% Fehlerkorrekturdaten einbetten, damit das lange und multibitfehler-geschützt überlebt..
Gruß, Andre
Eine Idee noch:
drbd
Wenn Du mit "ausreichend dimensioniertem" Metadatenbereich arbeitest, könntest Du den Sync nur gelegentlich (also nach Backupplan) fahren. Drbd sitzt direkt auf einem blockdevice, könnte also MBR/GPT mitsichern.
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Am Samstag, 11. Juni 2011, 22:06:39 schrieb Andre Klärner:
Hallo Ronny,
On Sat, Jun 11, 2011 at 09:54:54PM +0200, Ronny Seffner wrote:
Aus Deinem Beitrag wird die Problemstellung nicht ganz klar
das konkretisiere ich gerne: ich möchte die Festplatte nicht als Stapel Dateien haben, sondern als binären Blob, so dass ein dd if=/image.hddraw of=/dev/platte reicht, um das komplette System wie es zu dem Zeitpunkt war wieder zu haben.
Der praktische Nutzen für mich wäre, dass ich zur Laufzeit mit rsync die Festplatte auf einen Virtualisierungs-Server kopieren kann, dann nach Beginn der Downtime die letzten veränderten MB kopiere, und die neue VM dann einfach hochfahren kann, mit einer minimalen Downtime.
Wöllte ich das mit dd erreichen, muss ich die Festplatten aushängen um keinen Datenverlust zu bekommen. So dagegen kann das zeitaufwendigste noch Online erfolgen.
Ich hoffe, es ist jetzt etwas klarer geworden.
Danke und Gruß, Andre
Zum Glück gibt es unter L. viele Wege um das gleiche zu erreichen. dd vs. rsync: denkt an das nötige Volumen. Da Platten "dicker" sind als das Netzwerk ist das ein wichtiger Unterschied.
dd immer alle Bytes rsync erstmalige alle Files, später alle Änderungen
Ich arbeite mit dd nur im Ausnahmefall d.h. Windows Backup, wenn dort kritische Files wie S7 Authorisierungen sind und nachdem ich dort das größtmögliche 0-File angelegt und wieder gelöscht habe:
dd | gz | ssh --with-none <remote> `...`
Bernhard
Hej Andre!
ich habe schonmal gehört, dass man rsync dazu benutzen kann, eine gemountete Festplatte auf einen anderen Rechner (z.B. eine VM) zu kopieren, und dann mit einem zweiten Lauf nach dem Herunterfahren die letzten Änderungen synchronisieren kann.
Willst du das _block_device_ oder das darauf befindliche _Dateisystem_ synchronisieren?
Ersteres: sowas ala "rsync /dev/irgendwas $target" ist nicht vorgesehen. Dass ein reales, physisches System-Image erfolgreich in einer VM bootet ist nicht unmöglich, aber auch nicht sicher. Von daher ist das wohl auch nicht so empfehlenswert (immerhin will man mit einem Backup Sicherheit erlangen).
Zweiteres: siehe Mail von Ronny. (So könnte man auch ein VM-Disk-Image kopieren)
Hat das von euch schonmal jemand gemacht?
Ja, jahrelang, um insg. ca. 100 GB (Dateisystem inkl. mehrerer VM-Images) wöchentlich über eine 1000er-DSL-Leitung zu backupen.
Viele Grüße Fabian
Ersteres: sowas ala "rsync /dev/irgendwas $target" ist nicht vorgesehen. Dass ein reales, physisches System-Image erfolgreich in einer VM bootet ist nicht unmöglich, aber auch nicht sicher. Von daher ist das wohl auch nicht so empfehlenswert (immerhin will man mit einem Backup Sicherheit erlangen).
Es ist das Image eines Gastsystems und wird es auch in Zukunft bleiben. Von daher sollte eine 1:1 Kopie funktionieren.
Aus gegebenem Anlass stelle ich mir die selbe Frage und wüsste auch gerne, ob es nicht ein rsync innerhalb einer Datei gibt. Da werden blockweise die Checksummen verglichen, und wenn sich etwas in einem Block geändert hat, wird dieser übers Netz geschoben. Ohne rsync, viel einfacher. Gibts das?
Thomas
Hej!
Aus gegebenem Anlass stelle ich mir die selbe Frage und wüsste auch gerne, ob es nicht ein rsync innerhalb einer Datei gibt. Da werden blockweise die Checksummen verglichen, und wenn sich etwas in einem Block geändert hat, wird dieser übers Netz geschoben.
Ohne rsync, viel einfacher. Gibts das?
Fast. Es heißt rsync und macht genau das, was du vorschlägst ;-)
(So sind dann auch 20 GB VMs binnen kurzer Zeit via Internet synchronisiert).
Viele Grüße Fabian
On Sat, Jun 11, 2011 at 10:18:18PM +0200, Fabian Hänsel wrote:
Willst du das _block_device_ oder das darauf befindliche _Dateisystem_ synchronisieren?
Zweiteres.
Ersteres: sowas ala "rsync /dev/irgendwas $target" ist nicht vorgesehen. Dass ein reales, physisches System-Image erfolgreich in einer VM bootet ist nicht unmöglich, aber auch nicht sicher. Von daher ist das wohl auch nicht so empfehlenswert (immerhin will man mit einem Backup Sicherheit erlangen).
Im konkreten Fall will ich eine alte Laptop-Platte, die evtl bald defekt ist konservieren. Dazu gehört dann auch eine passend konfigurierte VM, die das Image dann wie es ist auch booten kann.
Zweiteres: siehe Mail von Ronny. (So könnte man auch ein VM-Disk-Image kopieren)
Ja, aber nur wenn es bereits ein Image ist.
Hat das von euch schonmal jemand gemacht?
Ja, jahrelang, um insg. ca. 100 GB (Dateisystem inkl. mehrerer VM-Images) wöchentlich über eine 1000er-DSL-Leitung zu backupen.
Zum reinen Datei-Backup nutze ich es auch schon lange.
Danke für die Antworten bis jetzt.
Gruß, Andre
2011-06-11 22:26, Andre Klärner skrev:
On Sat, Jun 11, 2011 at 10:18:18PM +0200, Fabian Hänsel wrote:
Willst du das _block_device_ oder das darauf befindliche _Dateisystem_ synchronisieren?
Zweiteres.
Dann müsstest du
# rsync -xyz123 / $remotetarget
nutzen. Das sollte auch funktionieren.
Ich meine aber aus deinen Mails eher herauszulesen, dass du so etwas ala
# rsync /dev/sda $remote
haben möchtest (was wie gesagt nicht geht, auch wenn es implementierbar wäre).
Könntest du das evtl. näher erläutern?
Viele Grüße Fabian
On Sat, Jun 11, 2011 at 10:42:32PM +0200, Fabian Hänsel wrote:
2011-06-11 22:26, Andre Klärner skrev:
On Sat, Jun 11, 2011 at 10:18:18PM +0200, Fabian Hänsel wrote:
Willst du das _block_device_ oder das darauf befindliche _Dateisystem_ synchronisieren?
Zweiteres.
Ich meine aber aus deinen Mails eher herauszulesen, dass du so etwas ala # rsync /dev/sda $remote haben möchtest (was wie gesagt nicht geht, auch wenn es implementierbar wäre).
Könntest du das evtl. näher erläutern?
Okay, ich habe wohl außer Acht gelassen, dass es genau drei Möglichkeiten gibt:
1. Den Inhalt des Blockdevices kopieren (also die Festplatte wie es dd tun würde) 2. Das Blockdevice selbst (also den Pointer auf das Kernel-Device "1. Festplatte am SCSI-Bus) 3. Den Inhalt des Dateisystems, also Dateien, Ordner, ACLs, Zugriffsrechte, Links, Inodes...
Mein Ziel ist wie gesagt Variante eins, für die es wohl keine Lösung gibt.
Variante zwei würde ich mit rsync auch jetzt schon hinbekommen (--device), nützt mir aber nichts, da ich dann nur einen Verweis auf die Platte bekomme, der aber leider auf der Zielmaschine null Wert besitzt.
Variante drei ist nuneinmal der Standard-Zweck von rsync, löst aber mein Problem der Bitgenauen Kopie nicht.
Danke für eure Ideen und Vorschläge, aber ich denke mein Problem ist leider (momentan) unlösbarer Natur. Eine bitgenaue Kopie eines Dateisystems mit MBR/GPT und Bootloader über Netzwerk unter Zuhilfenahme eines effizienten inkrementellen Algorithmus wie rsync's existiert wohl im Moment nicht.
Nochmals vielen Dank an Alle.
Gruß und gute Nacht, Andre
...
Danke für eure Ideen und Vorschläge, aber ich denke mein Problem ist leider (momentan) unlösbarer Natur. Eine bitgenaue Kopie eines Dateisystems mit MBR/GPT und Bootloader über Netzwerk unter Zuhilfenahme eines effizienten inkrementellen Algorithmus wie rsync's existiert wohl im Moment nicht.
Nochmals vielen Dank an Alle.
Gruß und gute Nacht, Andre
Versuchs mal mit einer Kombination aus nbd-server / nbd-client und rsync -D (Nie gemacht, IMHO ist das auch ziemlich neu bei rsync.)
Bernhard
Hallo Bernhard,
On Sun, Jun 12, 2011 at 10:24:29AM +0200, Bernhard Schiffner wrote:
Danke für eure Ideen und Vorschläge, aber ich denke mein Problem ist leider (momentan) unlösbarer Natur. Eine bitgenaue Kopie eines Dateisystems mit MBR/GPT und Bootloader über Netzwerk unter Zuhilfenahme eines effizienten inkrementellen Algorithmus wie rsync's existiert wohl im Moment nicht.
Versuchs mal mit einer Kombination aus nbd-server / nbd-client und rsync -D (Nie gemacht, IMHO ist das auch ziemlich neu bei rsync.)
Wie denkst du dir das dann? Einmal pro Kopiervorgang ein ganzes NetworkBlockDevice einrichten? Klingt für mich etwas nach Overkill..
Die Lösung mit ssh ist da noch am einfachsten uns portabelsten, aber frisst natürlich mächtig Verschlüsselungs-Zeit.
Danke und Gruß, Andre
Am Sonntag, 12. Juni 2011, 11:58:08 schrieb Andre Klärner:
Hallo Bernhard,
On Sun, Jun 12, 2011 at 10:24:29AM +0200, Bernhard Schiffner wrote:
Danke für eure Ideen und Vorschläge, aber ich denke mein Problem ist leider (momentan) unlösbarer Natur. Eine bitgenaue Kopie eines Dateisystems mit MBR/GPT und Bootloader über Netzwerk unter Zuhilfenahme eines effizienten inkrementellen Algorithmus wie rsync's existiert wohl im Moment nicht.
Versuchs mal mit einer Kombination aus nbd-server / nbd-client und rsync -D (Nie gemacht, IMHO ist das auch ziemlich neu bei rsync.)
Wie denkst du dir das dann? Einmal pro Kopiervorgang ein ganzes NetworkBlockDevice einrichten? Klingt für mich etwas nach Overkill..
rsync oder andere, ähnliche Programme müssen etwas lesen können, um Vergleiche und daraus Optimierungen machen zu können.
Was ist so schwer? 1. Seite "A": nbd-server 7777 /dev/sda 2. Seite "B": ndb-client "A" 777 /dev/nbd0 3. Seite "B": "rsync -D" /dev/nbd0 /dev/with-local-dd'ed-copy
ABER: Obwohl verschiedene Patches für rsync diesbezüglich existieren, scheint es für größere Volumina nicht effektiv zu sein. Vorschläge gehen für 3.) auf ein paar Perl "Einzeiler" hinaus.
google "about rsyncing of block devices" (Stephane Chazelas)
Die Lösung mit ssh ist da noch am einfachsten uns portabelsten, aber frisst natürlich mächtig Verschlüsselungs-Zeit.
ssh -c NONE (In der anderen Mail hatte ich die Compile-Option dafür --with-none angegeben, da NONE zum Glück kein Standard ist.)
Aber wie oben: die Leserichtung geht nicht so ohne weiteres.
Danke und Gruß, Andre
Bernhard
Hi Andre,
gedacht habe ich wohl gar nicht - zumindest nicht zu Ende. Zuallererst müsstest Du mal drbd auf dem betroffenen Notebook zwischen device und Partitionen bekommen. Dann kannst Du auf dem VM-Host ja eine Containerdatei als für drbd zu verwendendes "blockdevice" anlegen, welches dann bei Bedarf dem VM-Gast als Platte untergejubelt wird. Drbd ist in der Lage Änderungen in ein bitmap zu schreiben (m.E. adressen geänderter Blöcke). Wenn Du nun nicht viel harddisk-IO mit dem Notebook machst und/oder regelmäßig die drbd Verbindung zum VM-Host herstellst wird nicht jedes Mal das gesamte blockdevice synchronisiert, sondern nur die im bitmap vermerkten Blöcke. Das ist unterm Strich sicher mehr als rsync, aber weniger als the whole disk.
War nur als Nachdenkanregung gedacht, nicht fertig auf Realisierbarkeit durchdacht. Ich habe hier mal angefragt, wie ich für ein Backupziel mittels Softraid, wo ein Teil fest im Server steckt und ich eine Kopie gern wöchentlich rotiere ohne den regelmäßigen Vollsync des md auskomme, da wurde im Ergebnis Ähnliches entwickelt : drbd. Ich konnte es bis heute allerdings noch nicht umsetzen.
Mit freundlichen Grüßen / With kind regards Ronny Seffner
Hallo Ronny,
On Sun, Jun 12, 2011 at 01:06:39PM +0200, Ronny Seffner wrote:
gedacht habe ich wohl gar nicht - zumindest nicht zu Ende. Zuallererst müsstest Du mal drbd auf dem betroffenen Notebook zwischen device und Partitionen bekommen. Dann kannst Du auf dem VM-Host ja eine Containerdatei
genau da liegt das Problem: ich möchte einen fixen Zustand einer Maschine bequem über Netzwerk blockweise transferiren, und dieses Image dann bis in tausend Jahre aufheben.
Dagegen will ich nicht eine periodische Synchronisation eines Notebooks mit einem heimischen Image habe. Für diesen Zweck reichen mir etwas Netzwerkspeicher und rsnapshot-Sicherungen.
Ich will einfach die in ein paar Wochen vielleicht defekte Notebook-Platte einfrosten, sodass die Daten darauf wiederbeschaffbar sind, aber ich nicht die Hardware-Platte aufheben und verhätscheln muss.
Gruß, Andre
Andre Klärner kandre@ak-online.be (Sun Jun 12 13:21:39 2011):
Hallo Ronny,
On Sun, Jun 12, 2011 at 01:06:39PM +0200, Ronny Seffner wrote:
gedacht habe ich wohl gar nicht - zumindest nicht zu Ende. Zuallererst müsstest Du mal drbd auf dem betroffenen Notebook zwischen device und Partitionen bekommen. Dann kannst Du auf dem VM-Host ja eine Containerdatei
genau da liegt das Problem: ich möchte einen fixen Zustand einer Maschine bequem über Netzwerk blockweise transferiren, und dieses Image dann bis in tausend Jahre aufheben.
Das kannst Du mit SCP. Ich hatte verstanden, daß Du aber dann noch mal dieses Image syncronisieren wolltest, weil sich das Original inzwischen schon verändert haben kann.
Vielleicht hilft Dir das hier weiter: http://lists.samba.org/archive/rsync/2010-June/025164.html
Und dann könnte ich mir vorstellen, daß so ein - nennen wir es bsync - auch schreibbar sein müsste mit relativ unspektakulärem Aufwand…
Oder wir brauchen das Gegenstück vom loop-Treiber - ein Blockdevice auf eine normale Datei mappen :)
Hallo Heiko,
On Tue, Jun 14, 2011 at 03:02:56PM +0200, Heiko Schlittermann wrote:
Das kannst Du mit SCP. Ich hatte verstanden, daß Du aber dann noch mal dieses Image syncronisieren wolltest, weil sich das Original inzwischen schon verändert haben kann.
Ja, das wollte ich. Aber der aktuelle Anlass lässt sich auch mit einem einmaligen Transfer bewerkstelligen.
Vielleicht hilft Dir das hier weiter: http://lists.samba.org/archive/rsync/2010-June/025164.html
Und dann könnte ich mir vorstellen, daß so ein - nennen wir es bsync - auch schreibbar sein müsste mit relativ unspektakulärem Aufwand…
Ja, diese Zusammenfassung ist echt cool.. Wo hast du die hervorgezaubert?
Das mit dem Perl-One-Linern über ssh werd ich demnächst mal ausprobieren.
Oder wir brauchen das Gegenstück vom loop-Treiber - ein Blockdevice auf eine normale Datei mappen :)
Ja, das wäre wahrscheinlich noch cooler.. Wer hat Lust das zu coden? Ich biete ein großes Bier! ;)
Danke und Gruß,
Andre
PS: Entschuldigt bitte die Verzögerung - System neuaufsetzen kann tückisch sein, wenn man exim vergisst.. Shame on me..
Nabend
Haste dir schon mal VMWare Converter angeschaut? seit der neusten Version arbeitet dieser auch Hotclonig (ging früher nur Coldcloning)
Als Ergebnis haste einen VM die ein Clone deiner realen Maschine ist
Andreas
lug-dd@mailman.schlittermann.de
-
Andre Klärner -
Bernhard Schiffner -
Fabian Hänsel -
Grimnin Fridyson -
Heiko Schlittermann -
Ronny Seffner -
Thomas Schmidt