Virtuelle Disks unterschiedlich häufig sichern

[herzkerl]

Hallo zusammen, wir haben bei einer Fileserver-VM eines Kunden bisher zwei Backups gefahren:
• Ein imagebasiertes Backup der gesamten VM um 6 und 18 Uhr, täglich – bisher mit Active Backup for Business, nun mit Proxmox Backup Server; sowie
• ein dateibasiertes Backup der Dateien unter D:\Daten, das stündlich lief – bisher mit Veeam Backup & Replication.

Das zweite Backup möchten wir nun auch mit Proxmox Backup Server abbilden. Mir ist klar, dass hier (noch) kein dateibasiertes Backup eines Windows-Servers möglich ist – und ich möchte auch nicht unbedingt den Umweg gehen und die Dateifreigabe via SMB auf einem Linux-Host einhängen und dort dann sichern.

Idealerweise sollte es möglich sein, die zweite virtuelle Disk (Laufwerk D, auf dem die Dateien liegen) häufiger zu sichern, hier habe ich aber noch keine Lösung gefunden.

Freue mich auf eure Vorschläge

 

[Falk R.]

Du kannst das OS doch genauso oft Inkrementell mitsichern, macht ja kaum Volumen aus. Alles andere macht beim DR Restore genau so wenig Spaß, wie so ein gestückeltes Backup. Das Inkrementelle PBS Backup wird garantiert effizienter und schneller sein als das bisherige File Backup.

 

[herzkerl]

Damit hast du natürlich Recht – das Problem hätte ich genauer spezifizieren müssen:
• Es wird hier auf ein Synology-NAS gesichert (natürlich mit HDDs, und noch dazu mit 1 GBit/s aktuell)
• Wenn ich "Verify New Snapshots" aktiviere, hängt sich der PBS irgendwann auf, weil er nicht hinterherkommt

Ich würde nun also gerne die Snapshots von 6 und 18 Uhr verifizieren, die anderen aber einfach nicht. Falls ich das richtig sehe, gibt es hier nur eine Möglichkeit:
• "Verify New Snapshots" deaktiviert lassen
• Die stündlichen Backups in einen zweiten Namespace schreiben
• Einen Verify-Job für die anderen Backups im 'Root Namespace' einrichten, der regelmäßig läuft

Glücklicherweise bewahren wir hier nicht lange auf, sodass es gar nicht zu einem 're-verify' kommen muss.

 

[Falk R.]

Um wieviel Volumen geht es denn? Günstige QLC SSDs reichen in der Regel für den PBS auch aus und haben bessere Leseperformance und auch Verify gehen schnell.

 

[herzkerl]

Wenige TB (irgendwas zwischen 2 und 4)... Günstige QLC SSDs haben i.d.R. keine Power Loss Protection, und afaik sollte man die schon verwenden. Gut, hier geht es nicht um ZFS oder Ceph, sondern eine Synology, da wird das sicherlich nicht sooo dramatisch sein. Und es geht "nur" um Backups, die dank Verify Job ja auch überprüft werden können. Hmm...

 

[Falk R.]

PLP ist bei Produktivspeicher wichtiger, damit man da den Cache nicht deaktivieren muss. Bei dem wenigen Schreiben vom Backup geht das auch ohne Cache. Aber beim lesen und Verify macht Sicht das extrem bemerkbar. Ich habe dann lieber ein schnellen Restore und ein Full Backup dauert dann halt etwas länger.

 

[herzkerl]

Aus der Ceph mailing list (Quelle):

With Ceph, power loss protection is important not because it protectsthe data after power loss, but because it allows the drive not towaste time on fsyncs (which Ceph issues for every write). I.e. betterperformance.

Und hier noch via StackExchange (Quelle):

Even Consumer-grade SSDs have serious issues with Ceph's fsync frequency as journals/WAL, as consumer SSDs only have transactional logs and no real power-backup.

It's Enterprise SSDs that have large capacitors that allow the drive to continue operating after a power-loss. Thus, they can guarantee a successful write under a power-loss event.

The added benefit is that Enterprise SSDs typically ignore fsync commands from the OS! Because they can guarantee the success of the write, they immediately return the fsyncrequest from the OS.

Thus, you get major performance gains when using an Enterprise-grade SSD as your WAL/DB/Journal.

Under FileStore, you'll see those delays go away, but you'll see inconsistent bursts of cache and then back down.

This is where BlueStore comes in, as BlueStore will guarantee a consistent IOPS and write across the board. But, you need WAL/DB/Journal on an Enterprise SSD to ignore those fsyncs.

Habe dazu früher auch schon immer in Verbindung mit Ceph gelesen, dass man von SSDs ohne PLP die Finger lassen soll und HDDs nur zusammen mit WAL/DB auf NVMe (mit PLP) nutzen soll aufgrund der Thematik. Unsere HDD-Pools in Ceph (derzeit noch ohne WAL/DB auf NVMe) sind auch sehr langsam, das kann ich aus der Praxis bestätigen.

Würde mich freuen, hierzu noch ein paar Erfahrungsberichte zu hören, werde aber ggf. in unserem eigenen Cluster mal QLC-SSDs ohne PLP (aus dem Consumer-Bereich) für die Backups testen, sofern ich die Zeit dafür finde.

 

[Falk R.]

Also für Ceph benutze ich produktiv nur Enterprise NVMe, aber hier geht es um Backup. Man muss ja auch kein ZFS nutzen.

 

[herzkerl]

Man muss ja auch kein ZFS nutzen.

Worauf war das bezogen?

Bei den Kunden sind es ja eh i.d.R. Synology NAS, die dann btrfs nutzen via CIFS. Alternativ könnte ich natürlich auch iSCSI verwenden, aber die Konfiguration via CIFS war einfacher – würde aus Performancegründen (mal ungeachtet der Platten) hier iSCSI einen großen Unterschied machen? Welches Filesystem würdest du hier bevorzugen?

Da ist dann auch das Problem, dass meistens nicht genügend Slots für weitere SSDs da sind – die sind alle mit HDDs gefüllt – und die M.2-Slots (so sie denn vorhanden sind) nur Synologys eigene SSDs (die eher in der Enterprise-Klasse mitspielen und daher natürlich teurer sind) als Volume genutzt werden können.

Was ich noch nicht ausprobiert habe (aber definitiv als nächstes Mal teste!) ist es, den SSD-Cache in der Synology einzurichten, mit NVMe-SSDs aus dem Consumer-Bereich. Ich gehe davon aus, dass das ein gutes Performance-Plus bringen wird. Lasse euch dann gerne mal Benchmarks in einem eigenen Thread da.

 

[herzkerl]

Was ich noch nicht ausprobiert habe (aber definitiv als nächstes Mal teste!) ist es, den SSD-Cache in der Synology einzurichten, mit NVMe-SSDs aus dem Consumer-Bereich. Ich gehe davon aus, dass das ein gutes Performance-Plus bringen wird. Lasse euch dann gerne mal Benchmarks in einem eigenen Thread da.

Kurzes Update: Habe jetzt mal zwei NVMe-SSDs in einer Synology beim Kunden und lasse dort zum Spaß noch den SSD-Cache-Ratgeber laufen für eine Woche – der zeigt dann an, wie groß die SSDs sein sollten für das Volume. Es sind 2x 1 TB, somit denke ich, mehr als ausreichend.