Veeam Backup and replication Geschwindigkeit

[dom0309]

Hallo zusammen,

ich habe eine kurze Verständnisfrage zu der ich keine richtige Info gefunden habe:

Gesichert wird eine VM mit einer MSSQL DB. Das Ganze passiert mit Veeam B&R 9.5.

Backupmethode ist reverse Incemental mit CBT und einer VM als Backupproxy.

Beim Bericht nach erfolgreichem Backup erhalte ich einen Wert für die jeweilige VM-Harddisk. z.B.

Festplatte2 (800GB) 361,4 GB read at 15MB/s [CBT] - Dauer 6:50:35

Nun die eigentliche Frage: Was genau passiert in dem Schritt der quasi 99% der Jobdauer benötigt? Eigentlich doch ein Abgleich und ein Schreiben der geänderten Blöcke oder nicht? Wenn ja, warum kommt man auf so eine "lausige" 15MB/s Rate?

Edit: Bottleneck ist Target:99%. Bei 15 MB/s dürfte das nicht so sein. Target ist mit 10GBit angebunden und schafft im normalen Filecopy bei großen Dateien knapp 500MB/s.

Viele Grüße

 

[McClane]

Das wird sehr wahrscheinlich der Aufräumvorgang sein, da du ja Reverse Incremental verwendest. Dabei werden ja die älteren Punkte gelöscht und die geänderten Datenblöcke ins neue Vollbackup geschrieben. Das dauert sehr lange da sehr viele Schreib-Leseoperationen auf der Festplatte statt finden. Je nach Storagekonfiguration und verwendetem Raid geht da die Performance ziemlich runter.

Ergänzung (8. März 2017)

Wie ist denn das Storage konfiguriert?
Ich verwende Forever Forward Incremental, und selbst da geht die Geschwindigkeit ziemlich runter beim Konsolidieren.

 

[gbene]

Wie schon geschrieben baust du ja ein neues Vollbackup aus dem Incremental. Das ist extrem I/O lastig. Je nachdem was für ein Storagesystem du hast geht da die Performance in die Knie. Wie viele Concurrent Tasks sind auf dem Repository zugelassen?

Wir sichern z.B. extrem große Archivserver, die nur so nice to have aber nicht wichtige Daten vorhalten auf eine SATA LUN mit Raid 10 als Basis und 3,5" 7,2k Platten. Im Vergleich zu unserer EMC ist die Merging Performance echt grottig. Ist halt n Unterschied 15k SAS mit SSD Cache gegen normale SATA... auch beim Preis

 

[dom0309]

Das Storage läuft mit Storage Server 2012 R2 Standard, 32GB Ram, Xeon E5-2630 v3.
Das OS läuft auf einem Raid1 aus 2x 300GB SAS 10K 12Gbs Platten.
Die Daten liegen auf einem Raid5 aus 6x 4TB SAS 7,2K 12Gbs Platten.

Normal 2 concurrent tasks. Hatte mal 3 probiert, ändert aber nichts.

Also liegts an den Platten. Umstellung auf 1 concurrent wird ja auch keine Wunder wirken oder?

gbene: bei was für einer Performance liegt ihr denn bei Sata Lun bzw EMC?

 

[McClane]

4TB? Das sind dann aber Nearline-SAS oder? 6 Platten und dann noch im Raid5, dann passt das ziemlich gut mit deiner Performance. Mehr kannst du da nicht erwarten.
Ich hab hier eine IBM V3700 mit 12 NL-SAS Platten im Raid5 und komme auf etwa das doppelte. Aber auch die 6 10k SAS Platten im zweiiten Raid5 machen da nicht so den Unterschied.
Darum nutz ich das Forever Incremental, da sind es etwas weniger IOs und auch weniger Daten die zurückgeschrieben werden müssen (und für die Tapesicherung eh Voraussetzung). Allerdings dauert da ein Merge von 175GB Daten bei 4 Concurrent Jobs auf dem SAN auch fast 2 Stunden (das Full ist 2TB groß).

 

[gbene]

Also das Sichern auf EMC läuft beim Lesen so mit 600 MB/s und beim Schreiben mit 150 MB/s. Also doch relativ fix. Auf die SATA LUNS läuft das ganze wesentlich langsamer. Ca. 50 MB/s lesen durch die Backup Files und ca 20 MB/s schreiben.

Wobei man sagen muss, dass die Backup Sourcen ESXi 6 Hosts sind, die vom physikalischen Backup Server (=Backup Proxy) direkt per 8 GBit FC angebunden sind. Das Backup Target EMC ist ebenso mit 8 GBit FC angebunden. Jeweils mit 2 Controllern a 2 Anschlüssen. Die SATA LUN ist per 4 * 1 Gbit LAN angeschlossen (Teaming).
Ein paar Hosts sind auch per 10 Gbit LAN angebunden. Die sind etwas langsamer als die per FC angebunden Hosts.

Der Backup Server hat ein 4 * 600 GB SAS Raid 10 fürs OS und den VBR Catalog

2 x Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 10 Cores/20 Threads
128 GB RAM


Wir sichern Forever Incremental, erstellen aber Samstag immer ein Active Full, damit unser Backup To Tape schneller läuft. Da sind 4 LTO 6 Laufwerke drin und wir müssen jeden Sonntag in einem kurzen Zeitfenster ca 20 TB wegsichern. Da lohnt es sich, den Platz mit dem Active Full zu belegen

 

[dom0309]

Ich sehe grade: wenn ich die VM als ActiveFull (1x im Monat) sicher dauert der Prozess mit aktiviertem CBT nur 1 std 20 Min.

Festplatte2 (800GB) 479,2 GB read at 132MB/s [CBT] - Dauer 1:02

Da sollte ich die VM wohl immer einfach voll sichern.

Hosts sind bei mir auch Esxi 6.0.

BackupStorage mit 10Gb angebunden. Storage redundant ebenfalls mit 8Gb FC wie bei euch.

 

[gbene]

Veeam unterscheidet aber ja, ob er per LAN sichern kann oder aber direkt an das Storage gehen kann. Dann springt er auf Network Mode um, wenn er "nur" LAN bekommt. Da gibts n paar Sachen, die das Backup etwas verlangsamen können.

Reverse Incremental ist ja eigentlich das, womit Veeam groß geworden ist. Mittlerweile nutzt man das aber nicht mehr, das Mergen dauert halt einfach zu lange. Deswegen machen wir auch forever incremental mit der Option, dass immer Samstag ein Fullbackup geschrieben wird. Das wird dann wieder auf Tape kopiert. Zusätzlich zu dem sichern auf Backup Target 2 (EMC DataDomain) und wegschreiben der Inkrementellen Backups täglich auf Tape.

 

[McClane]

Wenn du den Platz für die Vollbackups hast kannst du das natürlich machen. Auf mein Storage passen allerdings keine 60 Vollbackups
Man sollte allerdings auch bedenken das die inkrementellen Backups evtl. schneller durch sind als Vollbackup, da die Transformation parallel stattfinden kann und in meiner Umgebung die Backups in weniger als einer Stunde fertig sind (ca. 70 VMs). Zumal das Produktivstorage keine Last hat dabei. Jeden Tag Vollbackup würde sicherlich andere Aktionen die in der Nacht laufen beeinflussen (Datenbankjobs usw.)