Auslegung Veeam-Repository

[mwiederkehr 351]

Hallo zusammen

 

Ein Kunde hat sich über zu lange dauernde Backups beschwert. Diese werden nicht mehr innerhalb der Nacht fertig. Er hat einen Hyper-V-Cluster (Windows Server 2019) mit vier Hosts und ca. 150 VMs. Die Backups laufen über einen separaten Server mit Veeam Backup & Replication 11a. Der Datenbestand im Repository beträgt 80 TB, die tägliche Änderung ca. 500 GB. Die Sicherungen sind als Reverse Incremental mit 90 Tagen Rückhaltezeit konfiguriert. Der Speicher liegt auf einer Synology Rackstation und ist über SMB mit 10 Gig angebunden. Es besteht ein RAID 6 aus 12 x 12 TB SATA-Disks (7.2k). Zusätzlich ist ein SSD-Cache mit 2x 1.8 TB (RAID 1) konfiguriert.

 

Veeam sind das Bottleneck beim Target und wenn ich auf die Synology schaue, ist der Durchsatz nicht das Problem, aber sie kommt nicht über 200 IOPS beim Schreiben.

 

Aus meiner Sicht bestehen folgende Probleme:

 

- Bei der Synology ist die Chunk Size 64 KB und lässt sich (ausser inoffiziell mit mdadm über SSH) nicht anpassen. Wenn Veeam mit 256 oder 512 KB kommt, werden zu viele Disks beschäftigt.

- Der SSD-Cache auf der Synology schreibt die Daten erst auf die Disks, wenn er fast voll ist. Er ist somit in diesem Szenario nur von beschränktem Nutzen.

 

Zur Verbesserung fällt mir als Erstes ein anderer RAID-Level ein. Mit RAID 10 sollte sich eine massive Verbesserung erzielen lassen. Wäre eine Umstellung von SMB auf iSCSI (mit ReFS) und Umstellung auf Forward Incremental ratsam? Ich kenne die Theorie, aber die Erfahrung mit Repositories dieser Grösse fehlt mir. Damit ich keine falsche Empfehlung abgebe, bin ich froh um Ratschläge.

 

Wie sehen eure Speicher in dieser Grössenordnung aus? Besten Dank für eure Erfahrungsberichte.

[Marco31 31]

So viel ich weiß ist reverse incremental als Sicherung nicht so performant. Da wirft Google einiges zu aus, vielleicht liegt da das Problem. 

[Nobbyaushb 1.359]

Was spricht denn Veeam dazu?

Es wird doch einen gültigen Vertrag geben, oder?

[gaijin 20]

vor 6 Minuten schrieb Marco31:

So viel ich weiß ist reverse incremental als Sicherung nicht so performant. Da wirft Google einiges zu aus, vielleicht liegt da das Problem. 

 

Hi,

die Erfahrungen haben wir auch gemacht.

Wir haben einen ähnlichen Kunden und fahren hier Inkrementell und Synthetic Full.

Wir haben dadurch einen ordentlichen Performancezuwachs erreicht.

bearbeitet 13. Dezember 2022 von gaijin
Rechtschreibung

[Squire 211]

Was ist der Grund für reverse incemental?

NAS als Backupziel ist suboptimal. Ich würde das eher als Block LUN per iSCSI an den Backupserver als Laufwerk durchreichen, dann ReFS verwenden

bearbeitet 13. Dezember 2022 von Squire

[mwiederkehr 351]

vor 40 Minuten schrieb Marco31:

So viel ich weiß ist reverse incremental als Sicherung nicht so performant.

Ja, es erzeugt die doppelte Schreiblast im Vergleich zu Forward Incremental (1x lesen, 2x schreiben vs. 1x lesen, 1x schreiben). Dafür entfällt die Belastung durch (Synthetic) Fulls.

 

vor 39 Minuten schrieb Nobbyaushb:

Was spricht denn Veeam dazu?

Das ist eine gute Idee. Ist mir gar nicht eingefallen, die zu fragen. Hatte in der Vergangenheit bei anderen Herstellern die Erfahrung gemacht, dass man einfach ein paar Links zugeschickt bekommt, aber nicht direkt etwas aus der Praxis. Dass 64 KB Chunk Size nicht ihrer Empfehlung entsprechen, habe ich selbst in der Doku gefunden. Aber der Kunde hat genug bezahlt für Lizenz & Support, da kann ich mal anfragen.

 

vor 14 Minuten schrieb Squire:

Was ist der Grund für reverse incemental?

Es scheint (wenn der Storage schnell genug ist) die eleganteste Lösung zu sein: Die aktuelle Sicherung ist immer die Vollsicherung, die Wiederherstellung also schnell. Und es entfallen Aufwand und Speicherbedarf für (synthetische) Vollsicherungen. (Wobei die Geschwindigkeit mit ReFS kein Problem mehr sein sollte, wenn ich die Doku richtig verstanden habe.)

[djmaker 95]

Ich stimme ISCSI / Block und ReFS zu, das bringt aber erst ab Server 2016 auf dem Veeam Server etwas. Sichere die ISCSI-Verbindung undeningt mit Benutzer / PW etc. ab, die SW / FW nicht vergessen.

[mwiederkehr 351]

Nachdem jetzt ein paar Wochen Erfahrungen gesammelt werden konnten, gebe ich gerne eine Rückmeldung:

 

Das Update auf DSM 7.1 und Neu-Erstellen des SSD-Caches (damit das neue Verfahren verwendet wird) hat geholfen. Der Cache ist nun wesentlich intelligenter. Wenn die Disks nichts zu tun haben, wird der Inhalt des Caches auf die Disks geschrieben. Die Daten bleiben aber im Cache, einfach unter "überschreibbar" und nicht "verwendet". Kommen neue Daten dazu, werden sie überschrieben, ansonsten als Lese-Cache verwendet. (Der Cache ist für Veeam nicht unbedingt relevant, aber einfach zur Information, falls mal die Anschaffung einer Synology erwogen wird.)

 

Ich habe eine LUN erstellt, diese per iSCSI an den Backupserver angehängt und mit ReFS (Clustergrösse 64K) formatiert. Danach im Veeam ein Repository erstellt und einen neuen Backupjob eingerichtet. (Wenn man die Backupdaten verschiebt und den bestehenden Job anpasst, wird Fast Clone nicht verwendet.)

 

Resultat: Die Sicherungen laufen nun mit über 500 MB/s statt um die 30 MB/s. Zeitlich sind sie um einen grösseren Faktor schneller: elf Minuten statt sieben Stunden! Wie von Veeam versprochen benötigen die wöchentlichen Synthetic Fulls so gut wie keinen Speicherplatz.

 

Besten Dank für die Unterstützung! Das Thema "Fast Clone" und damit die Nutzbarkeit von Forward Incremental ist komplett an mir vorbeigegangen.

[Squire 211]

ja - ist schon erstaunlich, dass man mit gleicher Hardware, aber unterschiedlicher Konfiguration eine solche Verbesserung erreichen kann.

Danke für die Rückmeldung!