Defekte QCow2-Platten

[LnxBil]

Der Teil im Log zeigt, dass der SATA Link zurück gesetzt wird und damit werden alle I/Os für den Zeitraum blockiert. Wenn ich das richtig sehe, dann passt der Zeitpunkt mit dem Beginn des Backups zusammen. Wie sieht die Storage (local) Last auf dem System aus? Oder gibt es auch am Host hinweise, auf eine langsame Disk?

Ähnliches hatten wir sporadisch auch beim Backup, ist aktuell (also nach einigen Updates) aber nicht mehr aufgetreten. Wir haben das nicht weiter verfolgt, da es ca. 1 mal pro 250 Backups aufgetaucht ist.

 

[Panter Datentechnik GmbH]

Hallo,
wir haben immer alle Updates im Release-Zweig gemacht. Brachte nie eine Besserung.
Es sind 2 Platten die beide auf dem gleichen lokalen Raid5 liegen, und immer nur wird die Daten-Platte zerstört.


Da wir eine Oracle-Partition sichern, führen wir das Backup wegen der Datenkonsistenz im Modus STOP aus.
Dabei sollte doch die VM runterfahren, gesichert werden und wieder hochfahren. Dies braucht nach meinem Verständnis für 200GB eine Zeit > 0.
Allerdings kann man im dmesg-Protokoll sehen, dass zu/ab dem Zeitpunkt des Backups (22:30) Einträge im Client geschrieben werden. D.h. es gibt quasi keine Downtime.

Das sollte doch gar nicht sein, oder?

Ich habe nochmal die dmesg- Ausgabe von heute angehängt. Vielleicht kann jemand ein Problem erkennen.


Grüße
Manfred

 

[tom]

Dabei sollte doch die VM runterfahren, gesichert werden und wieder hochfahren. Dies braucht nach meinem Verständnis für 200GB eine Zeit > 0.
Allerdings kann man im dmesg-Protokoll sehen, dass zu/ab dem Zeitpunkt des Backups (22:30) Einträge im Client geschrieben werden. D.h. es gibt quasi keine Downtime.
Das sollte doch gar nicht sein, oder?

Im "Stop" Modus wird die VM runtergefahren und sofort wieder hochgefahren und das vzdump backup beginnt. D.h. die downtime ist nur solange wie die VM zum rebooten braucht.

 

[LnxBil]

Warum er solche Probleme hat kann ich nicht sagen. Macht doch einfach ein richtiges online Backup der Oracle Datenbank mittels RMAN und ihr könnt die VM oben lassen. Es ist absoluter quatsch eine Datenbank herunterzufahren für ein Backup, mal ganz abgesehen von den Performance-Einbußen, die ihr dann habt bei einer "kalten" Datenbank.

 

[Panter Datentechnik GmbH]

Hallo,
das Problem ist nicht das Backup und die Performance der Oracle Datenbank. Das stimmt zwar alles mit der Oracle, ist aber nicht von Relevanz, weil ja nicht die Oracle das Problem ist.
Sondern das Problem ist, daß die Platte sich einfach ins Nirvana verabschiedet - und zwar regelmäßig. Die Oracle funktioniert tadellos, auch nach dem Backup. Und nochmal, die Platte verabschiedet sich irgendwann *nach* dem Backup, da das Backup in der Nacht ja - glücklicherweise - korrekt läuft. Und sie ist irreparabel.
Gibt es denn keinen Hinweis? Irgend eine Konfiguration die man nicht machen sollte, z.B. keine Raw-Platten auf einem Raid5 mit SSDs ??

Grüße
Manfred

 

[tom]

Was ist das genau für ein Raid5?

Im dmesg sind auch fehler ?:

[Jan23 22:35] EXT4-fs (sdb1): error count since last fsck: 7
[  +0,000006] EXT4-fs (sdb1): initial error at time 1514929088: ext4_journal_check_start:56
[  +0,000003] EXT4-fs (sdb1): last error at time 1514949002: ext4_put_super:788
[Jan23 22:40] ata5.00: exception Emask 0x0 SAct 0x8000000 SErr 0x0 action 0x6 frozen
[  +0,000004] ata5.00: failed command: WRITE FPDMA QUEUED
[  +0,000002] ata5.00: cmd 61/30:d8:78:49:c4/00:00:09:00:00/40 tag 27 ncq 24576 out
         res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
[  +0,000001] ata5.00: status: { DRDY }
[  +0,000005] ata5: hard resetting link
[  +3,291033] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[  +0,000252] ata5.00: configured for UDMA/100
[  +0,000003] ata5.00: device reported invalid CHS sector 0
[  +0,000006] ata5: EH complete