Backup-Unterbrechung führt zu defekten VMs.

[itNGO]

Hallo zusammen,
wir haben hier einen Kunden dessen PVE 7.4-3 mit einem externen PBS in unserem Rechenzentrum gesichert wird.
Das ganze geschieht über eine 400MBit Leitung und funktioniert auch wunderbar. Nun kam es während der Sicherung heute Nacht zu einer Unterbrechung der Internetleitung beim Kunden.

Neben der daraus resultierenden, zu erwartenden Meldung:
Jun 01 07:38:32 pve pvestatd[3051]: RZ-PBS_SSD: error fetching datastores - 500 Can't connect to *******:8007 (Connection timed out)
sind dann auch 2 lokale VMs ausgestiegen. Es handelt sich jeweils um Windows VMs. Der Backupjob ist auf "Snapshot" konfiguriert. Eine VM war so "beschädigt" das sie erst durch Chkdsk und Startup-Repair wieder vernünftig laufen wollte.

Nun die Frage: Soll das so sein, das eine Unterbrechung der Verbindung zum Backup-Server während des Backups die lokale VM "zerlegt"? Das wäre ja ein Fatales verhalten.

Mein empfinden würde meinen, das wenn der Snapshot erstellt und wieder comitted wurde, der lokalen VM/Storage eine Unterbrechung doch völlig egal sein müsste. Es wird ja aus dem SnapShot gesichert?

Vielleicht kann mich da jemand aufklären?

 

[dcsapak]

auf was für einem storage laufen die vms? ist vielleicht hatte das ganze netzwerk der kiste probleme und die verbindung zum storage war weg?

 

[itNGO]

auf was für einem storage laufen die vms? ist vielleicht hatte das ganze netzwerk der kiste probleme und die verbindung zum storage war weg?

Ist nen Hardware-Raid mit lokalen SSDs. Nein der Server lief durch, hängt an USV und hatte sonst auch nichts zu beanstanden.
Nur 2 von 5 Gästen haben sich unschön "hingelegt", als der Backup-Storage offline war.

 

[tom]

Hat der Hardware-Raid Controller eine BBU? Also ist der Cache des Controller geschützt?

Und haben die SSD eine power-loss protection?

 

[itNGO]

Hat der Hardware-Raid Controller eine BBU? Also ist der Cache des Controller geschützt?

Und haben die SSD eine power-loss protection?

Das ist ein Thomas-Krenn:
2HE AMD Single-CPU RA1208-AIEPN Server (V1.0)
- Supermicro Mainboard H12SSL-i
- 16x SATA-3 + 2x M.2 / 8x SATA-3 + 2x NVMe + 2x M.2 (Ohne RAID)
- 2x 1 Gbit/s on Board LAN (Broadcom BCM5720)
- Full Remote Management (KVM over LAN, IPMI 2.0)
- Trusted Platform Management Modul
- AMD EPYC 7302 (3,00 GHz, 16-Core, 128 MB)
- 64 GB (4x 16GB) ECC Reg ATP DDR4 3200 RAM (Premium)
- 2x 800 Watt redundantes Hot Swap Netzteil (80 plus Platinum) (ein Bein USV, ein Bein Netz an 2ter Phase)

Festplatten und RAID
Broadcom (LSI/Avago) MegaRAID 9560-8i SAS3 / NVMe 8x intern (Tri-Mode)

Laufwerke: 2x 1,92 TB SATA III Intel SSD 3D-NAND TLC 2,5" (D3-S4520) (VM-Speicher)
2x 120 GB ATP N600Sc mit PLP (M.2 PCIe x4 2280) (Proxmox-Install)
RAID-Level: RAID 1 (Boot ca. 100 GB)
RAID 1 (Daten ca. 1.800 GB)

 

[dcsapak]

grundsätzlich ist es so dass ein langsamer backup storage schon mal die laufende vm ausbremsen kann (da potentiell zuerst blöcke weggesichert werden müssen bevor die vm was drauf schreiben kann)
aber die daten auf der vm sollten nicht kaputt gehen

dass eine andere vm irgendwie betroffen ist (die gar nicht gebackupt wurde zu dem zeitpunkt) kann eig. nur passieren wenn das backup so schnell von der disk liest dass der drunter liegende storage ausgelastet ist (dagegen kann man ein bwlimit beim backup setzten)

wie sieht denn der backup task log aus?

 

[fabian]

