Hi, Am 21.06.2011 23:14, schrieb Peter Mc Donough:

Hi,

...

Ich möchte gerne Linux mit allem "Furz und Feuerstein" im laufenden Betrieb über rsync sichern.

im laufenden Betrieb weiss ich nicht, aber sonst

...

Die zweite wäre dann die Frage nach den Optionen. Nach einer Sichtung der manpage von rsync ist mir zwar hinreichend schwindelig, aber nun

habe ich die besten Resultute im "stehenden" Betrieb mit

rsync -avxHSAX --delete /Pfad zum Quellverzeichnis/ . (sicherheitshalber im Zielverzeichnis) erzielt

--exclude-from=(Dateiliste mit nicht zu sichernden Dateien) hält dir Unerwünschtes aus der Sicherung

--exclude-from= solltest Du aber gewissenhaft setzen, den neben /proc und /sys gibt es tiefer im Dateisystem nochmal solche Dateien, die nur zur Laufzeit existieren und sehr sehr gross sind. Habe jetzt gerade kein solches Linux hier und kann nicht nachsehen. Gruss Werner

Peter, Am 22.06.2011 13:30, schrieb Peter Mc Donough:

...

...

--exclude-from=(Dateiliste mit nicht zu sichernden Dateien)

--exclude-from= solltest Du aber gewissenhaft setzen, den neben /proc und /sys gibt es tiefer im Dateisystem nochmal solche Dateien, die nur zur Laufzeit existieren und sehr sehr gross sind.

In meinem Fall, boote ich das System (Einzelrechern) mit der Installationsdisk, dem Rescue Abschnitt, damit sind garantiert keine Systemdateien offen.

Dann lege ich unter /mnt zwei Verzeichnisse an /mnt/in und /mnt/out und mounte das zu sichernde System readonly.

Irgendwann werde ich mir eine kleine Linuxpartition einrichten, von der aus das Hauptsystem gesichert wird.

Dann sicherst Du ja kein laufendes System. Ich bin da nur kürzlich reingefallen, als ich ein laufendes System auf eine zweite Partition kopieren wollte. Bei älteren OS ging das mal so, aber jetzt sollte das zu kopierende System nicht laufen. Gruss Werner

Hallo, Am Wed, 22 Jun 2011, Werner Franke schrieb:

Am 22.06.2011 13:30, schrieb Peter Mc Donough:

...

Irgendwann werde ich mir eine kleine Linuxpartition einrichten, von der aus das Hauptsystem gesichert wird.

Dann sicherst Du ja kein laufendes System. Ich bin da nur kürzlich reingefallen, als ich ein laufendes System auf eine zweite Partition kopieren wollte. Bei älteren OS ging das mal so, aber jetzt sollte das zu kopierende System nicht laufen.

Also, das System hier hab ich im laufenden Betrieb von der Original 11.2 aus kopiert (init S, rsync -auxPRAXSH / /P_SUSE/) und die 11.2 Kopie auf /P_SUSE gebooted und mit zypper dup (Repos alle an, alle auf 11.4 umgestellt) von 11.2 dann auf 11.4 gezogen. Da ich den rsync- Befehl in der ~/.bash_history habe war / dabei nicht ro gemounted. Das was halt dann noch im Original geloggt / in die history geschrieben wurde wurde halt nicht mit kopiert. Egal. HTH, -dnh -- Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. -- Calvin & Hobbes, 8.11.1989 -- 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

On 22.06.2011 18:38, Tao te Puh wrote:

Am 22.06.2011 10:18, schrieb Sandy Drobic:

...

On 21.06.2011 21:27, Tao te Puh wrote:

...

Ich möchte gerne Linux mit allem "Furz und Feuerstein" im laufenden Betrieb über rsync sichern.

Das führt fast zwangsläufig zu LVM und Snapshots. Ohne einen Snapshot wirst du das nicht schaffen, da sonst Dateien offen sind, die dann nicht gesichert werden.

Aha! Na dann werde ich mir das wohl mal angucken müssen.

...

...

Ziel ist es, bezüglich der Rücksicherung, ein vergleichbares Ergebnis zu erreichen wie wenn ich mit z.B. mit Clonezilla ein Backup erstellen würde.

