Archiv verlassen und diese Seite im Standarddesign anzeigen : Grundlegende Fragen zum Server Backup
Ich bin auf der Suche nach einer geeigneten Backuplösung für einen Webserver.
Darauf läuft Debian Sarge und die bisherige "Datensicherung" bestand lediglich aus einem Raid1, nun soll aber ein "richtiges" Backup her.
Grundsätzlich möchte ich es so, dass alle X Tage (wohl als Cronjob) ein Backup erstellt wird, welches gepackt an einen anderen Rechner im Netzwerk übertragen wird, automatisch natürlich.
Nun haben sich bei den Grundüberlegungen doch ein paar Fragen ergeben.
1. Komplette oder nur teilweise Sicherung?
Wenn es komplett ist gehe ich davon aus, dass wenn es einmal wieder eingespielt ist alles funktioniert, genau wie früher halt. Wenn ich nur Teile sichere wie läuft es dann ab beim Wiederherstellen? Grundsystem installieren und die Config Sachen alle wieder einspielen denk ich mir da spontan, aber geht das auch reibungslos? Und wie verhält sich das wenn geringfügige Änderungen an der Hardware vorgenommen wurden (z.B. neue Festplatte)?
Und ist es möglich bei laufendem System einfach komplette etc Ordner usw. zu ersetzen?
Prinzipiell hätte ich nämlich schon lieber eine komplette Sicherung, falls dies machbar ist.
das 2. Problem ist: In welcher Form sichern?
Mir fehlt da eine konkrete Vorstellung, kann man einfach den kompletten Datenbestand automatisch in ein Image packen lassen und dieses gepackt an den Backup Rechner schicken?
Oder gar ein riesiges Archiv ohne erst ein Image erstellt zu haben? Klingt irgendwie nach Stümperei, vielleicht kann mir jemand auf die Sprünge helfen was gängige Methoden sind, bzw. welche Software/Befehle man am besten einsetzt. Mir würde spontan bloß dd einfallen, was ich aber vermeiden möchte ;) Die Frage die sich mir dann stellt ist auch wie das ganze wieder eingespielt werden soll.
3. (und letzte) Frage: Wie übertragen?
Gibt es da etwas worauf man achten sollte? Der Zielrechner wird aller Voraussicht nach ein Windowssystem haben, soll ich zur Übertragung FTP nutzen oder die Freigabe als Netzlaufwerk mounten, oder mit smbclient, oder...., ... ?
Danke im Voraus
hi, also ich kann von mir nicht behaupten, dass ich bei diesem thema gut bin, doch sichere ich meine wichtigen sachen in ein tar.gz archiv und übertrage es dann via ssh auf nen anderen server.....
der dann das ganze auf band sichert....
funktioniert bei mir ziemlich gut - jedoch stoppe ich die webserverdienste vor dem sicherungsvorgang.....
alles automatisch via cron....
baumgartner
30.06.06, 10:00
doch sichere ich meine wichtigen sachen in ein tar.gz archiv und übertrage es dann via ssh auf nen anderen server.....
Hallo,
ein Backup zu zippen ist gar nicht gut, denn wenn hier nur ein bit fehlerhaft ist, ist das ganze Archiv defekt, besser ist es als *.tar, da wär dann nur eine einzelne Fehlerhaft.
Ich selbst mache bei mir Backup von den Daten mittels rsync-backup auf eine externe HD auf einem entfernten Rechner. Gleichzeitig dazu sichere ich auch /etc um evtl. unüberlegte Änderungen schnell & einfach wiederherstellen zu können, wenn das System neu aufgesetzt wurde würd ich das aber nicht machen ;-)
Der Vorteil von rsync-backup ist dass du die letzte Version mit simplem kopieren wiederherstellen kannst. Im aktuellen FreeX ist dazu ein guter Artikel drinnen, also einfach mal in den nächsten Kiosk und....
mfg Martin
Ich bin auf der Suche nach einer geeigneten Backuplösung für einen Webserver.
Dann schauen wir mal was wir für dich in der Kiste haben.
Darauf läuft Debian Sarge und die bisherige "Datensicherung" bestand lediglich aus einem Raid1, nun soll aber ein "richtiges" Backup her.
RAID != Backup. Magst du russisches Roulette?
Grundsätzlich möchte ich es so, dass alle X Tage (wohl als Cronjob) ein Backup erstellt wird, welches gepackt an einen anderen Rechner im Netzwerk übertragen wird, automatisch natürlich.
Wie übertragen wird? Per NFS, per FTP, per SSH, per SMB/CIFS? Soll das ganze über eine WAN oder eine LAN Strecke gehen? Welche Bandbreite hast du zur verfügung?
Nun haben sich bei den Grundüberlegungen doch ein paar Fragen ergeben.
1. Komplette oder nur teilweise Sicherung?
Wenn es komplett ist gehe ich davon aus, dass wenn es einmal wieder eingespielt ist alles funktioniert, genau wie früher halt. Wenn ich nur Teile sichere wie läuft es dann ab beim Wiederherstellen? Grundsystem installieren und die Config Sachen alle wieder einspielen denk ich mir da spontan, aber geht das auch reibungslos? Und wie verhält sich das wenn geringfügige Änderungen an der Hardware vorgenommen wurden (z.B. neue Festplatte)?
Und ist es möglich bei laufendem System einfach komplette etc Ordner usw. zu ersetzen?
Prinzipiell hätte ich nämlich schon lieber eine komplette Sicherung, falls dies machbar ist.
Solange Bandbreite und Ziel der Datensicherung mitspielen sollte man immer voll sichern. Du hast noch zwei Varianten:
Inkrementell sichert nur das was sich gegenüber der letzten Sicherung geändert hat. Das hat den Vorteil das die einzelnen Backups sehr klein sind. Nachteil: Wenn du einen Restore machen willst, brauchst du das letzte Vollbackup plus alle _alle_ inkrementellen Sicherungen.
Differenziell sichert nur das was sich gegenüber der letzten Vollsicherung geändert hat. In dem Fall brauchst du bei einem Restore nur das letzte Vollbackup und ein differenzielles Backup.
das 2. Problem ist: In welcher Form sichern?
Mir fehlt da eine konkrete Vorstellung, kann man einfach den kompletten Datenbestand automatisch in ein Image packen lassen und dieses gepackt an den Backup Rechner schicken?
Oder gar ein riesiges Archiv ohne erst ein Image erstellt zu haben? Klingt irgendwie nach Stümperei, vielleicht kann mir jemand auf die Sprünge helfen was gängige Methoden sind, bzw. welche Software/Befehle man am besten einsetzt. Mir würde spontan bloß dd einfallen, was ich aber vermeiden möchte ;) Die Frage die sich mir dann stellt ist auch wie das ganze wieder eingespielt werden soll.
Du wirfst da ein paar Dinge durcheinander. Imagesicherungen kannst du mit partimage, Acronis Trueimage oder Symantec Ghost machen. Einige Datensicherungsprogramme können das auch. Für ein konsitentes Image musst du die Maschine herunterfahren und von einer Live-CD o.ä. starten. Acronis Trueimage erlaubt dir das erstellen von Images im laufenden Betrieb, kostet allerdings richtig Geld. Symantec Ghost kann das auch, aber nicht unter Linux.
Archivsicherungen kannst du mittels Tar erstellen. Schau einfach mal in die Manpage. Tar kann auch inkrementelle Sicherungen usw.
Dritte Möglichkeit wäre die Sicherung des Servers über einen Agent einer Backupsoftware. Wenn du an der Windows-Maschine ein Bandlaufwerk hast, und du hast dort eine Backup-Software die einen Agent für Linux-Systeme hat, dann kannst du die Kiste auch direkt auf Tape sichern. Macht aber nur bei einer breitbandigen (min. 2MB/s) Verbindung sinn.
3. (und letzte) Frage: Wie übertragen?
Gibt es da etwas worauf man achten sollte? Der Zielrechner wird aller Voraussicht nach ein Windowssystem haben, soll ich zur Übertragung FTP nutzen oder die Freigabe als Netzlaufwerk mounten, oder mit smbclient, oder...., ... ?
Ich würde in dem Fall FTP nutzen. Ist am einfachsten. Wenn es verschlüsselt sein soll, kannst du dir auch mal sFTP oder sCP ansehen.
baumgartner
30.06.06, 10:32
Inkrementell sichert nur das was sich gegenüber der letzten Sicherung geändert hat. Das hat den Vorteil das die einzelnen Backups sehr klein sind. Nachteil: Wenn du einen Restore machen willst, brauchst du das letzte Vollbackup plus alle _alle_ inkrementellen Sicherungen.
Differenziell sichert nur das was sich gegenüber der letzten Vollsicherung geändert hat. In dem Fall brauchst du bei einem Restore nur das letzte Vollbackup und ein differenzielles Backup.
Das wäre der Vorteil von rdiff-backup, hier ist der direkt verfügbare Stand immer der letzte der gesichert wurde und die alten Versionen sind die Deltas.
mfg Martin
Danke für die schnellen Antworten.
RAID != Backup. Magst du russisches Roulette?
Daher schrieb ich es in Anführungszeichen, ich kann nichts für das "Datensicherungskonzept" meines Vorgängers :)
Wie übertragen wird? Per NFS, per FTP, per SSH, per SMB/CIFS? Soll das ganze über eine WAN oder eine LAN Strecke gehen? Welche Bandbreite hast du zur verfügung?
Der Spaß geht mit 100MBit über LAN
Solange Bandbreite und Ziel der Datensicherung mitspielen sollte man immer voll sichern. Du hast noch zwei Varianten:
...
Ich denke es spricht dann nichts dagegen immer voll zu sichern, ich kann das Backup zu Zeiten machen wo die Netzlast quasi null ist und genug Festplattenplatz ist auch vorhanden.
Du wirfst da ein paar Dinge durcheinander. Imagesicherungen kannst du mit partimage, Acronis Trueimage oder Symantec Ghost machen. Einige Datensicherungsprogramme können das auch. Für ein konsitentes Image musst du die Maschine herunterfahren und von einer Live-CD o.ä. starten. Acronis Trueimage erlaubt dir das erstellen von Images im laufenden Betrieb, kostet allerdings richtig Geld. Symantec Ghost kann das auch, aber nicht unter Linux.
Ja, genau an dem Punkt habe ich mich auch gewundert, ich wollte ja ohne ein solches Programm auskommen. Es stimmt halt nicht alles was in Foren etc. steht, somit war ich dann doch etwas verwirrt ;)
Demzufolge kann ich Imagesicherung schonmal streichen.
Archivsicherungen kannst du mittels Tar erstellen. Schau einfach mal in die Manpage. Tar kann auch inkrementelle Sicherungen usw.
Darauf wird es hinauslaufen, die Sache mit dem Backup Agent wird für meine einfachen Zwecke zu kompliziert denke ich, außerdem ist kein Bandlaufwerk vorhanden, das Backup soll lediglich auf die Festplatte des andern Rechners.
Wenn ich eine Komplettsicherung wieder einspielen will bin ich dann aber auf irgendwelche Hilfsmittel (Knoppix, Startdiskette, .. ?) angewiesen oder übersehe ich da was? Wenn kein System auf dem Server mehr läuft kann er auch schlecht das Backup annehmen wenn ich es übers Netz übertrage oder nicht?
baumgartner
30.06.06, 12:02
Du hast meine beiden Beiträge gelesen?
Das erfüllt imho genau das was du brauchst...
Ja das habe ich selbstverständlich, aber was unterscheidet in dem Fall rsync von einem ganz normalen copy Befehl wenn ich die vielleicht blöde Frage stellen darf?
Ich habe damit auch schon herumprobiert, es fumktioniert auch teilweise, aber ich bekomme noch eine Reihe von Fehlermeldungen wie diese:
rsync: failed to set permissions on "/mnt/test/etc/ppp/peers": Operation not permitted (1)
Und was tu ich im Ernstfall mit meinem Backup um es wieder einzuspielen?
Der Server hat nur ein Diskettenlaufwerk, irgendwie muss ich ihm ja aber klarmachen das ich gerne was über FTP oder was auch immer übertragen möchte. Beim Ernstfall gehe ich davon aus das 2 völlig neue leere Platten im Server stecken und wenn es ein vollständiges Backup ist will ich es ja auch auf ne leere Platte aufspielen.
baumgartner
30.06.06, 12:46
Also, bislang dachte ich eher es geht dir um die Daten und nicht um das Gesamtsystem. Wenn du ein täglich ein komplettes Imagebackup über ein 100mbit Netzwerk machen willst, wirst du bei heutigen Plattenkapazitäten an ein zeitliches Problem stoßen.
Ein HOWTO gibts hier:
http://archiv.debianhowto.de/de/rdiff-backup/
Der unterschied zw. rsync und rdiff-backup ist, dass du bei rdiff-backup auch ältere Zustände wiederherstellen kannst.
Ich denke der OP muss sich selber eine andere Frage stellen: Was will ich scihern und was will ich damit erreichen. Ich vermute mittlerweile das der OP eine Art, oder eine Anleitung, für einen sog. "bare metal restore" sucht. Ich habe eine (völlig zerschossene) oder leeren Maschine und möchte mit meinem vorhandenen Backup auf Stand X zurück. Für sowas gibt es IMHO nur zwei wirklich brauchbare Verfahren:
- Backupsoftware samt Agent
- Imagesicherung über Partimage, Acronis oder Symantec Ghost
Backupsoftware + Agent setzt nicht zwangsläufig ein Tape voraus. Oft können die Programme auch auf Platten sichern. Eine Sicherung per TAR ist auch nicht ausgeschlossen. Wichtig ist halt das Archiv am Ende zu packen. Das Archiv an sich ist ja nur eine Ansammlung von Dateien, erst das komprimieren des Archivs verkleinert es. Ich weiß nicht wie sich Rsync oder rdiff für einen "bare metal restore" eignen.
baumgartner
02.07.06, 02:01
Denke auch, dass er in der Lage sein will sein System komplett zu sichern, darum hab ich oben auf die Zeiten bei 100mbit und image Sicherung angesprochen.
Was ich aber nicht verstehe, ist warum du das TAR Pakerl zippen willst. Wenn du beim gezippten dann nur einen einzigen Bytefehler hast, dann ist doch das ganze Archiv wertlos. :-/
mfg Martin
Wie oft hattest du das? Die Anzahl kann ich bei mir an beiden Händen abzählen. Bei einer Imagesicherung kann dir das auch passieren. Wenn er den Platz hat, braucht er ja nicht komrpimieren, aber i.d.R. macht man das um Platz zu sparen.
baumgartner
02.07.06, 12:30
Hast du auch recht:)
übrigens noch ein netter Artikel zum Thema "inkrementelles Backup" und "warum man Backups auch überprüfen sollte":
http://www.heise.de/newsticker/meldung/74978
Ob das Backup funktioniert hat, sieht man beim Restore. ;)
ja, das ist der Zeitpunkt, zu dem auch Admins religiös werden... :-)
baumgartner
03.07.06, 11:17
Das sind dann die Admins die mit einem Rosenkranz vor einem Terminal sitzen :ugly:
BedriddenTech
03.07.06, 13:10
Um mal zum Thema zurückzukommen -- wir fahren hier momentan auf zwei verschiedenen Backup-Schienen, bzw. -Ebenen.
Erste Ebene betrifft die Daten an sich. Der werden mittlerweile mittels ENBD auf drei Rechnern mit jeweils Spiegel-RAID geschrieben. Einer von den dreien macht jede Nacht ein Band-Backup.
Die zweite Ebene, das System an sich, besteht aus einer VMWare-Virtualmachine, die im Prinzip im Datenverzeichnis liegt und genauso mittels ENBD, RAID und Band gesichert wird. Das ganze ist ein differenzielles Backup, jeden Freitag schieben wir ein großes Band für ein Vollbackup 'rein; die differenziellen werden jede Woche neu geschrieben. Für das Vollbackup haben wir mittlerweile allerdings schon 6 Monate Historie. :)
Damit das alles nicht so lahm wird, sind die drei Geräte untereinander mit einem separaten 100MBit-Netzwerk verkabelt.
Ist das nicht nicht etwas aufwendig? Wie skaliert das System denn nach oben? Wäre eine VTL nicht einfacher? Aber ein interessanter Ansatz. Wieviele Gigabyte sichert ihr mit dem System?
BedriddenTech
03.07.06, 21:36
Der Aufwand hält sich eigentlich in Grenzen, weil man ja im Prinzip einfach nur Abends mal ein Band wechseln muß. Für den Bandroboter ist noch nicht genug Geld dagewesen. ;)
Wir sind eine Entwicklerfirma, d.h. das, was wir lagern, ist hauptsächlich Quelltext. Da reichen uns ~400GByte an maximalem Platz. Den haben wir bisher mit noch nicht mal 100GByte Rohdaten kaum ausgeschöpft. :) Nach oben zu skalieren hieße halt, zwei neue Platten einzusetzen, das ist zugegebenermaßen nicht ganz so bequem, ist aber bisher noch nicht vorgekommen. Kaputte Platten werden ja nur ersetzt. ;)
Was würdest du denn in Richtung VTL tun/vorschlagen?
Also Kombinationen aus Disk-Cache und Tape-Library / Auto-Loader, oder halt eine komplette VTL, gehen derzeit wie warmes Brot im Markt. Im einfachsten Fall würde ich vier große SATA Platten in den Server bauen (4x 250 GB als RAID 5) und dahiner ein LTO-2 oder LTO-3 (je nachdem wie lange die Lösung genutzt werden soll) hängen. In Verbindung mit HP DataProtector und der Advanced Backup-to-Disk Option eine hübsche kleine Lösung die wir mittlerweile auch oft bei kleinen Kunden einsetzen. Backups nachts auf die Platte und danach auf Band. Die Backups werden dann solange auf den Platten vorgehalten, wie Platz frei ist.
BedriddenTech
04.07.06, 12:20
Das wäre tatsächlich eine hübsche Erweiterung für unsere Anlage... Danke für die Anregung! :)
Erst einmal sorry für die späte Antwort, ich war leider verhindert.
Ich hatte gedacht, dass es eine halbwegs einfache Möglichkeit (ohne Zuziehung "richtiger" Backup-Software) der Sicherung des gesamten Systems gibt, aber wenn dem nicht so ist, dann muss es halt anders gehn, wäre nur schön bequem gewesen ;)
Wenn es lediglich um die Sicherung bestimmter Daten geht ist natülich alles soweit klar, Danke für die nette Hilfe und die Anregungen :)
Klingt vllt. blöd aber ich verwende Unison.
http://www.cis.upenn.edu/~bcpierce/unison/
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.