Backups auf CIFS Freigabe Sorgen für hänger

[superwinni2]

Hallo zusammen

ich habe hier zwei ProxMox VE Server (pmfw1 und pmfw2) auf Version 8.2.3. Beide zeigen sporadisch den gleichen Fehler:
Auf ProxMox laufen 2 VMs. Beides sind OPNsense Firewalls. (Falls das von belangen ist)
PMFW1:
VM 100 -> FW1
VM 111 -> FWInternBackup

PMFW2:
VM 101 -> FW2
VM 110 -> FWIntern

Ich habe bisher (die letzten Jahre) immer auf ein SMB/CIFS Storage (seperater WIndows Server 2016) Backups gemacht. Lief immer problemlos.
Nun habe ich den Windows Server von 2016 auf 2022 geupdated.
Der Backupjob vom PMFW2 läuft (aktuell) ohne Probleme. Beim PMFW1 gibt es Probleme.

Wenn ich nun ein Backup mache so bleibt sporadisch alles so "halber" hängen...
Was meine ich mit "halber"?:

• ProxMox selbst ist via WebGUI nicht mehr erreichbar. Ich komme noch auf die Loginseite, nach dem eingeben und absenden der Logindaten geht es jedoch nicht mehr weiter. Es kommt nach einiger Zeit die Meldung: "Anmeldung fehlgeschlagen. Bitte versuchen Sie es noch einmal." Anmeldedaten sind natürlich korrekt.
• Ich komme nicht mehr via SSH auf den Proxmox. Die Verbidnugn an sich wird aufgebaut aber nach:
  

  Using username "root".
  Authenticating with public key "PublicKey" from agent

  geht es nicht mehr weiter. Irgendwann kommt vom Putty die Fehlermeldung:
  

  Network error: Network error: Software caused connection abort

• Die OPNsense "FW1" (an welcher das aktuelle Backup durchgeführt wird) ist ebenfalls nicht mehr erreichbar. Komme ebenfalls nicht mehr auf die WebGUI oder via SSH drauf. Filtern, routen, VPN und alles was sie sonst so tut geht jedoch noch.?
• Die OPNsense "FWInternBackup" funktioniert ganz normal. Der Backup Prozess ist ja noch immer an der FW1 dran.

Was mache ich damit es aktuell wieder läuft:

• Server hart ausschalten und wieder einschalten.
• Alternativ: SMB Server neustarten oder ausschalten. Sobald der Share nicht mehr da ist, ist alles für einen kurzen Moment (wenige Minuten) gut bis es dann wieder von vorne anfängt. In der zeit in der man auf das GUI kommt veruchen den BackupJob zu stoppen und nachträglich die VM via "qm unlock 100" freischalten.
  • In der Log steht dann folgendes:
    

    INFO: starting new backup job: vzdump 100 110 --mode snapshot --mailnotification failure --mailto patrick.winter@aww.de --storage Backup-pmfw1 --quiet 1 --compress zstd --fleecing 0INFO: Starting Backup of VM 100 (qemu)
    INFO: Backup started at 2024-08-09 21:00:02
    INFO: status = running
    INFO: VM Name: FW1
    INFO: include disk 'virtio0' 'local-lvm:vm-100-disk-0' 50G
    INFO: backup mode: snapshot
    INFO: ionice priority: 7
    INFO: creating vzdump archive '/mnt/pve/Backup-pmfw1/dump/vzdump-qemu-100-2024_08_09-21_00_02.vma.zst'
    INFO: started backup task '8c68f18c-d449-4f31-b5d8-d393cf832067'
    INFO: resuming VM again
    INFO:   0% (496.6 MiB of 50.0 GiB) in 3s, read: 165.5 MiB/s, write: 91.4 MiB/s
    INFO:   1% (996.9 MiB of 50.0 GiB) in 6s, read: 166.8 MiB/s, write: 160.2 MiB/s
    INFO:   3% (1.5 GiB of 50.0 GiB) in 9s, read: 180.0 MiB/s, write: 173.3 MiB/s
    INFO:   4% (2.1 GiB of 50.0 GiB) in 12s, read: 200.6 MiB/s, write: 194.0 MiB/s
    INFO:   5% (2.5 GiB of 50.0 GiB) in 16s, read: 116.0 MiB/s, write: 115.9 MiB/s
    INFO:   6% (3.1 GiB of 50.0 GiB) in 21s, read: 113.8 MiB/s, write: 109.4 MiB/s
    INFO:   7% (3.6 GiB of 50.0 GiB) in 25s, read: 124.2 MiB/s, write: 119.2 MiB/s
    INFO:   8% (4.0 GiB of 50.0 GiB) in 29s, read: 113.3 MiB/s, write: 108.4 MiB/s
    INFO:   9% (4.6 GiB of 50.0 GiB) in 32s, read: 204.2 MiB/s, write: 197.6 MiB/s
    INFO:  10% (5.0 GiB of 50.0 GiB) in 35s, read: 141.4 MiB/s, write: 141.4 MiB/s