Es hat aber gute Gründe, warum dies nicht aus dem laufenden System geschieht.

Nun ja, aber es gibt ja Programme die meinen das im laufenden Betrieb zu können, siehe "VMware Converter" für Windows oder "Relax & Recover" für Linux.

...

...

Die erste Frage in diesem Zusammenhang wäre: Geht das überhaupt oder muss man hier in jedem Fall mit Reibungsverlusten rechnen?

Mit kleinen Verlusten muss man immer rechnen. Z.B. eine MySQL-Datenbank, welche im laufenden Betrieb offen ist und geschäftig Daten schaufelt. Diese sollte man dann natürlich vorher kurz anhalten oder zumindest das Schreiben in die Datenbank stoppen.

Ich würde natürlich versuchen, den entsprechenden Prozessen eine Denkpause zu verpassen.

...

...

Die zweite wäre dann die Frage nach den Optionen. Nach einer Sichtung der manpage von rsync ist mir zwar hinreichend schwindelig, aber nun habe ich eigentlich noch mehr Fragen als Antworten ...

Das ist weniger eine Frage von rsync als eine Frage, wie die Daten konsistent gehalten werden können, damit rsync diese kopieren kann.

Was genau meinst Du damit?

Wenn du einen großen Datenpool hast, der sich laufend verändert, dann hast du nicht einen Backupzeitpunkt, sondern einen Backupstrich, wo du nicht sauber definieren kannst, wann die Dateien gesichert wurden. Das führt dazu, dass Datenbanken, welche voneinander abhängen, mit einem unterschiedlichem Stand gesichert werden. Bei meinem Cyrus Imap-Server gibt es z.B. Indexe, welche sehr wichtig sind. Deshalb mache ich einen Snapshot des Imap-Verzeichnisses und exportiere die Indizes von diesem Snapshot. Dann wird dieser Snapshot mit rsync gesichert. So gehe ich sicher, dass die exportierten Datenbanken und die Verzeichnisse mit den Mails wirklich zusammenpassen. Ein anderes Beispiel ist die Sicherung von virtuellen Maschinen. Im laufenden Betrieb kann es sein, dass die VMs wild schreiben und der Snapshot mitten in einer Transaktion gemacht wurde. Also wird die VM erst einmal eingefroren, der Snapshot gemacht und dann der normale Betrieb der VM wieder aufgenommen. Damit hat die VM des Snapshots einen definierten Zustand und kann gesichert werden. Nach dem Backup wird der Snapshot verworfen und gut ist.

...

...

Okay, Sym- und Hardlinks wären mir auch noch eingefallen, ebenso die Berücksichtigung der GID/UID - aber da gibt es ja noch Dinge, von denen ich noch nie gehört habe wie --acls und --xattrs etc.

Eine Option die einem Clone-Modus nahe kommt, habe ich leider nicht gefunden ;-)

Wie könnte so ein rsync-Befehl aussehen.

Sag mal lieber was für ein System gesichert werden soll. Handelt es sich hier um einen Server (wenn ja, welche Dienste laufen darauf?) oder eine Workstation mit X?

Konkret geht es um zwei Systeme.

Das Eine (ein Server) ist schon sehr betagt und darauf läuft so eine typische "alles was der Siedler braucht"-Umgebung, also LAMP mit diversen Applikationen, Netzwerk (DNS, DHCPD, NTPD, Postfix, fetchmail, Internetgateway, Samba/NFS/FTP usw.). Das System hat einen 3ware-Controller und RAID-5 sowie einen alten USB 1.0. Da bin ich mit Clonezilla erst einmal nicht weitergekommen und eine Sicherung via tar/rsync bei gestopptem Betrieb, wollte mal eben 36 Stunden spendiert bekommen.

Die meisten Dienste sollten kein Problem darstellen, selbst wenn das Backup viele Stunden dauert. Ist das wirklich so ein großer Datenbestand oder ist das RAID einfach lahm? Tipp: Wenn viele verschieden Anforderungen auf dem Server laufen, kann es wirklich helfen, mehrere RAIDS einzurichten und nach den IO-Anforderungen aufzuteilen. Je mehr parallele Zugriffe auf ein RAID gleichzeitig erfolgen, desto langsamer wird die Gesamtleistung. Wie genau läuft der Syncvorgang ab, auf eine zweite Partition des Servers oder eine externe Festplatte oder einen zweiten Server über das Netz?