Mein empfinden würde meinen, das wenn der Snapshot erstellt und wieder comitted wurde, der lokalen VM/Storage eine Unterbrechung doch völlig egal sein müsste. Es wird ja aus dem SnapShot gesichert?

nur der vollstaendigkeit halber - das trifft nur auf container zu. bei VMs hat der "snapshot" mode nichts mit snapshots im storage sinn zu tun. bei VMs wird in allen drei modi ein qemu-interner "copy-before-write" mechanismus genutzt, der unterschied ist lediglich wann dieser mechanismus in gang gesetzt wird und damit einhergehend, wie konsistenz sichergestellt wird.

sh. https://pve.proxmox.com/pve-docs/pve-admin-guide.html#_backup_modes

das copy-before-write funktioniert im prinzip so, dass writes vom gast von qemu abgefangen werden, die original daten vor dem write werden dann aufs backup gesichert, dann erst geht der write auf die VM disk durch (mit entsprechendem tracking und natuerlich auch backup von bloecken, die nicht vom gast geschrieben werden ). daher kann schlechte performance des backup targets auch die I/O performance des gasts beeintraechtigen, weil die gast writes dann entsprechend "stauen" waehrend der backup storage versucht die ueberschriebenen daten wegzuschreiben.

 

[itNGO]

Wir werden das erstmal weiter beobachten. Das Internet fällt beim Kunden zum Glück nicht andauern aus....

 

[Falk R.]

Deshalb mache ich über WAN immer nur BackupCopy / Sync. Habt ihr schon mal ein Restore über WAN getestet? Für DR habe ich immer gern ein paar Backups lokal und Langzeitbackup gern offsite.

P.S. Das Primäre Backup kann auch gern ein PBS als VM sein.

 

[itNGO]

Deshalb mache ich über WAN immer nur BackupCopy / Sync. Habt ihr schon mal ein Restore über WAN getestet? Für DR habe ich immer gern ein paar Backups lokal und Langzeitbackup gern offsite.

P.S. Das Primäre Backup kann auch gern ein PBS als VM sein.

Ist ne Migration von HyperV. Der Kunde hat noch nen durchgereichtes RDX mit VEEAM. Das Backup2Datacenter PBS ist nur nen "benefit" während der Migration. Daher auch nicht so "priorisiert" in der Fehlersuche....

 

[Falk R.]

Ist ne Migration von HyperV. Der Kunde hat noch nen durchgereichtes RDX mit VEEAM. Das Backup2Datacenter PBS ist nur nen "benefit" während der Migration. Daher auch nicht so "priorisiert" in der Fehlersuche....

Du kannst ja nix dafür, aber bei Veeam mit RDX bekomme ich auch die Krise. Mit RDX machst du dir gleich einige Features Kaputt, so ähnlich wie PBS auf Hetzner Storagebox.

Interessant wäre trotzdem ob eine BBU für den Controller verbaut ist. Kannst du ja mal eben per megacli abfragen. Eigentlich dürfte es maximal extrem langsam werden, aber defekte Daten sollten in dem Setup nicht entstehen.
Von der Logik her kannst du eigentlich nur defekte Daten bekommen, wenn der Diskcache an ist, bei Disks im Raid.

 

[mow]

Interessant wäre trotzdem ob eine BBU für den Controller verbaut ist.

Du meinst, weil der sonst den FBWC nicht einschalten will?

Von der Logik her kannst du eigentlich nur defekte Daten bekommen, wenn der Diskcache an ist, bei Disks im Raid.

Sollte bei diesen eigentlich nichts ausmachen, die haben ja PLP.
Aber auch dann muß erstmal der Strom ausfallen, damit das überhaupt zu einer Inkonsistenz führen kann.

 

[Falk R.]

Die PLP bringt da manchmal nix, aber ein anderes Thema.
Ich habe mir das noch etwas durch den Kopf gehen lassen.
Ich glaube wir sind auf der falschen Fährte.

Was sagt denn das Eventlog der beiden VMs? Ich kann mir gut vorstellen, dass die intern auf den 60s Timeout bei den Disks gelaufen sind. Das beste ist dann immer, die VM sofort ausschalten ohne Shutdownversuch. Wenn Windows Disk I/Os droppt weil das Storage über 60s Latenz hat, schreibt Windows dann Inkonsistente Daten wenn die VM weiter läuft. Sowas habe ich schon bei IBM SVC Failover gesehen wenn das Backend Storage zu klein gesized war.