Zusätzliche Info:

• Der Traffic zwischen Client, Proxmox und OPNsense wird NICHT über die OPNsense oder irgendwas anderes geroutet oder gefiltert. Die IPs welche ich anspreche befinden sich alle im gleichen (Broadcast) Netzwerk.
• Anfangs hatte ich vermutet, dass es am Kernel liegt. Dann habe ich diesen auf 6.8.8-4-pve geupdated und es wurde auch besser. Leider fängt es nun erneut von vorne an.
• Die Ausgabe des journalctl ab dem zeitpunkt des Backups habe ich mal angehängt. (Zu viel Text um es als Spoiler oder so zu machen)
• Am Windows Server kann ich keine Fehler erkennen. (Der andere ProxMox kann ja alles sauber machen)
• Die Backup Jobs laufen Zeitlich mehrere Stunden versetzt.

Hat jemand eine Idee oder einen Tipp was schief läuft? Liegt es am Windows Server? Ist es eine blöde Kombination aus beidem?

Danke schonmals!
Viele Grüße

 

[superwinni2]

Push?

 

[Falk R.]

HI, in dem Log steht doch alles Wichtige. Storage Stuck bedeutet, das Storage ist busy und nimmt nix an. Wenn das Backupstorage langsam ist, hängt natürlich die VM, das ist der Architektur geschuldet wie die Snapshot Backups gemacht werden.
Guck mal wie schnell du andere Daten auf den Share kopieren kannst.

 

[superwinni2]

Hallo Falk

danke für die Antwort.
Das Zielstorage ist ein Windows Server 2022 welcher selbst auf SSDs basiert und die Freigabe (Laufwerk F: ) ist eine 12 Bay QNAP NAS welche via iSCSI mit 10 GBit/s angebunden ist. Die NAS ist die selbe wie beim Windows 2016 Server.
Diese hat absolute Langeweile. Wirklich 0 % Auslastung. Ist ausschließlich für Backups da. Dabei laufen keine Jobs zeitgleich. Andere Computer und Geräte sind in der Lage auf den Share zuzugreifen und auch mit mehr oder weniger vollem Speed (~ 700 MByte/s bzw. 6GBit/s ) Daten zu schreiben.

Habe es auch bereits mit einem anderen frischem Server 2022 mit anderer Storage (noch viel viel viel Performanter) getestet. Gleiche Situation.

 

[Falk R.]

Mach mal eine NFS freigabe auf dem Windows Server. Das sollte besser performen.
Außerdem, würde ich in der Größenordnung keine VZDump Backups machen sondern einen PBS nutzen.

 

[superwinni2]

Eigentlich möchte ich kein NFS machen...
Werde es trotz allem versuchen. Da dies aber ja ein ganz anderes Protokoll ist vermute ich, dass es keinerlei Probleme verursachen wird.

Backups haben ja bisher (über 3 Jahre) immer problemlos funktioniert. Daher wundert es mich eher, dass es auf einmal auf einem WinServer 2022 nicht mehr geht?

Ja PBS ist schön und toll, aber leider bekomme ich das nicht sauber in die bestehende Veeam Struktur hinein. Hoffentlich kommt da das groß erhoffte Update von Veeam auch Proxmox VE zu unterstützen.

 

[Falk R.]

Eigentlich möchte ich kein NFS machen...
Werde es trotz allem versuchen. Da dies aber ja ein ganz anderes Protokoll ist vermute ich, dass es keinerlei Probleme verursachen wird.

Falls der Server ein Veeam Backup Server ist, kannst du kein NFS zur Verfügung stellen, da sonst der vPowerNFS von Veeam streikt.