Das andere System ist mein Arbeitsplatz. Das hat ein Software-RAID-0. Da habe ich überhaupt keinen Weg gefunden das mit Clonezilla zu sichern - außer jede Partition für sich, aber dann kann ich damit ja nicht umziehen auf z.B. ein neues RAID-1-System oder anderes Filesystem.

Für alles Rechner existiert eine nächtliche, inkrementelle Datensicherung. Die ist auch mit rsync realisiert. Aber die ist eben nicht für ein "Deasater Recovery", eine Virtuallisierung oder sonstige Migration (RAID0 -> RAID1, oder neues Filesystem) geeignet.

Ehrlich gesagt hatte ich es aufgegeben, unseren Oracleserver (RHEL 5.3) über einen Clone zu virtualisieren und habe es schließlich doch über ein Dateibackup gemacht. Unter Linux ist alles eine Datei, deshalb funktioniert das auch so schön. (^-^) -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@)drobic (.) 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

Am 24. Juni 2011 19:33 schrieb Tao te Puh :

Das Problem ist die alte Hardware. In diesem Fall primär der langsame USB 1.0-Anschluss.

Geh zum nächsten Computer-Laden und kauf eine USB-2 Karte für PCI. Kostet ca. 4,95 €. :-) Gruß Martin -- 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

Am 22.06.2011 10:18, schrieb Sandy Drobic:

On 21.06.2011 21:27, Tao te Puh wrote:

...

Ich möchte gerne Linux mit allem "Furz und Feuerstein" im laufenden Betrieb über rsync sichern.

Das führt fast zwangsläufig zu LVM und Snapshots. Ohne einen Snapshot wirst du das nicht schaffen, da sonst Dateien offen sind, die dann nicht gesichert werden.

...

Ziel ist es, bezüglich der Rücksicherung, ein vergleichbares Ergebnis zu erreichen wie wenn ich mit z.B. mit Clonezilla ein Backup erstellen würde.

Es hat aber gute Gründe, warum dies nicht aus dem laufenden System geschieht.

