Hallo zusammen,
ich besitze seit 2 Jahren einen root-server und sichere diesen mit reoback nachdem ich mich mehrere Tage mit Sicherung beschäftigt habe. Wobei ich eher eine Ã?bersicht bekommen habe, welche Backupsoftware es gibt und welche am meisten genutzt wird ;-) Das ganze läuft auch sehr zuverlässig und ich durfte (musste!!!) auch schon einmal ein Recovery erfolgreich fahren. Sagen wir mal so, dass ich ruhig schlafen kann.
Da ich aber mehr gestrickt habe als das ich wußte was ich da genau mache, werde ich sicher ein Recovery nicht mal eben testen oder wiederholen. Jetzt werden sicherlich die Cracks sich denken, dass man die Finger davonlassen soll, wenn man keine Ahnung hat.
Um neue Programme oder Funktionen zu testen, würde ich auch gerne diesen Server verwenden, da ein Testserver schwer nachzugestalten ist und dort was funktionieren kann, was evt. dann auf dem root-server nicht geht. Daher suche ich eine Möglichkeit, wie ich den Server komplett sichern kann (manuell), daran Samstag nachst um 3 Uhr was testen kann um ihn dann wieder um 5 Uhr zurückzuspielen ;-)
Sprich, kein Filesystem, sondern eine Art Ghost. Partimg oder Ã?hnliches kann ich nicht einsetzen, da es ja ein root-server ist und dieser nur direkt oder per Recovery-Console erreichbar ist. Ein Backupspace ist vorhanden. Leider nur 10GB und das System hat eine 40GB Platte. Würde aber bei einer einfachen funktionierenden Lösung sicher auch noch die anderen 30GB dazumieten bzw. einen neuen bestellen.
Meine Zielvorstellung wäre:
1. Recovery-Console hochfahren
2. Backup des Systems auf Backupspace
3. Mailserver beenden und rumtesten
4. Recovery-Console hochfahren
5. System wieder zurückspielen
6. schlafen gehen
Hoffe auf Infos und Lösungsmöglichkeiten. Dankääääää
root-server backup die 99zigste
Re: root-server backup die 99zigste
Dein "Ghost oder Partimg" heißt dd.
Meine Idee wäre: Unterteile mit dd beim Backup die Platte in Segmente (Buffer Size setzen, dann mit skip den Offset und mit count die Größe bestimmen), nach dem Lesen eines Segments kann es von der Ramdisk, in der es zu diesem Zeitpunkt liegt, auf den (FTP-?)Backupserver gespielt werden - ggf. kann man es auch ein zweites Mal lesen und vergleichen, um Lesefehler zu bemerken sowie vom Backupserver zurückholen und wieder vergleichen um Ã?bertragungsfehler zu bemerken.
Danach das nächste Segment usw.
Beim Restore bestimmst du dann den Offset, wo geschrieben wird, mit seek, ansonsten ist es gleich.
Wenn du das in ein ordentliches Skript packst, kommst du zu deinem Szenario und kannst das Skript nachher auch anderen zur Verfügung stellen.
(Die einzelnen Plattensegment-Images könntest du dann auch noch z.B. mit bzip2 packen, um Platz zu sparen.)
Sei dir jedoch dessen bewusst, dass ein solches Komplettbackup insbesondere mit den vorgeschlagenen Ã?berprüfungen lange dauern kann: eine 100MBit-Netzwerkkarte schafft 10 MB/s, macht für 40 GB ca. 15 Minuten - im Bestfall, d.h. der Backupserver ist nicht stark frequentiert. In der anvisierten Zeit dürfte das jedoch nicht der Fall sein, da normale Backupzeit der meisten Systeme wohl in die Zeit von 2-5 Uhr fallen dürften.
Fazit: Technisch machbar, nur praktisch womöglich sehr langsam.
Meine Idee wäre: Unterteile mit dd beim Backup die Platte in Segmente (Buffer Size setzen, dann mit skip den Offset und mit count die Größe bestimmen), nach dem Lesen eines Segments kann es von der Ramdisk, in der es zu diesem Zeitpunkt liegt, auf den (FTP-?)Backupserver gespielt werden - ggf. kann man es auch ein zweites Mal lesen und vergleichen, um Lesefehler zu bemerken sowie vom Backupserver zurückholen und wieder vergleichen um Ã?bertragungsfehler zu bemerken.
Danach das nächste Segment usw.
Beim Restore bestimmst du dann den Offset, wo geschrieben wird, mit seek, ansonsten ist es gleich.
Wenn du das in ein ordentliches Skript packst, kommst du zu deinem Szenario und kannst das Skript nachher auch anderen zur Verfügung stellen.
(Die einzelnen Plattensegment-Images könntest du dann auch noch z.B. mit bzip2 packen, um Platz zu sparen.)
Sei dir jedoch dessen bewusst, dass ein solches Komplettbackup insbesondere mit den vorgeschlagenen Ã?berprüfungen lange dauern kann: eine 100MBit-Netzwerkkarte schafft 10 MB/s, macht für 40 GB ca. 15 Minuten - im Bestfall, d.h. der Backupserver ist nicht stark frequentiert. In der anvisierten Zeit dürfte das jedoch nicht der Fall sein, da normale Backupzeit der meisten Systeme wohl in die Zeit von 2-5 Uhr fallen dürften.
Fazit: Technisch machbar, nur praktisch womöglich sehr langsam.
Re: root-server backup die 99zigste
Hallo,
das hört sich schon mal verdächtig gut an. Die Geschwindigkeit spielt in erster Linie keine Rolle. Eine Stunde hin und herschaufeln ist ok, da erstens kein großer Mailtraffic laufen wird und zweitens die anderen Mailserver ja geduldig sind und die Mail ja noch ne Weile behalten (glaube erst in 4 Stunden bekommt der Absender eine Infomail).
Nun zu Deiner Idee:
Ich habe ne Ramdisk über 20MB, dass Script würde dann auf dem FTP Server liegen, was ich mir dann jedesmal ziehen muss wenn ich im Rescuesystem hochfahre.
if=/dev/hda .......... of=/ramdisk/image.img
Er fängt an und liest sich 20MB, kopiert dieses in image.img. Dann kopiere ich per ftp diese Datei zum FTP-Server und lösche dieses lokal. dd macht dann den zweiten Block mit 20MB der ebenfalls dann kopiert wird und so weiter. Später habe ich dann auf dem FTP-Server 2000 Dateien a 20MB ;-) Aber egal. Gut, dann würden die 10GB Backup ja nicht ausreichen ;-( Der Server hat nur ein Datenvolume von 1,5 GB, was sich auch nicht ändern wird.
Habe ich das so richtig verstanden ???
Wie sieht es mit Filekopie aus ??? Kann ich nicht im Rescuesystem booten und die Partitionen mounten und dann per ftp kopieren. Bei einem Restore würde ich dann einfach alles lokal löschen und per ftp zurückkopieren. Da läuft ja nichts, also bekomme ich auch keine Probleme mit mysql oder sonstigen Diensten oda ??? Nur denke ich, dass ftp nicht alle Dateirechte mitnimmt und ob Grub dann Ã?rger macht.
Beispiel:
Ich tar jeden Ordner in /home (Home hat den größten Platz). Kopiere alles per ftp weg. Dann tar ich /home nach /var (zweitgrößten Platz ;-) und ebenfalls per ftp weg.
Später dann per ftp wieder lokal und dann auspacken
Auh man wird das alles verstrickt ;-( Ich glaube es gibt 1000 Möglichkeiten und ich fange jede an, bring aber keine zu Ende.
das hört sich schon mal verdächtig gut an. Die Geschwindigkeit spielt in erster Linie keine Rolle. Eine Stunde hin und herschaufeln ist ok, da erstens kein großer Mailtraffic laufen wird und zweitens die anderen Mailserver ja geduldig sind und die Mail ja noch ne Weile behalten (glaube erst in 4 Stunden bekommt der Absender eine Infomail).
Nun zu Deiner Idee:
Ich habe ne Ramdisk über 20MB, dass Script würde dann auf dem FTP Server liegen, was ich mir dann jedesmal ziehen muss wenn ich im Rescuesystem hochfahre.
if=/dev/hda .......... of=/ramdisk/image.img
Er fängt an und liest sich 20MB, kopiert dieses in image.img. Dann kopiere ich per ftp diese Datei zum FTP-Server und lösche dieses lokal. dd macht dann den zweiten Block mit 20MB der ebenfalls dann kopiert wird und so weiter. Später habe ich dann auf dem FTP-Server 2000 Dateien a 20MB ;-) Aber egal. Gut, dann würden die 10GB Backup ja nicht ausreichen ;-( Der Server hat nur ein Datenvolume von 1,5 GB, was sich auch nicht ändern wird.
Habe ich das so richtig verstanden ???
Wie sieht es mit Filekopie aus ??? Kann ich nicht im Rescuesystem booten und die Partitionen mounten und dann per ftp kopieren. Bei einem Restore würde ich dann einfach alles lokal löschen und per ftp zurückkopieren. Da läuft ja nichts, also bekomme ich auch keine Probleme mit mysql oder sonstigen Diensten oda ??? Nur denke ich, dass ftp nicht alle Dateirechte mitnimmt und ob Grub dann Ã?rger macht.
Beispiel:
Ich tar jeden Ordner in /home (Home hat den größten Platz). Kopiere alles per ftp weg. Dann tar ich /home nach /var (zweitgrößten Platz ;-) und ebenfalls per ftp weg.
Später dann per ftp wieder lokal und dann auspacken
Auh man wird das alles verstrickt ;-( Ich glaube es gibt 1000 Möglichkeiten und ich fange jede an, bring aber keine zu Ende.