1&1 RootServer - HDD Image Backup

[Micha_J]

Hallo,
ich habe einen Root von 1&1 mit Plesk 7.5.4.
Um meine Daten wirklich einfach zu Sichern würde ich gerne auf ein HDD Image Tool zurückgreifen um im Notfall wieder so schnell und vor allem
so unkompliziert wie möglich, meinen "alten" Stand wieder herstellen.

Ich habe hier im forum schon viel gelesen, z.b. von dem Tool G4L, es scheint auch eine Benutzeroberfläche zu haben.

Meine Fragen:

• Ist G4L auch über Putty komplett Oberflächengesteuert?
• Gibt es G4L vielleicht auch in Deutsch?
• Kann G4L selbstständig z.b. einmal die Woche einen FTP Backup fahren?
• Läuft die Rücksicherung nach der Ausführung aus der Oberfläche selbstständig bis zum Serverreset durch?
• Gibt es hier jemanden der sich mit G4L auskennt und den ich bei Fragen mal ansprechen dürfte?

Ich hoffe die Fragen sind hier richtig und nicht zu unverschämt.
In der Dokumentation von G4L stand leider nicht viel drin, war nur eine 10 seitige PDF.

Vielleiucht hat ja auch jemand eine bessere Idee für mein vorhaben?

Ich danke Euch!!

Gruß aus dem Norden,
Micha

 

[Micha_J]

Hätte denn jemand eine andere Idee oder Software mit der man einen Server Image to FTP machen kann?

BITTE

 

[Rocko]

Also mit anderen Worten, du hast 0 Ahnung und willst mit einem Knopfdruck ausm Rescue System deine HDD wiederherstellen bei Problemen?

So schön stell ich mir das auch mal vor..
Leider kenn ich sowas nicht...

Aber mal im Ernst.. Ich mach das Backuppen anders.
Ich packe alles in ein BZIP2 Archiv, und das funktioniert sogar. Hatte schonmal damit das System "reaktiviert". Es speichert alle Berechtigungen noch dazu.

Dafür müsstest du folgenden Befehl in "/" ausführen:

tar --atime-preserve --ignore-failed-read --numeric-owner --same-owner --exclude=sysbackup-25.01.2006.tar.bz2 -cjlvpf sysbackup-25.01.2006.tar.bz2 ./

Das ganze dauert je nach Hardware und Daten 1-3 Stunden.
Die fertige TAR Datei kann man aufn BACKUP Space hochladen.


Einige werden vielleicht meinen, das ist eine "billige" Möglichkeit, aber sie funktioniert sehr gut

 

[Dawn]

Finde diese Anleitung sehr gut Bei Netdirekt habe ich die Möglichkeit einen Rescue-Modus zu booten (so kann ich sicher gehen das keine Dienste mehr laufen bzw. sonst auf den Server zugegriffen wird). Dann mounte ich die entsprechende Partition:

mount /dev/hda1 /mnt

Danach wechsle ich ins Verzeichnis /mnt und führe den folgenden Befehl aus (die Tar/Gzip-Variante):

tar --atime-preserve --ignore-failed-read --numeric-owner --same-owner --exclude=sysbackup-[Datum].tgz -czlvpf sysbackup-[Datum].tgz ./

Weiss jemand was die bessere Kompression hat bzw. schneller ist Gzip oder Bzip?

Gruss,
Dawn

 

[Rocko]

Na bzip natürlich, hat manchmal nen Vorteil von 30%. Dauert dafür aber auch länger.

 

[Dawn]

Intressant zu wissen... Also für ca. 1.4 GB Daten hatte ich auf einem Athlon XP 2000, 512MB Ram ca. 10 Minuten für das Backup (war etwa 750MB) gross.

Weiss jemand von euch wie man das Backup verschlüsseln kann zum beispiel per GPG? Was ist die beste Variante? Wenn ich mein Backup auf einen anderen Server stelle, möchte ich ja nicht das alle Passwörter herausgelesen werdenn können...

Gruss,
Dawn

 

[Micha_J]

Hi Rocko,
ja, ich muss leider zugeben, ich habe eigentlich null ahnung von einem Root Server, bin aber vom Chef dazu versammt mich darum zu kümmern. Eigentlich läuft er ja, aber ein Backup ist eben nicht ganz unwichtig dachte ich.

Deine Lösung würde ich gerne übernehmen, bei meinem Windows System mache ich es eigentlich genauso und das Funktioniert auch seit Jahren zuverlässig, wusste nicht das es bei Suse auch geht.