Hallo Mitlistige, ich mag noch "kurz" berichten, wie die Sache dann für mich ausgegangen ist. Dank Eurer Tipps, bin ich nun, für meinen neuen Server, folgenden Weg gegangen: LVM-Snapshot und fsarchiver. Somit ist der Betreff dieses Threads eigentlich überholt ... Das mit den LVM-Snapshots ist ja wirklich recht einfach, man muss lediglich beim Verwalten der VG darauf achten, dass noch etwas Platz für Snapshots über ist. Statt dann aber diesen Snapshot mit einem "einfachen" rsync oder einem "dicken" dd zu sichern, habe ich mich für die Sicherung via fsarchiver entschieden. Das scheint mir ein guter Kompromiss bezüglich Geschwindigkeit, Zuverlässigkeit und Backup-Dateigröße zu sein. Aus der Praxis kann ich folgendes berichten: Ich habe mal testweise eine frische 11.4/Tumbleweed-Installation, welche in einem LVM residiert das wiederum auf einem Software-RAID-1 geparkt ist, versucht via LVM-Snapshot und fsarchiver in eine VM zu migrieren. Der LVM-Snapshot ist, wie geschrieben, keine große Sache. Dann kommt die Sicherung dieses Snapshots via fsarchiver. Da war ich recht angenehm überrascht. Ein komplette Sicherung des gesamten Systems (rund 4GB in einem 16GB-LV) auf eine USB-Platte, hat lediglich 6 Minuten gedauert. Dabei entsteht eine Archivdatei die "nur" 1,5GB in Anspruch nimmt (Standardkomprimierung, geht also auch noch kleiner). Das werde ich nun wohl jede Nacht automatisiert machen und dieses Archiv mit in die normale nächtliche Sicherung mit aufnehmen - so kann ich mir im Notfall immer mal schnell das System von gestern wieder komplett neu aufsetzen. Außerdem passt so ein 1,5 GB großes Archiv auch locker auf eine DVD und man hat so auch mal eine Langzeitsicherung des Systems. Den großen Vorteil des fsarchiver sehe ich darin, dass wirklich nur "Nutz"-Daten gesichert und diese dann auch noch komprimiert werden. Das ist sehr schnell und erzeugt ein kleines Archiv. Außerdem kann man mit fsarchiver auch auf eine kleinere Zielpartition umziehen und nicht zuletzt, kann man bei dem Umzug auch noch das Dateisystem wechseln! Das macht fsarchiver übrigens vollkommen selbstständig vorausgesetzt, man setzt den entsprechenden Parameter beim zurück spielen. Einziger Wermutstropfen am fsarchiver ist bisher, dass man das Archiv nicht, wie z.B. dd, mal eben mounten oder, wie z.B. bei tar, einzelne Dateien extrahieren kann. Mann braucht also zwingend eine freie Partition (oder LV), auf dem man dann das komplette Archiv entpackt, auch wenn man nur eine Datei benötigt. Mich stört das in sofern nicht, als das meine Maschinen sowieso jeder Nacht gesichert werden und ich so also an die einzelnen Dateien auf diesem Weg ran komme. Außerdem wird dieses Feature auch von vielen anderen Anwendern beim Entwickler angefragt und es wird wohl auch schon an einer Lösung gewerkelt. Das Wiederherstellen - oder in diesem Fall die Migration in Richtung VM - war eigentlich auch keine große Sache. Am fummeligsten sind dabei eigentlich immer nur die ganzen kleinen Befehle die man im Alltag ansonsten nicht so häufig benutzt, also RAID und LVM einrichten/starten/stoppen usw., aber die notiert man sich dann halt mal wieder ... Auch musste ich einiges an Lehrgeld bezahlen weil ich das RAID-1 von Hand aufgesetzt habe und mir die Sache mit den Versionen der Metadaten nicht bekannt war - legt man so wie ich das RAID einfach nur an, kann man später davon nicht booten, da grub rum nörgelt und muss von vorne anfangen ... aber gut, zum Glück habe ich ja alles mitgeschrieben und die "copy & paste"-Lösung. Um sich das manuelle Einrichten des neuen System bezüglich Disklayout zu ersparen, kann man sich auch mal intensiver mit "Relax & Recover" auseinander setzen. Das nimmt einem die lästige Arbeit bezüglich Disklayout komplett ab - wie es aber so ist, huscht das dann alles voll automatisiert und ohne Nachfrage durch und ich habe mir dann so auch mal eben eine USB-Platte, welche dummerweise noch mit dran hing und sich zwischen sda und sdb drängelte, komplett zersägt ... war aber nichts wirklich wichtiges drauf und eine gute Gelegenheit mal testdisk und phtorec auszuprobieren ... Zur Wiederherstellung des Sytems habe ich die VM dann mit dem SuSE-Rescue-System gestartet, dass Netzwerk und sshd gestartet und die weitere Konfiguration via ssh erledigt. Dann kann man mit "copy & paste" arbeiten. So habe ich dann also die VM mit Disklayout/RAID-1/LVM vorbereitet. Dummerweise hat die SuSE-Rescue kein fsarchiver an Board, so dass ich deshalb extra das System erneut starten musste, diesmal mit SystemRescuCd. In diesem Zustand, habe ich dann das Archiv wieder via fsarchiver auf das System zurück gespielt. Das hat ebenfalls nur wenige Minuten gedauert. Den letzten Schliff habe ich dem System dann wieder im SuSE-Rescue System verpasst. Da gibt es ja noch einige Anpassungen die zu erledigen sind (menu.lst, device.map, fstab, mdadm.conf ...) und dann muss der grub natürlich noch den mbr neu beschreiben. Ich bin also mit der Lösung LVM-Snapshot und fsarchiver derzeit sehr glücklich und kann mein System in 30 bis 60 Minuten wieder komplett herstellen. Auch kann ich künftig SuSE-Versionssprünge, "mal eben" in einer VM austesten. Leider habe ich nicht alle meine Maschinen mit LVM eingerichtet - das wird sich in Zukunft sicherlich ändern ... Vielen Dank dann also nochmal an Euch alle für Eure Tipps! -- Herzliche Grüße Tao -- 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