Backup

LeoLinux

Well-Known Member
Ich habe mit dd ein 150 GB großes File erstellt, dass ich nun mit einem ext3 Filesystem bespielt habe worauf ein lauffähiges Linux Szstem für Xen ist.
Von diesen 150 GB sind 15 GB in Verwendung.

Nun habe ich ein zweites File mit dd erstellt, welches nun nurmehr 20 GB groß ist.
Dieses 20 GB file habe ich ebenfalls mit einem ext2 Filesystem bespielt.

Ziel ist es nun beide virtuellen Platten zu mounten und die Dateien der großen Platte auf die kleine zu überspielen. Hierbei meine ich ALLE Dateien, so dass ich später dem Xen nur noch die neue, kleinere Platte überreichen kann und dann wieder ein lauffähiges System habe.


Zuerst habe ich an cp mit Rechten und keinen Systemlinks folgen gedacht. Doch das geht nur solange gut bis cp an /dev angelangt und dann wars das ... ;(

mv ist da nicht besser ... zuletzt bleibt irgendetwas von /var übrig

Also habe ich an tar gedacht ....

Code:
cd /mnt/oldFS; tar cf -  . | (cd /mnt/newFS; tar xpf - )
tar: Read fault on ./var/cache/apt/srcpkgcache.bin (Input/output error)
tar: Read fault on ./var/lib/mysql/ibdata1 (Input/output error)
tar: Read fault on ./var/lib/mysql/ib_logfile0 (Input/output error)
tar: Read fault on ./var/lib/mysql/ib_logfile1 (Input/output error)
tar: Read fault on ./var/lib/mysql/db_ispconfig/isp_server.frm (Input/output error)
... [usw.] ...

^^ Dem zufolge wären ja aber irgendwelche Files nicht in ordnung - stimmt aber nicht! Habe das gründlichst gecheckt - die Files die er mir da als input/output error bringt sind in Ordnung.


Nagut, also habe ich weiter gegoogled ... und bin hierbei auf folgendes gestoßen ...:
Code:
cd /mnt/oldFS; dump 0f - . | (cd /mnt/newFS; restore -rf - )
  DUMP: Dumping sub files/directories from /mnt/oldFS
  DUMP: Dumping file/directory .
  DUMP: Cannot open /dev/vnd0a
Checksum error 0, inode 0 file <name unknown>
Tape is not a dump tape
^^ dump habe ich leider nur für mein root Verzeichnis zum laufen bekommen ... ;( nicht aber für die Ordner in denen meine beiden virtuellen Platten gemounted sind ... denn ich möchte ja nur den Inhalt kopieren.


und weiter gegoogled ....
Code:
( cd /mnt/oldFS; find . -print0 ) | pax -0 -w | ( cd /mnt/newFS; pax -0 -r )
pax: Read fault on ./var/cache/apt/srcpkgcache.bin (Input/output error)
pax: Ustar cannot archive a socket ./var/spool/postfix/private/tlsmgr
... [usw.] ...


Was läuft hier schief??
 
Ok, es schienen wohl doch korrupte Dateien geweßen zu sein.
Jedoch habe ich nun mit tar noch immer das Problem, dass er mir Sockets ignoriert .. ;(

Code:
FileServer ~ #  cd /mnt/oldFS; tar cf -  . | (cd /mnt/newFS; tar xpf - )
tar: ./var/run/proftpd/proftpd.sock: Socket ignoriert
tar: ./var/run/courier/authdaemon/socket: Socket ignoriert
tar: ./var/spool/postfix/public/cleanup: Socket ignoriert

weshalb kann das nicht mitkopiert werden? Oder besser gefragt: Wie kopiere auch das mit ?

Danke
 
Sollten diese Sockets beim nächsten Systemstart nicht wieder automatisch angelegt werden? Kann ich das also ignorieren und einfach fortfahren, anstelle die vermissten Sockets per Hand mit cp -a nach zu kopieren?
 
Ich habe mit dd ein 150 GB großes File erstellt
Dafür gibt es truncate(1), was zumindest bei FreeBSD beiliegt. Erstellt eine ausgenullte Datei sofort und ohne jede Verzögerung. :)

Also, es gibt mehrere Wege Daten von einer Platte auf eine andere zu kopieren. dump(1) ist die sicherste Methode, da sie alle Metadaten beachtet. In der Praxis sind aber sysutils/cpdup (in DragenflyBSD Teil des Basissystems) und das klassische rsync beliebter, da man nur die "birth time" verliert, welche eigentlich irrelevant ist. tar(1) und cpio(1) gehen natürlich auch. Für die ganz harten BSDler gäbe es auch noch pax(1).

Was die Socket betrifft werden sie bis auf wenige, in der Praxis mehr oder weniger irrelevante Ausnahmen dynamisch angelegt. Musst du dich also nicht drum kümmern und sie auch nicht kopieren. Zu Device-Nodes kann man generell nichts sagen, da sie sehr Betriebssystemabhängig sind. Unter Linux kommt es zudem noch darauf an, ob du udev, devfs, was anderes oder gar kein solches System nutzt. Überhaupt, um nun konkrete Ratschläge geben zu können, müsste man wissen auf welchem System du das Linux umkopiert. :)
 
pax hatte ich ja auch verwendet ... würde das denn auch die Sockets mitkopieren?
turncate verwende ich mitlerweile auch auf FreeBSD, ist aber ein Debian Dom0 geweßen und damals wusstei ch noch nicht wie ich auf Debian solch eine ausgenullte Datei anlege.
Naja - ich habs jetzt geschafft - dennoch wäre das mit pax noch interessant, wenn du das so ausm Kopf heraus weißt.

LG
 
Nein, weiß ich leider nicht. Aber vom Gefühl her würde ich sagen, dass pax aufgrund seiner engen Verwandtschaft mit tar und cpio keine Sockets unterstützt.
 
Alles klar - aber soweit ich das verstanden habe soltle er mir die Sockets ja beim nächsten Systemstart sowieso wieder anlegen und es sollte daher auch keine Probleme geben, richtig?


Hast du Xen Erfahrung? Habe da nämlich ncoh ne kleine Frage zwecks ner Migration von ner 32Bit DomU auf nein 64Bit Dom0 System ...
 
Ja, er wird sie neu anlegen.

Nein. ich habe mit Xen noch nie gearbeitet. Ich glaube noch immer nicht so wirklich an Virtualisierung auf Maschinenebene auf x86-Prozessoren. Ich bin halt altmodisch. :(
 
Ich halte vom konzeptionellen Ansatz her OS-Level Virtualisierung wie zum Beispiel durch Jails oder Solaris Zones noch immer für am besten, da der Overhead unschlagbar gering ist und da man mit diesem Methoden zumindest Pseudoechtzeitanforderung erfüllen kann. Auch ist das Management der virtuellen Systeme meist einfacher, da man auf geteilte Infrastruktur zurückgreifen kann und so weiter.Hypervisoren wie Xen oder dieser VMWare-Kram stellen immer eine Schicht mehr da und egal wie schlank diese ist, es führt immer zu mehr Overhead.
Ich gehe sogar soweit zu sagen, dass Xen und die dicken VMWare Server im Moment schlicht nur deshalb so erfolgreich sind, da die meisten x86-Betriebsysteme bis heute keine vernünftige OS-Level Virtualisierung bieten, man aber die immer dickeren Kisten irgendwie ausgelastet bekommen muss. Was logischerweise nur geht, wenn man immer mehr Dienste auf einer Kiste sammelt.
Klar, Virtualisierung per Hypervisor hat Vorteile wie Migration im laufenden Betrieb, ein Kernel crasht zumindest in der Theorie nicht die ganze Kiste, etc. Aber braucht man das wirklich? Wenn ich keinen Ausfall einer Kiste zur Migration akzeptieren kann, würde ich mir ganz stark überlegen, ob mein System nicht grundsätzlich falsch aufgebaut ist. Wenn ich hochverfügbare Anlagen baue, haben sie immer genügend Redundanzen, sodass ich eine Maschine abziehen kann und gemütlich ersetzen. Wenn ein Kernel crasht, wie kann ich sicher sein, dass er keine anderen Speicherbereiche zerdeppert hat? In der Theorie kann er es nicht, in der Praxis allerdings durchaus. Also darf ich doch wieder alles rebooten.

Das soll nun nicht heißen, dass echte Hypervisoren grundsätzlich schlecht wären. IBM setzt sie seit 45 Jahren in verschiedenen Formen ein, in einigen Bereichen sind sie elementarer Bestandteil des Konzepts. Nur dies sind Architekturen, die Virtualisierung von Beginn an in Hardware und Software unterstützten. Dort musste man nicht in einen gewachsenen Haufen Müll das gerade gehypte Konzept einfrickeln. Das ist nämlich das wirkliche Argument gegen Hypervisoren auf der x86-Plattform. Es war nie vorgesehen, es funktioniert entsprechend nur mit Hacks und Tricks ohne Ende. Ein Beispiel, Intel hatte in seinen "Nehalem"-Prozessoren einen recht üblen Bug, der virtuelle Kontexte teilweise inkonsistent werden ließ. Im Zusammenspiel mit HyperV führte das zu interessanten Fehlern: http://support.microsoft.com/kb/975530 Passieren konnte es nur, da Virtualisierung in diesem Maß ein Aufsatz auf eine Architektur ist, die es nie vorsah.
 
Zu dem Problem mit den Sockets, das ist eins der großen Probleme von Unix, da sie keine richtige Datei-Abstraktion besitzen.

Sie sind übrigens nur vorhanden, solange das Socket offen ist. Wenn du sie kopieren willst, müsstest du auch den Prozess kopieren, der sie gerade offen hat... Das geht so einfach nicht.
 
Wofür soll es den gut sein Sockets in einem Backup zu sichern. Ich kann mir dafür keine Anwendung vorstellen.
 
Back
Top