Deinen Befehl binde ich in einen Crontab ein, oder?

Noch eine Frage, wenn ich das Archive dann mal wieder entpacken muss,
wie ist die Zeile dafür aufgebaut?

 

[Dawn]

Ich möchte mich Micha_J anschliessen. Wie genau entpackt man dann das Backup-Archiv wieder um die Dateien 1:1 wiederherzustellen?

Ich habs mal mit

tar xfvz [archivdatei.tgz]

versucht. Ging leider nicht wirklich...

Überhaupt wenn ich mir die Parameter so anschaue:

tar --atime-preserve --ignore-failed-read --numeric-owner --same-owner --exclude=sysbackup-[Datum].tgz -czlvpf sysbackup-[Datum].tgz ./

--atime-preserve = Zugriffszeit beim Auspacken erhalten (macht das Sinn für die Komprimierung, wäre das nicht für die Dekomprimierung?)

--ignore-failed-read = Kein Abbruch bei nicht lesbaren Dateien (überhaupt nötig wenn per Rescue-Konsole auf die Harddisk-Partition zugegriffen wird?)

--numeric-owner = Zahlen für Benutzer bzw. Gruppen benutzen (was hat das für einen Vorteil?)

--same-owner = Eigentümer beim Auspacken erhalten (macht das Sinn für die Komprimierung, wäre das nicht für die Dekomprimierung?)

--exclude=sysbackup-[Datum].tgz = Dateien auslassen (macht Sinn Archiv soll ja nicht versucht werden zu komprimieren)

-c = neues Archiv erzeugen (macht Sinn)

-z = Archiv mit gzip (de)komprimieren (macht Sinn)

-l = beim Erzeugen Dateisystem nicht wechseln (macht Sinn)

-v = zu bearbeitende Dateien ausführlich listen (macht Sinn)

-p = Zugriffsrechte beim Auspacken erhalten (macht das Sinn für die Komprimierung, wäre das nicht für die Dekomprimierung?)

-f = Gerät oder Datei ARCHIV benutzen (macht Sinn ja)

./ (am Schluss) = verstehe ich leider nicht???

Wäre froh wenn hier jemand ein wenig Licht ins Dunkle bringen würde..

Gruss & ein grosses Dankeschön,
Dawn

 

[Dawn]

Es ist sonst nicht meine Art einen Thread hochzupuschen, jedoch benötige ich sehr dringend eine Antwort auf die folgende Frage:

Wie genau entpacke ich mein SO gepacktes Tar-Archiv so dass alles genauso ist, wie die Dateien welche ich gepackt habe (Dateidatum/-zeit, Rechte, Owner usw...)?

EDIT: Habs nun selber hingekriegt:

Backup:

1. Server im Rescue-Mode booten (um sicherzustellen damit keine Dienste mehr laufen)
2. Per folgenden Befehl Partition mounten:

mount /dev/[Datenpartition] /mnt

3. Ins Verzeichnis /mnt wechseln:

cd /mnt

4. Server backupen:

tar --atime-preserve --ignore-failed-read --numeric-owner --same-owner --exclude=[Name des Archivs].tar.bz2 -cjlvpf [Name des Archivs] ./

5. Backup-Archiv per mc auf Backup-Server speichern.

Restore:

1. Server im Rescue-Mode booten (um sicherzustellen damit keine Dienste mehr laufen)
2. Per folgenden Befehl Partition mounten:

mount /dev/[Datenpartition] /mnt

3. Ins Verzeichnis /mnt wechseln:

cd /mnt

4. Am einfachsten per mc alles auf /dev/[Datenpartition] löschen
5. Image per FTP hoch/herunterladen
6. Folgenden Befehl ausführen:

tar jxvpf [backup-datei]

 

[Rocko]

Du vergisst eins... wenn der beim packen, nicht alle Sicherheitsberechtigungen und owner ids speichert, dann kann er sie beim entpacken nicht wiederherstellen, ergo macht es schon Sinn !

Ausserdem war mein Vorschlag nicht TGZ sondern BZIP, da es ein viel besseren Algorhytmus hat, und demnach besser packt, und vor allem viel viel kleiner.

Zudem nix von hda1 löschen, sondern nur wenn da das / verzeichnis gemountet ist, und net /boot/
Bei mir ist hda1 /boot/, und hda2 swap, und hda3 ist /.
Also aufpassen da...

P.S. Du solltest schon wissen, wofür das "./" am ende steht.

 

[Dawn]

@Rocko: Stimmt du hast recht, das war vielleicht ein wenig zu unpräzise:

./ war ne dumme Frage, das heisst das dass Komplette VFS (/) ins Archiv soll...

Das mit Bzip wusste ich nicht so exakt, aber macht Sinn für mich.

/dev/hda1 sollte besser /dev/[Datenpartition]

Ich werde das letzte Posting ändern, damit auch andere damit andere auf einen Blick mit der Problematik klar kommen.

 

[Rocko]

Ich sollte vielleicht noch dazu sagen, das ich den Server fürn Backup nie ins Rescue Modus fahre, das ist nicht unbedingt nötig.
Backuppe immer im laufenden Betrieb, und wie gesagt, war ein Einspielen des Backups ohne Probleme möglich.

Wer eh grad rebooten will, kanns natürlich optional im Rescue Modus machen

 

[Dawn]

@Rocko:

Wie stellst du denn sicher das auch laufende Datenbanken richtig gebackupt werden? Angenommen ein User greift gerade in der Sekunde in der du backupst auf die DB zu... Kann das nicht ein ziemliches durcheinander geben?

Ich denke deswegen nutzt du auch den Parameter "--ignore-failed-read"? Wenn der Server im Rescue-Mode gestartet wurde, ist das ja nicht wirklich nötig, da man ja als Root eingeloggt ist und eh problemlos Zugriff auf alle Dateien hat (denke ich mal?).

 

[Rocko]

@Rocko:

Wie stellst du denn sicher das auch laufende Datenbanken richtig gebackupt werden? Angenommen ein User greift gerade in der Sekunde in der du backupst auf die DB zu... Kann das nicht ein ziemliches durcheinander geben?

Nein, er speichert ja den derzeitigen Stand.

Ich denke deswegen nutzt du auch den Parameter "--ignore-failed-read"? Wenn der Server im Rescue-Mode gespeichert wurde ist das ja nicht wirklich nötig, wenn man als Root einloggen kann.

Jo, aber auch weil diverse Sachen während des Betriebs nicht ausgelesen werden können, sind aber nur unwichtige Sachen, prozesse, pids.. kA.

Windows kann man auch im Betrieb backuppen, früher war auchn reboot notwendig damit er es ausserhalb windows backuppen tut, heute gehts während des Betriebs mit .NET Framework

 

[Dawn]

@Rocko: Gut wir wollen ja nicht M$ als Referenz nehmen *lach* Nein was ich gemeint habe: Angenommen ein Script läuft gerade, das ist zu 70% ausgeführt wenn das Backup durchläuft. Wenn man das Backup zurücklädt dann sind ja eini Teil der Daten dort und der andere Teil ist unvollständig... Dases geht glaube ich sicher, aber ich denke es kann durchaus auch zu Problemen führen (das haben mir jedenfalls einige Leute gesagt).

 

[Huschi]

Wenn man das Backup zurücklädt dann sind ja eini Teil der Daten dort und der andere Teil ist unvollständig...

Das Problem wirst Du immer haben.
Man kann es zwar versuchen zu minimieren, aber dazu gehört meist ein Eingriff in fast alle laufenden Software-Pakete. Und bei großen Datenbanken kann man es evtl. nicht vermeiden.

Ich wollte nur der Vollständigkeithalber ansprechen, daß ich dieses Vorgehen (Backup einer ganzen HD) für schwachsinnig halte.
Aber dazu gibt es ja bereits andere Threads. (Bitte die Boardsuche verwenden.)

huschi.

 

[Tiggr]

Guten Morgen,

wenn ich soweit alles richtig verstanden habe, müsste ich bei meiner Konfiguration:

dev/md1        /       ext3    defaults        1 1
/dev/sda2       none    swap    sw
/dev/sdb2       none    swap    sw
/dev/md5        /usr    xfs     defaults        0 2
/dev/md6        /var    xfs     defaults,usrquota       0       2
/dev/md7        /home   xfs     defaults,usrquota       0 2
/dev/md8        /srv    xfs     defaults,usrquota       0 2
devpts          /dev/pts        devpts  gid=5,mode=620  0 0
none            /proc   proc    defaults        0 0
none            /tmp    tmpfs   defaults        0 0

die befehle für folgende Devices wiederholen:

/dev/md1
/dev/md5
/dev/md6
/dev/md7
/dev/md8

Oder habe ich etwas wichtiges übersehen?

MySQL ist dann ja auch nach dem Restore wieder am Start...

Ein kurzes "OK" oder "überdenk die Sache nochmal genau" würde mir schon reichen!

LG der Tiggr!