Backups haben ja bisher (über 3 Jahre) immer problemlos funktioniert. Daher wundert es mich eher, dass es auf einmal auf einem WinServer 2022 nicht mehr geht?

Bei Server 2022 wird SMB3 erzwungen und wenn möglich versucht der auch immer eine verschlüsselte Verbindung zu erzwingen. Wie gut der SMB Stack im Linux mit der Verschlüsselung performt, weiß ich nicht.

Ja PBS ist schön und toll, aber leider bekomme ich das nicht sauber in die bestehende Veeam Struktur hinein. Hoffentlich kommt da das groß erhoffte Update von Veeam auch Proxmox VE zu unterstützen.

Da erwarte bitte nicht zu viel. Die erste version, die demnächst veröffentlicht wird, ist noch sehr rudimentär. Backups nur im HotAdd mode, kein Application Aware und beim Restore geht kein Live Restore sondern nur Full oder Application Restore. Auf die Performance bin ich auch mal gespannt. Im Lab OK, aber wenn es skalieren muss, werden wir es sehen.

Wenn du jetzt VZDumps machst und die dann "Dumm" mit Veeam wegsicherst, hast du ja auch nicht viel gewonnen. Ich habe auch Setups mit einem virtuellen PBS auf einem HyperV, der dann mit Veeam noch einmal auf das Secondary Repository gesichert wird. Auch nicht schön, aber Compliance eingehalten.

 

[superwinni2]

Falls der Server ein Veeam Backup Server ist, kannst du kein NFS zur Verfügung stellen, da sonst der vPowerNFS von Veeam streikt.

Oh danke für den entscheidenden Tipp. Jops ist auch ein Veeam Backup Server. Dann fliegt hier wohl NFS flach.

Bei Server 2022 wird SMB3 erzwungen und wenn möglich versucht der auch immer eine verschlüsselte Verbindung zu erzwingen. Wie gut der SMB Stack im Linux mit der Verschlüsselung performt, weiß ich nicht.

Hatte die SMB Verschlüsselung ebenfalls schon im Verdacht. Bin mich auch aktuell am einlesen ob und wie weit ich das sinnvoll rückgängig machen könnte.

Da erwarte bitte nicht zu viel. Die erste version, die demnächst veröffentlicht wird, ist noch sehr rudimentär. Backups nur im HotAdd mode, kein Application Aware und beim Restore geht kein Live Restore sondern nur Full oder Application Restore. Auf die Performance bin ich auch mal gespannt. Im Lab OK, aber wenn es skalieren muss, werden wir es sehen.

Wenn du jetzt VZDumps machst und die dann "Dumm" mit Veeam wegsicherst, hast du ja auch nicht viel gewonnen. Ich habe auch Setups mit einem virtuellen PBS auf einem HyperV, der dann mit Veeam noch einmal auf das Secondary Repository gesichert wird. Auch nicht schön, aber Compliance eingehalten.

Ich erwarte nur, dass ich das irgendwie weggesichert bekomme. Bissel Hochverfügbare Firewall, Monitoring und Storage Quorum.
Bei aktuell 3 ProxMox Servern mit jeweils 2 VMs bin ich daher entspannt wenn es auch etwas länger dauern möge.

Ich möchte mir den PBS sparen, da ich bei einem Emergency Recovery dann erst den Backup Server, nen ESXi und dann die PBS VM und Proxmox VE hochziehen muss. Wenn ich nur die VZDump Datei sichere so brauch ich nur Backup Server und Proxmox VE. Die Datei bekommt man dann schon irgendwie via USB Stick oder Netzwerkfreigabe zum Proxmox VE.

 

[Falk R.]

Oh danke für den entscheidenden Tipp. Jops ist auch ein Veeam Backup Server. Dann fliegt hier wohl NFS flach.

Hatte die SMB Verschlüsselung ebenfalls schon im Verdacht. Bin mich auch aktuell am einlesen ob und wie weit ich das sinnvoll rückgängig machen könnte.

Ich erwarte nur, dass ich das irgendwie weggesichert bekomme. Bissel Hochverfügbare Firewall, Monitoring und Storage Quorum.
Bei aktuell 3 ProxMox Servern mit jeweils 2 VMs bin ich daher entspannt wenn es auch etwas länger dauern möge.

