Spiegelung einer Festplatte mit Hilfe von rsync
Hallo Leute, ich habe hier ein System mit Suse 10.2 auf dem unter VMWare einige Server laufen (sollen). Nun möchte ich gerne die verwendete Festplatte jeweils nachts automatisiert per Scripting auf eine zweite Platte im lokalen System spiegeln. Nun sind aber zugegebenerweise sowohl Scripting als auch Datensicherung unter Linux für mich jeweils Bücher mit sieben Siegeln. Im Buch "Datensicherung unter Linux" habe ich ein sehr einfaches Script gefunden das angepasst auszugsweise so aussieht: ---------------- #!/bin/bash FLAGGS="--archive --one-file-system --delete" rsync $FLAGS /. /BACKUP/rootdir/. u.s.w. --------------- Ich würde auf der zweiten Platte eine Partitionsstruktur anlegen die der der ersten Platte entspricht und die Partitonen in der fstab jeweils unter /BACKUP/Verzeichnisname mounten. Allerdings bin ich mir ziemlich sicher dass ich mir insbesondere massive Probleme durch inkonsitente Daten einhandeln kann wenn ich die VMWare-Maschinen im laufenden Betrieb sichere. Reicht es aus vor die rsync-Befehle einfach ein "/etc/init.d/vmware stop" und danach ein "/init.d/vmware start" zu setzen? Für sachdienliche Hinweise wäre ich dankbar. Ziel ist es, im Falle eines Festplattendefektes einfach die Platten zu tauschen, Grub neu einzurichten und mit der alten Reserveplatte weiterzuarbeiten. Später sollen zusätzlich insbesondere die VMWare-Maschinen automatisiert weiter auf ein anderes System in einem anderen Raum gesichert werden. An eine Archivierung älterer Daten ist nicht gedacht. Es geht nur darum auch im Falle eines größeren Hardware-Schadens der auch die zweite Platte mit einschließen würde die virtuellen Maschienen wieder herstellen zu können. Leider steht zur Zeit nur eine Buffalo Terrastation Pro II zur Verfügung die per SMB oder FTP erreichbar ist. Rsync fällt deshalb meiner Meinung nach weg. Auch hier wäre ich für Vorschläge dankbar. Das ganze spielt sich in einem Schulnetz ab. Es würde deshalb beim Verlust der Daten primär kein finanzieller Schaden entstehen, ein Datenverlust würde "nur" viel Ärger und noch mehr Arbeit bedeuten. Grüße Ulrich -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Ulrich Mindrup, Samstag, 10. November 2007 11:36:
Ich würde auf der zweiten Platte eine Partitionsstruktur anlegen die der der ersten Platte entspricht und die Partitonen in der fstab jeweils unter /BACKUP/Verzeichnisname mounten. Allerdings bin ich mir ziemlich sicher dass ich mir insbesondere massive Probleme durch inkonsitente Daten einhandeln kann wenn ich die VMWare-Maschinen im laufenden Betrieb sichere. Reicht es aus vor die rsync-Befehle einfach ein "/etc/init.d/vmware stop" und danach ein "/init.d/vmware start" zu setzen?
Das mindeste, was Du Dir damit einhandelst, sind abstürzende Server im vmware, und natürlich inkonsistente Dateien überhaupt.
Ziel ist es, im Falle eines Festplattendefektes einfach die Platten zu tauschen, Grub neu einzurichten und mit der alten Reserveplatte weiterzuarbeiten.
Das läuft so: Du trabst in einen Laden, kaufst Dir nen vernünftigen RAID-Kontroller, und damit ist der Käse gebissen. Mach ein RAID 1, je nach Ansprüchen an die Performance, und schon darf Dir eine Platte abschmieren, die Du dann im laufenden Betrieb wechseln kannst. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Andre Tann schrieb:
Ulrich Mindrup, Samstag, 10. November 2007 11:36:
Ich würde auf der zweiten Platte eine Partitionsstruktur anlegen die der der ersten Platte entspricht und die Partitonen in der fstab jeweils unter /BACKUP/Verzeichnisname mounten. Allerdings bin ich mir ziemlich sicher dass ich mir insbesondere massive Probleme durch inkonsitente Daten einhandeln kann wenn ich die VMWare-Maschinen im laufenden Betrieb sichere. Reicht es aus vor die rsync-Befehle einfach ein "/etc/init.d/vmware stop" und danach ein "/init.d/vmware start" zu setzen?
Das mindeste, was Du Dir damit einhandelst, sind abstürzende Server im vmware, und natürlich inkonsistente Dateien überhaupt.
Könntest Du das bitte genauer erklären? Ich war eigentlich davon ausgegangen dass die Init-Schripts von VMWare so ausgereift seien dass die virtuellen Maschinen je nach Einstellung "eingefroren" oder heruntergefahren werden und nicht einfach abstürzen wenn man "/etc/init.d/vmware stop" eingibt.
Ziel ist es, im Falle eines Festplattendefektes einfach die Platten zu tauschen, Grub neu einzurichten und mit der alten Reserveplatte weiterzuarbeiten.
Das läuft so: Du trabst in einen Laden, kaufst Dir nen vernünftigen RAID-Kontroller, und damit ist der Käse gebissen. Mach ein RAID 1, je nach Ansprüchen an die Performance, und schon darf Dir eine Platte abschmieren, die Du dann im laufenden Betrieb wechseln kannst.
Ich bin Lehrer an einer berufsbildenden Schule. Die Betreuung des Rechnernetzes ist weitgehend mein "Privatvergnügen" das nur in geringem Umfang durch Ermäßigungsstunden abgefedert wird. Wenn das mein "Privatrechner" wäre dann könnte ich sicherlich in einen Laden gehen und mir einen RAID-Controller kaufen. Aber auch wenn ich ein gutes RAID-System hätte dann müsste ich trotzdem vorher die entsprechenden Maschinen herunterfahren bevor ich sie über das Netz auf das das ziemlich langsame NAS überspiele. Und das dafür notwendige Zeitfenster dürfte deutlich größer sein als bei Kopien von Platte zu Platte bei denen zudem nur die Änderungen im Dateisystem übertragen werden. Grüße Ulrich -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo Ulrich, Am Samstag, 10. November 2007 11:36:29 schrieb Ulrich Mindrup:
Hallo Leute,
ich habe hier ein System mit Suse 10.2 auf dem unter VMWare einige Server laufen (sollen). Nun möchte ich gerne die verwendete Festplatte jeweils nachts automatisiert per Scripting auf eine zweite Platte im lokalen System spiegeln. Nun sind aber zugegebenerweise sowohl Scripting als auch Datensicherung unter Linux für mich jeweils Bücher mit sieben Siegeln. [...]
Je nachdem auf welcher Hardware das Hostsystem läuft und welche OS in den VMs laufen sollen würde ich Dir einen Blick auf Xen empfehlen. Läuft in der 10.3 sogar "out-of-the-Box". Xen ist um einiges Ressourcenschonender als VMware. Das mal grundsätzlich vorab. Und mit entsprechender Hardwareausstattung (CPU mit Virtualisierungsunterstützung) laufen da sogar die Redmonder Systeme drauf, ohne entsprechende CPU bist Du allerdings auf Linuxsysteme beschränkt. Ob jetzt Xen oder VMware - beide Virtualisierungslösungen bieten aber AFAIK ein einfrieren der VMs während des Backups an. Dann kam hier der Tip, ein Raid1 als Backup zu nehmen. Raid ist kein Backup! Du könntest die Partition(en) mit den VM-Images aber in ein LVM legen, das erleichtert das Backup. Das eigentliche Backup kannst Du dann mit den Mitteln Deiner Wahl (rsync, tar, dar, cpio, etc. pp.) machen. Ausserdem würde ich die VMs auf eine zweite Platte getrennt vom Hostsystem auslagern. Schau Dir mal diese [1] Seite an und melde Dich noch mal, wenn da Fragen offen bleiben...
Grüße
Ulrich
Gruss Mario [1] http://blog.mellenthin.de/archives/2007/07/14/niemand-will-backup-alle-wolle... -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Mario van der Linde schrieb:
Je nachdem auf welcher Hardware das Hostsystem läuft und welche OS in den VMs laufen sollen würde ich Dir einen Blick auf Xen empfehlen. Läuft in der 10.3 sogar "out-of-the-Box".
Hallo Mario, ich habe zwar mitbekommen dass Xen sich deutlich weiterentwickelt hat, allerdings habe ich mich noch nicht näher damit beschäftigt.
Xen ist um einiges Ressourcenschonender als VMware. Das mal grundsätzlich vorab. Und mit entsprechender Hardwareausstattung (CPU mit Virtualisierungsunterstützung) laufen da sogar die Redmonder Systeme drauf, ohne entsprechende CPU bist Du allerdings auf Linuxsysteme beschränkt. Ob jetzt Xen oder VMware - beide Virtualisierungslösungen bieten aber AFAIK ein einfrieren der VMs während des Backups an.
Da das System mittlerweile läuft möchte ich jetzt ungerne von VMWare zu Xen wechseln, zudem fehlt mir im Augenblick einfach die Zeit um mich intensiv einzuarbeiten. Was das "Einfrieren" der Virtuellen Maschinen angeht so hatte ich vermutet dass dies problemlos funktionieren sollte wenn man den Dienst stoppt falls die entsprechende Option gewählt ist. Aber für weitergehende Informationen wäre ich natürlich dankbar.
Dann kam hier der Tip, ein Raid1 als Backup zu nehmen. Raid ist kein Backup!
Das ist mir durchaus klar ;-) Auch die Lösung die mir vorschwebt ist zunächst einmal kein ideales Backup. Das Backupmedium befindet sich im gleichen System, zudem besteht immer die Gefahr dass es gerade dann zu einem größeren Fehler kommt wenn die Daten von der ersten auf die zweite Platte geschrieben werden. Meine Überlegung war dass ich dann gezielt weitersichern könnte ohne dass das eigentliche System beeinflusst wird. Zudem könnte ich dann in unterschiedlichen Intervallen sichern. Reine Anwendungsdaten und den Systemstatus sichere ich zudem aus der virtuellen Maschine heraus, bei Windows-Systemen mit NTBackup.
Du könntest die Partition(en) mit den VM-Images aber in ein LVM legen, das erleichtert das Backup. Das eigentliche Backup kannst Du dann mit den Mitteln Deiner Wahl (rsync, tar, dar, cpio, etc. pp.) machen. Ausserdem würde ich die VMs auf eine zweite Platte getrennt vom Hostsystem auslagern.
Mit LVMs habe ich mich bisher noch nicht befasst, zudem habe ich im Augenblick nur zwei Festplatten. Als Schule sind unsere finanziellen Mittel berschränkt, zudem kann man nicht einfach so in den nächsten Laden gehen und Hardware kaufen.
Schau Dir mal diese [1] Seite an und melde Dich noch mal, wenn da Fragen offen bleiben...
Das werde ich machen. Im Augenblick schlage ich mich allerdings mit einem leichten Infekt herum und erledige deshalb nur die wirklich notwendigen Dinge. Grüße Ulrich P.S.: Und das ganze nochmal in die Liste. Irgendwann werde ich es noch lernen vor Betätigung des Absendebuttons den Empfänger umzustellen ;-) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, 13.11.2007 13:01,, Ulrich Mindrup wrote::
Mario van der Linde schrieb: ... Da das System mittlerweile läuft möchte ich jetzt ungerne von VMWare zu Xen wechseln, zudem fehlt mir im Augenblick einfach die Zeit um mich intensiv einzuarbeiten. Was das "Einfrieren" der Virtuellen Maschinen angeht so hatte ich vermutet dass dies problemlos funktionieren sollte wenn man den Dienst stoppt falls die entsprechende Option gewählt ist. Aber für weitergehende Informationen wäre ich natürlich dankbar.
Könntest du ja einfach ausprobieren. Ich weiss es momentan nämlich auch nicht :-)
Dann kam hier der Tip, ein Raid1 als Backup zu nehmen. Raid ist kein Backup!
Das ist mir durchaus klar ;-)
Sehr gut!
Auch die Lösung die mir vorschwebt ist zunächst einmal kein ideales Backup. Das Backupmedium befindet sich im gleichen System, zudem besteht immer die Gefahr dass es gerade dann zu einem größeren Fehler kommt wenn die Daten von der ersten auf die zweite Platte geschrieben werden. Meine Überlegung war dass ich dann gezielt weitersichern könnte ohne dass das eigentliche System beeinflusst wird.
So gesehen ein sinnvoller Ansatz. Mit LVM wird das allerdings schneller und platzsparender gehen. Snapshot ist das Schlüsselwort: Du hältst die VMs an, machst einen Snapshot, und startest alles wieder. Der Snapshot behält dann den Zusatand bei seiner Erzeugung, du kannst dir beim Sichern also Zeit lassen. Nach vollbrachter Sicherung wird der Snapshot wieder entfernt.
Zudem könnte ich dann in unterschiedlichen Intervallen sichern. Reine Anwendungsdaten und den Systemstatus sichere ich zudem aus der virtuellen Maschine heraus, bei Windows-Systemen mit NTBackup.
VMs sichern ist immer etwas problematisch, allerdings ist meine Erfahrung dass man mit der Sicherung aus dem System heraus zu brauchbaren Ergebnissen kommt. Allerdings auf Kosten höherer Leistungsverluste.
Du könntest die Partition(en) mit den VM-Images aber in ein LVM legen, das erleichtert das Backup. Das eigentliche Backup kannst Du dann mit den Mitteln Deiner Wahl (rsync, tar, dar, cpio, etc. pp.)
Hier fehlt noch Bacula :-)
machen.
Ausserdem würde ich die VMs auf eine zweite Platte getrennt vom Hostsystem auslagern.
Ja, würde ich auch tun. Mit VMware sollte das relativ simpel sein.
Mit LVMs habe ich mich bisher noch nicht befasst,
Dann ist jetzt der richtige Zeitpunkt!
zudem habe ich im Augenblick nur zwei Festplatten.
Das reicht erstmal.
Als Schule sind unsere finanziellen Mittel berschränkt, zudem kann man nicht einfach so in den nächsten Laden gehen und Hardware kaufen.
Stimmt wohl. Aber mit etwas Planung ist da was zu machen, denke ich.
Schau Dir mal diese [1] Seite an und melde Dich noch mal, wenn da Fragen offen bleiben...
Das werde ich machen. Im Augenblick schlage ich mich allerdings mit einem leichten Infekt herum und erledige deshalb nur die wirklich notwendigen Dinge.
Na dann erstmal gute Besserung! Arno
Grüße
Ulrich
P.S.: Und das ganze nochmal in die Liste. Irgendwann werde ich es noch lernen vor Betätigung des Absendebuttons den Empfänger umzustellen ;-)
-- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Ulrich, On Tuesday 13 November 2007, Ulrich Mindrup wrote:
Was das "Einfrieren" der Virtuellen Maschinen angeht so hatte ich vermutet dass dies problemlos funktionieren sollte wenn man den Dienst stoppt falls die entsprechende Option gewählt ist. Aber für weitergehende Informationen wäre ich natürlich dankbar.
vielleicht kannst Du zum sauberen Schliessen der VMs vmware-cmd (soweit ich weiss, nur bei VMWare Server dabei) benutzen. Ich zitiere aus einer frueheren Mail von Jenx Nixdorf auf dieser Liste:
vmware-cmd "/pfad/zur/vmx-Datei" suspend
Damit wird die VM in suspend geschickt, und es gibt bei Erfolg ein "suspend()=1" auf dem Standard-Input zurück. Danach kannst Du getrost alles abschiessen.
Viele Gruesse, Kurt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
curdy@congster.de schrieb:
vielleicht kannst Du zum sauberen Schliessen der VMs vmware-cmd (soweit ich weiss, nur bei VMWare Server dabei) benutzen. Ich zitiere aus einer frueheren Mail von Jenx Nixdorf auf dieser Liste:
vmware-cmd "/pfad/zur/vmx-Datei" suspend
Damit wird die VM in suspend geschickt, und es gibt bei Erfolg ein "suspend()=1" auf dem Standard-Input zurück. Danach kannst Du getrost alles abschiessen.
Auch an Dich vielen Dank, ich schaue mir das mal am Wochenende genauer an und probiere es dann Montag aus. Grüße Ulrich -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Mario van der Linde, Sonntag, 11. November 2007 16:17:
Dann kam hier der Tip, ein Raid1 als Backup zu nehmen. Raid ist kein Backup!
Falls Du mich meinst - das habe ich nicht vorgeschlagen. Dem OP ging es darum, nach einem Plattendefekt möglichst schnell weiterarbeiten zu können, jedenfalls habe ich das so verstanden. Er schrieb nämlich:
Ziel ist es, im Falle eines Festplattendefektes einfach die Platten zu tauschen, Grub neu einzurichten und mit der alten Reserveplatte weiterzuarbeiten.
und
An eine Archivierung älterer Daten ist nicht gedacht
Das sprach in meinen Augen viel mehr für RAID, als für irgendwelche Backup-Lösungen. Aber egal, RAID, Backup - man braucht eh beides. -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Ulrich Mindrup schrieb:
Hallo Leute,
ich habe hier ein System mit Suse 10.2 auf dem unter VMWare einige Server laufen (sollen). Nun möchte ich gerne die verwendete Festplatte jeweils nachts automatisiert per Scripting auf eine zweite Platte im lokalen System spiegeln. Nun sind aber zugegebenerweise sowohl Scripting als auch Datensicherung unter Linux für mich jeweils Bücher mit sieben Siegeln.
Im Buch "Datensicherung unter Linux" habe ich ein sehr einfaches Script gefunden das angepasst auszugsweise so aussieht: ---------------- #!/bin/bash
FLAGGS="--archive --one-file-system --delete"
rsync $FLAGS /. /BACKUP/rootdir/. u.s.w. --------------- warum so umständlich, denk mal 'dd' ist Dein Freund ;)
dd if=/dev/hda of=/dev/sda bs=16065b wobei /dev/hda dein Quelllaufwerk ist und /dev/sda das Ziel (z.B. USB Platte, im Idealfall Baugleich). Damit hast Du eine 1:1 Spiegelung inkl. MBR && Partitiontable. Die VM Guest's wuerd ich vorher in den Suspend schicken (vmware-cmd <cfg> suspend) jo das sollte problemlos funzen, achja die Zielplatte sollte gleich gross oder grösser sein und wie gesagt am Besten das selbe Modell. gruss Max
Ich würde auf der zweiten Platte eine Partitionsstruktur anlegen die der der ersten Platte entspricht und die Partitonen in der fstab jeweils unter /BACKUP/Verzeichnisname mounten. Allerdings bin ich mir ziemlich sicher dass ich mir insbesondere massive Probleme durch inkonsitente Daten einhandeln kann wenn ich die VMWare-Maschinen im laufenden Betrieb sichere. Reicht es aus vor die rsync-Befehle einfach ein "/etc/init.d/vmware stop" und danach ein "/init.d/vmware start" zu setzen? Für sachdienliche Hinweise wäre ich dankbar. Ziel ist es, im Falle eines Festplattendefektes einfach die Platten zu tauschen, Grub neu einzurichten und mit der alten Reserveplatte weiterzuarbeiten.
Später sollen zusätzlich insbesondere die VMWare-Maschinen automatisiert weiter auf ein anderes System in einem anderen Raum gesichert werden. An eine Archivierung älterer Daten ist nicht gedacht. Es geht nur darum auch im Falle eines größeren Hardware-Schadens der auch die zweite Platte mit einschließen würde die virtuellen Maschienen wieder herstellen zu können. Leider steht zur Zeit nur eine Buffalo Terrastation Pro II zur Verfügung die per SMB oder FTP erreichbar ist. Rsync fällt deshalb meiner Meinung nach weg. Auch hier wäre ich für Vorschläge dankbar.
Das ganze spielt sich in einem Schulnetz ab. Es würde deshalb beim Verlust der Daten primär kein finanzieller Schaden entstehen, ein Datenverlust würde "nur" viel Ärger und noch mehr Arbeit bedeuten.
Grüße
Ulrich
Markus Heinze schrieb:
Ulrich Mindrup schrieb:
Hallo Leute,
ich habe hier ein System mit Suse 10.2 auf dem unter VMWare einige Server laufen (sollen). Nun möchte ich gerne die verwendete Festplatte jeweils nachts automatisiert per Scripting auf eine zweite Platte im lokalen System spiegeln. Nun sind aber zugegebenerweise sowohl Scripting als auch Datensicherung unter Linux für mich jeweils Bücher mit sieben Siegeln.
Im Buch "Datensicherung unter Linux" habe ich ein sehr einfaches Script gefunden das angepasst auszugsweise so aussieht: ---------------- #!/bin/bash
FLAGGS="--archive --one-file-system --delete"
rsync $FLAGS /. /BACKUP/rootdir/. u.s.w. --------------- warum so umständlich, denk mal 'dd' ist Dein Freund ;)
dd if=/dev/hda of=/dev/sda bs=16065b
Danke für den Hinweis. Für die erste Kopie hatte ich auch schon daran gedacht um das Partitionieren, Anlegen der Dateisysteme, etc. zu sparen.. Allerdings hat rsync ja den Vorteil dass später nur die Änderungen synchronisiert werden müssen. In dem System sind imho Platten mit 160GB eingebaut, das dürfte dd etwas länger dauern. Aber ich denke es sollte doch nichts dagegen sprechen zunächst einmal per dd und dann per rsync zu kopieren?
wobei /dev/hda dein Quelllaufwerk ist und /dev/sda das Ziel (z.B. USB Platte, im Idealfall Baugleich). Damit hast Du eine 1:1 Spiegelung inkl. MBR && Partitiontable.
Die Platten sind baugleich, beides SATA. Auf hda liegen die Daten, hdb ist noch frei und soll die Kopie aufnehmen.
Die VM Guest's wuerd ich vorher in den Suspend schicken (vmware-cmd <cfg> suspend)
Ok, dass müsste ich mir noch genauer anschauen. Danke für die Hinweise. Mittelfristig werde ich mich auf jeden Fall mit LVMs näher beschäftigen, die von Mario verlinkte Seite sieht auf jeden Fall sehr interessant aus. Aber zumindest kurzfristig hast Du mich weitergebracht. Grüße Ulrich P.S.: Hat eigentlich die "krumme" Blockgröße irgend eine besondere Bedeutung? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, Am Fre, 16 Nov 2007, Ulrich Mindrup schrieb:
Markus Heinze schrieb: [..]
warum so umständlich, denk mal 'dd' ist Dein Freund ;)
dd if=/dev/hda of=/dev/sda bs=16065b
Danke für den Hinweis. Für die erste Kopie hatte ich auch schon daran gedacht um das Partitionieren, Anlegen der Dateisysteme, etc. zu sparen.. Allerdings hat rsync ja den Vorteil dass später nur die Änderungen synchronisiert werden müssen. In dem System sind imho Platten mit 160GB eingebaut, das dürfte dd etwas länger dauern. Aber ich denke es sollte doch nichts dagegen sprechen zunächst einmal per dd und dann per rsync zu kopieren?
Sinnvoller ist IMO die Zielplatte zu partitionieren und dann mit tar/rsync die Daten zu kopieren (-> siehe FAQ).
P.S.: Hat eigentlich die "krumme" Blockgröße irgend eine besondere Bedeutung?
Halte ich auch für seltsam. Sinnvoll ist eine Blockgröße die zur logischen Plattengeometrie passt, speziell in der Variante, daß man eine Blockgröße = Zylindergröße verwendet. Kopfzahl * Sektorenzahl * Sektorgröße = Zylindergröße 255 63 512 = 8225280 Bei passender (geraden) Zylinderzahl kann man noch verdoppeln usw. HTH, -dnh -- Dinner not ready...(A)bort (R)etry (P)izza -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
David Haller schrieb:
Hallo,
Am Fre, 16 Nov 2007, Ulrich Mindrup schrieb:
Markus Heinze schrieb:
[..]
Sinnvoller ist IMO die Zielplatte zu partitionieren und dann mit tar/rsync die Daten zu kopieren (-> siehe FAQ).
Du meinst diese FAQ: http://suse-linux-faq.koehntopp.de/ch/ch-backup.html? Was genau spricht dagegen beim ersten Mal dd einzusetzen? Das einzige was mir einfallen würde wäre eine zweite Platte die obwohl anscheinend baugleich um einige Sektoren kleiner wäre. Aber das sollte man eigentlich der Fehlermeldung am Ende des Kopiervorgangs entnehmen können.
P.S.: Hat eigentlich die "krumme" Blockgröße irgend eine besondere Bedeutung?
Halte ich auch für seltsam. Sinnvoll ist eine Blockgröße die zur logischen Plattengeometrie passt, speziell in der Variante, daß man eine Blockgröße = Zylindergröße verwendet.
Kopfzahl * Sektorenzahl * Sektorgröße = Zylindergröße 255 63 512 = 8225280
Bei passender (geraden) Zylinderzahl kann man noch verdoppeln usw.
Ist es wirklich noch sinnvoll sich an der Zylindergröße als Maß zu verwenden? Der tatsächliche Wert ändert sich doch schon seit einer zweistelligen Zahl von Jahren stufenweise von außen nach innen, adressiert werden die Sektoren per LBA. Ich hätte gedacht es sei sinnvoller sich beispielsweise am Cache der Festplatte zu orientieren. Grüße Ulrich -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (7)
-
Andre Tann -
Arno Lehmann -
curdy＠congster.de -
David Haller -
Mario van der Linde -
Markus Heinze -
Ulrich Mindrup