11
Centos Server im laufenden Betrieb komplett sichern
Moin zusammen,
ich habe grad ein schwerwiegendes Problem mit einem "meiner" Server. Seit heute morgen wirft er weniger lustige Fehlermeldungen.
smartd[4784]: Device: /dev/sda, FAILED SMART self-check. BACK UP DATA NOW!
smartd[4784]: Device: /dev/sda, SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 47 to 45
smartd[4784]: Device: /dev/sda, SMART Usage Attribute: 188 Unknown_Attribute changed from 100 to 99
smartd[4784]: Device: /dev/sda, FAILED SMART self-check. BACK UP DATA NOW!
smartd[4784]: Device: /dev/sda, SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 45 to 43
smartd[4784]: Device: /dev/sda, SMART Usage Attribute: 188 Unknown_Attribute changed from 99 to 100
smartd[4784]: Device: /dev/sda, SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 71 to 70
smartd[4784]: Device: /dev/sda, starting scheduled Offline Immediate Test.
Wenn ich das richtig sehe ist die Platte kurz vor dem K.O. und ich sollte eine neue einbauen. Im Normalfall würde ich den Server ausmachen die Platte auf eine neue Clonen und die Platten tauschen. Server an Problem gelöst. Das geht hier leider nicht, ich kann den Server nicht vom netzt nehmen.
Gibt es eine Möglichkeit die Platte zu klonen und in eine File abzulegen die ich später so wieder auf einen neue Festplatte schreiben kann? Wie wenn man mit z.b. Clonezilla zwei Platten klont, nur das ich eine Platte in ein File schreiben will oder in einen Ordner irgendwo auf einem anderen Server. Der Kaputte Server hat grad mal 20GB belegt, sollte also zum einen nicht lange dauern und zum anderen auch keine Platzproblem sein.
Viele Grüße
Maveric
ich habe grad ein schwerwiegendes Problem mit einem "meiner" Server. Seit heute morgen wirft er weniger lustige Fehlermeldungen.
smartd[4784]: Device: /dev/sda, FAILED SMART self-check. BACK UP DATA NOW!
smartd[4784]: Device: /dev/sda, SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 47 to 45
smartd[4784]: Device: /dev/sda, SMART Usage Attribute: 188 Unknown_Attribute changed from 100 to 99
smartd[4784]: Device: /dev/sda, FAILED SMART self-check. BACK UP DATA NOW!
smartd[4784]: Device: /dev/sda, SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 45 to 43
smartd[4784]: Device: /dev/sda, SMART Usage Attribute: 188 Unknown_Attribute changed from 99 to 100
smartd[4784]: Device: /dev/sda, SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 71 to 70
smartd[4784]: Device: /dev/sda, starting scheduled Offline Immediate Test.
Wenn ich das richtig sehe ist die Platte kurz vor dem K.O. und ich sollte eine neue einbauen. Im Normalfall würde ich den Server ausmachen die Platte auf eine neue Clonen und die Platten tauschen. Server an Problem gelöst. Das geht hier leider nicht, ich kann den Server nicht vom netzt nehmen.
Gibt es eine Möglichkeit die Platte zu klonen und in eine File abzulegen die ich später so wieder auf einen neue Festplatte schreiben kann? Wie wenn man mit z.b. Clonezilla zwei Platten klont, nur das ich eine Platte in ein File schreiben will oder in einen Ordner irgendwo auf einem anderen Server. Der Kaputte Server hat grad mal 20GB belegt, sollte also zum einen nicht lange dauern und zum anderen auch keine Platzproblem sein.
Viele Grüße
Maveric
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 207197
Url: https://administrator.de/forum/centos-server-im-laufenden-betrieb-komplett-sichern-207197.html
Ausgedruckt am: 23.12.2024 um 10:12 Uhr
11 Kommentare
Neuester Kommentar
Hi,
Kannst du noch die Partition, Dateisysteme und mountpoints von sda bekanntgeben?
Je nachdem was da wie gemountet ist ändert sich die Backupstrategie beträchtlich.
mfg
Ctlhuhu
Kannst du noch die Partition, Dateisysteme und mountpoints von sda bekanntgeben?
Je nachdem was da wie gemountet ist ändert sich die Backupstrategie beträchtlich.
mfg
Ctlhuhu
Platte /dev/sda: 250.0 GByte, 250000000000 Byte
255 heads, 63 sectors/track, 30394 cylinders
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Gerät boot. Anfang Ende Blöcke Id System
/dev/sda1 * 1 29374 235946623+ 83 Linux
/dev/sda2 29375 30394 8193150 82 Linux Swap / Solaris
/dev/sda1 218G 12G 196G 6% /
tmpfs 3,9G 0 3,9G 0% /dev/shm
.. weitere externe Laufwerke von anderen Servern
/dev/sda1: Linux rev 1.0 ext3 filesystem data (needs journal recovery) (large files)
255 heads, 63 sectors/track, 30394 cylinders
Einheiten = Zylinder von 16065 × 512 = 8225280 Bytes
Gerät boot. Anfang Ende Blöcke Id System
/dev/sda1 * 1 29374 235946623+ 83 Linux
/dev/sda2 29375 30394 8193150 82 Linux Swap / Solaris
/dev/sda1 218G 12G 196G 6% /
tmpfs 3,9G 0 3,9G 0% /dev/shm
.. weitere externe Laufwerke von anderen Servern
/dev/sda1: Linux rev 1.0 ext3 filesystem data (needs journal recovery) (large files)
servus,
hast Du es schon mit dem "dd" Tool probiert? Aber vorsichtig bei der Benutzung man kann auch alles kaputt machen!
z.B: dd if=/dev/hdb of=/pfad/wo/das/Image/hin/soll/hdb-Image.img
obwohl wenn die Platte defekte Sektoren aufweist, dann eher "ddrescue".
hast Du es schon mit dem "dd" Tool probiert? Aber vorsichtig bei der Benutzung man kann auch alles kaputt machen!
z.B: dd if=/dev/hdb of=/pfad/wo/das/Image/hin/soll/hdb-Image.img
obwohl wenn die Platte defekte Sektoren aufweist, dann eher "ddrescue".
Nein noch nicht probiert. Ich werde es mir gleich mal anschauen und ggf. in einer V-Maschine vorher testen. Danke für den Tipp, wenn du mir noch sagen kannst was ich beachten sollte wäre das super.
Bei deiner Konfiguration würde meine Wahl auch auf dd_resuce fallen.
Du solltest aber das root-Dateisystem vorher im read-only-mode mounten. Gegebenfalls muss du ein paar daemons anhalten die z.B. logfiles schreiben wollen. Oder du mountest ein anderes Dateisystem (gegebenfalls eine Ramdisk, wenn sonst grad nix da ist) auf /var bzw. /tmp um zu verhindern, dass deine daemons außer Tritt kommen.
Mit einem Backup einer EXT-Partition welche 1) RW-gemountet und 2) ein nicht gecleantes journal aufweist, wirst du aber vermutlich Probleme beim Rücksichern haben. Stell dich also darauf ein, dass nicht alles 1:1 kopiert werden kann.
Du solltest aber das root-Dateisystem vorher im read-only-mode mounten. Gegebenfalls muss du ein paar daemons anhalten die z.B. logfiles schreiben wollen. Oder du mountest ein anderes Dateisystem (gegebenfalls eine Ramdisk, wenn sonst grad nix da ist) auf /var bzw. /tmp um zu verhindern, dass deine daemons außer Tritt kommen.
Mit einem Backup einer EXT-Partition welche 1) RW-gemountet und 2) ein nicht gecleantes journal aufweist, wirst du aber vermutlich Probleme beim Rücksichern haben. Stell dich also darauf ein, dass nicht alles 1:1 kopiert werden kann.
in deinem Fall solltest du auf ddrescue zurück greifen.
ddrescue -r0 -v -d -n /dev/sda /dev/sdb/image.iso /dev/sdb/rescue.log
man erklärung: (ansonsten Man Page lesen)
-r0 = max-retries= exit after given retries (-1=infinity)
-v = Verbose
-d = direct use direct disc access for input file
-n = no-split do not try to split error areas
/dev/sda = Quell Laufwerk
/dev/sdb = Ziel Laufwerk
/mnt/usbstick/rescue.log = logs da man unter ddrescue die möglichkeit hat mehrmals das tool durchlaufen zu lassen, ddrescue greift dann auf die log zurück.
ach ja der Packetname lautet ddrescue und nicht dd_rescue!
ddrescue -r0 -v -d -n /dev/sda /dev/sdb/image.iso /dev/sdb/rescue.log
man erklärung: (ansonsten Man Page lesen)
-r0 = max-retries= exit after given retries (-1=infinity)
-v = Verbose
-d = direct use direct disc access for input file
-n = no-split do not try to split error areas
/dev/sda = Quell Laufwerk
/dev/sdb = Ziel Laufwerk
/mnt/usbstick/rescue.log = logs da man unter ddrescue die möglichkeit hat mehrmals das tool durchlaufen zu lassen, ddrescue greift dann auf die log zurück.
ach ja der Packetname lautet ddrescue und nicht dd_rescue!
moin,
Ich da ganz verwegen ein "overlay" über root drüberlegen und per copy-on-write alles ins overlay migrieren lassen. (Stichwort: unionFS).
Dann hast Du erstmal Deine daten in einem filesystem wo Du dirkt zugriff drauf hast.
ddrescue sichert Dir zwar das device, aber solange das Ding noch Produktiv läuft, werden da inkonsistenzen im Filesystem sein, die Du damit nciht abgefangen bekommst. dd/ddrescue sind nur im offline-betrieb oder mit filesystemen sinnvoll, die einen snapshot erlauben.
Andererseits ist einddrescue-image von einem laufenden System immer noch besser als gar nichts.
Also mein Vorschlag:
Aber das sinnvolste wäre:
Du solltest Dir genau überlegen, was mehr kostet: jetzt die Kiste ausschalten oder der gleiche Ausfall, wenn die Kiste ganz abkackt.
lks
Ich da ganz verwegen ein "overlay" über root drüberlegen und per copy-on-write alles ins overlay migrieren lassen. (Stichwort: unionFS).
Dann hast Du erstmal Deine daten in einem filesystem wo Du dirkt zugriff drauf hast.
ddrescue sichert Dir zwar das device, aber solange das Ding noch Produktiv läuft, werden da inkonsistenzen im Filesystem sein, die Du damit nciht abgefangen bekommst. dd/ddrescue sind nur im offline-betrieb oder mit filesystemen sinnvoll, die einen snapshot erlauben.
Andererseits ist einddrescue-image von einem laufenden System immer noch besser als gar nichts.
Also mein Vorschlag:
- mit rsync erstmal das root-fs auf ein externes medium sichern.
- danach mit unionfs (o.a.) ein overlay auf / legen.
- Alle Dateien auf das overlay "kopieren"
- danach den inhalt des overlays auf eine neue Platte kopieren. udn einbauen.
Aber das sinnvolste wäre:
- Kiste aus
- Platte sichern
- neue Platte rein
- neustart
Du solltest Dir genau überlegen, was mehr kostet: jetzt die Kiste ausschalten oder der gleiche Ausfall, wenn die Kiste ganz abkackt.
lks
Zitat von @111857:
ach ja der Packetname lautet ddrescue und nicht dd_rescue!
ach ja der Packetname lautet ddrescue und nicht dd_rescue!
besser ddrescue (=gddrescue) nehmen, das eine weiterentwicklung von dd_rescue ist. das ist für defekte Platten meist besser geeignet, weil es zuerst die funktionierenden sektoren kopiert, bevor es sich an die problematischen macht.
lks
Perfekt Mädels und allerbesten Dank. Ich werde mich gleich ran machen und eure Vorschläge als Stütze nehmen. Geht doch nix über ein wenig Erfahrung unter gleichgesinnten. Ich werde mich die Tage hier noch einmal zu Wort melden wie ich es zu letzt komplett gelöst habe, damit wir alle was davon haben.
In diesem Sinne "You made my day!"
Viele Grüße
Maveric
In diesem Sinne "You made my day!"
Viele Grüße
Maveric
Die angewandte Lösung war jetzt folgende:
1. Wartungsarbeiten einleiten
2. Server herunterfahren
3. Platte spiegeln
4. Neue Platte rein und betrieb wieder aufnehmen
Das Spiegeln hat aufgrund der enormen Fehlermenge ca. 1 Std. gedauert, nicht schön aber selten.
Ich hatte zwar geschrieben das der Server nicht vom Netz genommen werden kann, aber hey
wenn er sich selber vom Netz nimmt, hat man das Problem nicht mehr XD.
@Lochkartenstanzer, der Ansatz mit deinem Kopiertool war schon sehr gut und ich hatte 97% nur dann
ist der Server leider abgesegelt. Arbeiten und kopieren war nicht mehr drin.
Jetzt hat der Server übrigens ein Raid 5 mit 3 Platten, ich konnte komischerweise jetzt wo wir ein wenig
Downtime hatten ohne viel gegen die Wand gerede ohne Probleme Geld für etwas mehr Sicherheiten
einstreichen :D
1. Wartungsarbeiten einleiten
2. Server herunterfahren
3. Platte spiegeln
4. Neue Platte rein und betrieb wieder aufnehmen
Das Spiegeln hat aufgrund der enormen Fehlermenge ca. 1 Std. gedauert, nicht schön aber selten.
Ich hatte zwar geschrieben das der Server nicht vom Netz genommen werden kann, aber hey
wenn er sich selber vom Netz nimmt, hat man das Problem nicht mehr XD.
@Lochkartenstanzer, der Ansatz mit deinem Kopiertool war schon sehr gut und ich hatte 97% nur dann
ist der Server leider abgesegelt. Arbeiten und kopieren war nicht mehr drin.
Jetzt hat der Server übrigens ein Raid 5 mit 3 Platten, ich konnte komischerweise jetzt wo wir ein wenig
Downtime hatten ohne viel gegen die Wand gerede ohne Probleme Geld für etwas mehr Sicherheiten
einstreichen :D
Zitat von @Maveric:
Jetzt hat der Server übrigens ein Raid 5 mit 3 Platten, ich konnte komischerweise jetzt wo wir ein wenig
Downtime hatten ohne viel gegen die Wand gerede ohne Probleme Geld für etwas mehr Sicherheiten
einstreichen :D
Jetzt hat der Server übrigens ein Raid 5 mit 3 Platten, ich konnte komischerweise jetzt wo wir ein wenig
Downtime hatten ohne viel gegen die Wand gerede ohne Probleme Geld für etwas mehr Sicherheiten
einstreichen :D
Ist RAID5 mit 3 Platten nicht zu langsam? Nicht lieber RAID1 mit hot-spare?
Aber ansonsten, die besten Chancen etwas zu verbessern hat man immer dann, wenn es gerade heftig wehgetan hat, sagt meien Erfahrung.
lks