Ich möchte mir den PBS sparen, da ich bei einem Emergency Recovery dann erst den Backup Server, nen ESXi und dann die PBS VM und Proxmox VE hochziehen muss. Wenn ich nur die VZDump Datei sichere so brauch ich nur Backup Server und Proxmox VE. Die Datei bekommt man dann schon irgendwie via USB Stick oder Netzwerkfreigabe zum Proxmox VE.

Gerade beim DR ist der PBS recht schnell. Wozu brauchst du beim DR einen ESXi?

Ich habe meinen PBS auf einem dritten Node, der Quorum spielt und den PBS als VM hält. Die VM sichere ich per VZDump auf eine externe USB Disk.
Wenn das ding Crasht, brauche ich die Disk, mache auf einem frischen PVE einen Restore vom VZDump (3,6 GB im Schnitt) und wenn die Disks im System drin sind, sind die auch wieder in die VM durchgereicht. Dann kann ich wieder vom PBS restoren.

Wie du siehst, es gibt viele Kreative Lösungen, welche dir das Leben leichter machen können. VZDumps per Veeam wegsichern finde ich im Ernstfall zu unübersichtlich.

 

[superwinni2]

Achso. Ich dachte du hast den PBS eventuell auf nem ESXi Cluster. Mit DisasterRecovery (danke, das Wort ist mir vorhin nicht einfallen) rede ich wirklich von der Pike auf alles neu. Es überlebt nichts. Kein ESXi, kein PM, theoretisch nicht mal die NAS auf welcher die Backups liegen. Ein Recovery komplett aus dem Air-Gap. Alles was dann noch nutzbar ist, ist für mich eine Zeitersparnis damit man schneller lauffähig sein wird.

Rechne mit dem Schlimmsten aber hoffe das Beste

Das ganze ist bei mir etwas komplizierter mit Air-Gap welches über LTO-Bänder mithilfe von Veeam realisiert wird und auch der 3-2-1 Regel (schöngerechnet wäre es 5-3-1).
So ist aktuell meine Backup-Konstellation:
Ich habe ein ESXi (vCenter) Cluster und 3 (mit Absicht) einzelne PM VE Server.
Das komplette ESXi wird mithilfe von Veeam gesichert. Dieses landet dann auf der primären NAS (Laufwerk S). Zusätzlich ein Copy Job auf eine sekundäre NAS (Laufwerk E) und dann noch als OffSite-Backup mit Air-Gap auf LTO Band.
Der Veeam Server hat eine SMB Freigabe ((Laufwerk F) welche auf der sekundären NAS liegt) und ProxMox-VE sichert dort die Daten hin. Veeam nimmt diese Daten und sichert sie auf die primäre NAS und ebenfalls der Copy-Job auf die Sekundäre NAS und auf LTO.

Gibt in der Konstellation zwar ~100 GB (ehrlicherweise 2 TB da die Partition so groß ist) weniger nutzbaren (Sekundären Backup) Speicherplatz da manches doppelt ist. Das fällt hier allerdings nicht auf.

 

[Falk R.]

Klingt alles recht kompliziert und anfällig.
NAS für Veeam war noch nie eine gute Idee. Unnütze Protokolle an und die Sicherheitslücken werden auf den NAS spät oder gar nicht gefixt.

Mal eine Konstellation von einem Kunder der asu "Gründen" noch beides nutzen muss.
Das Setup ist auch so, weil ESXi und Veeam schon da waren.
Veeam Server Physikalisch mit lokalen HDDs, da HyperV Rolle drauf und ein virtueller PBS als VM.
Veeam Speichert auf lokale HDDs und der PBS hat auf den HDDs eine große virtuelle Disk.
Veeam macht ein Copy der vSphere Backups auf ein Linux Hardened Repository. (Server mit viel HDD Speicher) und macht ein HyperV Backup vom PBS direkt auf das Hardened Repository.
Vom LHR kann man direkt nach vSphere restoren. Im DR Fall müsste man den PBS aber wieder auf einen Server restoren.

Wenn vSphere abgelöst ist, bleiben die Langzeitbackups auf dem Linux liegen. Der Veeam Server wird zum Primären PBS und das Hardened Repository wird mit PBS neu installiert und die große XFS Disk einfach gemountet. Da darf dann der sekundäre PBS seine Daten dazu legen.

Das ganze hat dann auch guten Ransomwareschutz, der bei NAS Systemen eigentlich nie gegeben ist.