Veeam Backup & Replication hat in den letzten Jahren den Markt ganz schön aufgemischt.
Früher habe ich bei Kunden Backupexec oder Acronis Produkte eingesetzt. Als dann aber selbst kleinere Firmen angefangen haben zu virtualisieren sind diese Produkte etwas ins Hintertreffen gekommen.
B&R ist eigentlich relativ einfach zu bedienen. Mit den verschiedenen Backup Modi hatte ich aber anfangs so meine Probleme. Es gibt so viele aber welches ist das richtige Verfahren? Warum gibt es eigentlich so viele unterschiedliche Möglichkeiten? Das war bei Backupexec dann doch etwas einfacher.
Darum möchte ich in diesem Artikel auf die einzelnen Verfahren näher eingehen.
B&R bietet viele verschiedene Möglichkeiten um VM´s unter VMware oder Hyper-v zu sichern.
Als ich mit der Version 8.0 angefangen habe war die Dokumentation bei Veeam noch etwas unzureichend und ich musste etliche Testsicherungen vornehmen bis ich verstanden habe wie die einzelnen Backup Verfahren funktionieren. Bei Veeam findet man zwar immer schöne Beispiele für ein Backup von 7 Restorepoints aber wie sich die Software nach z.B. 60 Tagen verhält wird nicht aufgeführt. Bei mir ist in den ersten Monaten regelmäßig mein Backup Repository vollgelaufen.
Es gibt leider keine Möglichkeit wie bei anderen Programmen dass man B&R einen Speicherplatz zuweist und dann automatisch Backups erstellt und gelöscht werden. Na ja, es muss ja auch Platz für Features in neuen Versionen geben.
Übrigens, falls jemand mit verschiedenen Begrifflichkeiten nicht zu Recht kommt. Ich habe dafür einen eigenen Artikel angelegt der auf Begriffe wie Repository, Deduplizierung, Bitlooker usw. eingeht.
So und jetzt geht´s los:
B&R kennt eigentlich nur 2 Backupverfahren, Reverse Incremental & nur Incremental Backups
Jetzt schreibe ich bewusst, “eigentlich”. Richtig wäre, dass B&R folgende Modi kennt:
Forward incremental oder nur als Incremental (recommended) in der Software bezeichnet.
Active full Backup in Kombination mit den beiden oben genannten
Synthetic Full Backups in Kombination mit den beiden oben genannten
Synthetic Full kombiniert mit „Transform previous backup chains into rollback“
Das ist nicht gerade wenig 🙂
Der Dialog in B&R sieht dabei so aus:
Am Anfang gibt es wie bei jedem anderen Backupsystem immer ein Fullbackup (Dateiendung .vbk). Hier wird die gesamte VM gesichert oder mehrere, je nach Jobauswahl.
Beim nächsten Backup wird ein incremental Backup gefahren (Dateiendung .vib oder .vbr). Dabei wird immer zum vorherigen Backup nur die Änderungen von Blöcken gesichert was sehr platzsparen ist und auch sehr schnelle Backups ermöglicht. Differental Backups kennen viele andere Backupsysteme, B&R aber nicht.
Ein kleiner Hinweis noch. B&R sichert keine Dateien. Es werden immer nur Blöcke gesichert die sich z.B. seit dem letzten Backup verändert haben. Das hat nicht nur Vorteile. Oft wundert man sich wie groß Incrementelle Backupdateien sind (mehrere GB) obwohl doch nur wenige Dateien im MB Bereich sich verändert haben. Stichwort Defragmentierung. Wer seine Server regelmäßig defragementiert ändert sehr viele Blöcke, daraus resultiert dann auch ein sehr großes Backupfile. Auch sollte man sich mal den Zusammenhang zw. NTFS und darunterliegende Filesysteme wie VMFS von VMware ansehen.
Vor- und Nachteile der Backupmodi
Beim Incrementalbackup baut jede Datei auf der anderen auf. Wird irgendwann mal eine Datei beschädigt oder wurde gelöscht (Spalte F – Freitag) dann ist meistens das ganze Backup beschädigt. In der Regel kann man noch das Vollbackup verwenden und evtl. noch die incremental Dateien dahinter bis zu der beschädigten Datei, dahinter ist alles verloren. Hier mit x gekennzeichnet.
Verwendbar sind also die Backups Montag bis Donnerstag.
Durch verschiedene Backup Verfahren kann man aber dieses Manko etwas kompensieren. Dazu später mehr. Der Vorteil ist, dass die incrementelen Backupdateien (.vib/.vrb) relativ klein sind und somit auch schnell erzeugt werden können. Hängt natürlich davon ab wie viele Daten sich auf einem Server täglich ändern.
Synthetisches Backup:
Bei einem normalen Vollbackup muss die komplette VM eingelesen werden. Hier werden über das Netzwerk sehr viele Daten kopiert. Zusätzlich wird das Produktivsystem stark belastet. Dies kann man mit einem synthetischen Backup vermeiden.
Gehen wir mal davon aus, dass wir von Montag bis Freitag sichern und am nächsten Montag wieder ein Vollbackup erstellen wollen. Dann kann B&R ein synthetisches Backup erstellen in dem es das letzte Vollbackup (Bild 2 A) verwendet + alle inkrementellen Backups und daraus eine neue Datei generiert.
Das Voll-Backup (F) ist also die Summe aus (A,B,C,D und E). Zusätzlich werden noch die wenigen Daten mit den Änderungen geholt (seit Freitag) und in das synt. Vollbackup eingebacken.
Liegen die Backups z.B. wie bei mir direkt auf dem gleichen Server wie B&R dann entsteht fast überhaupt kein Netzwerktraffic. Am Dienstag wird dann wieder wie gewohnt weiter verfahren mit inkrementellen Backups.
Man könnte diesen Vorgang also problemlos auch während der Arbeitszeit laufen lassen und niemand würde es merken.
Ich muss dazu sagen, ich bin kein Freund von synt. Backups. Funktioniert dies immer reibungslos?
Habe da manchmal etwas Bedenken weil ja tonnenweise Blöcke von A nach B umkopiert werden. Zum Glück gibt es, ich glaube seit der V9 diverse Möglichkeiten um Backup´s autom. zu prüfen, zu defragmentieren etc. damit auch wirklich sichergestellt werden kann, dass das Backup in Ordnung ist.
Kurzer Ausflug zu Backupzeiten, I/O´s etc.
Veeam kennt unterschiedliche Backup-Verfahren. Ich erkläre diese hier nur oberflächlich. Man kann sich evtl. noch im Detail einlesen wie viele I/O´s bei welchen Verfahren entstehen. Das war für mich eigentlich nie ein Thema. Meine Backups laufen immer Nachts und ob die Festplatte beim Verfahren 1 mehr Last hat wie beim Verfahren 2 ist für meine Umgebung eigentlich nicht relevant. Auch in Zeitnot bin ich nicht. Manche Verfahren brauchen mehr Zeit da mehr I/O´s durchgeführt werden. Das ist in anderen Produktivsystemen sicherlich wichtig oder beim Einsatz von SSD´s, dass die vielleicht schneller kaputt gehen bei vielen I/O`s. Was mir aufgefallen ist. Wenn man z.B. eine NAS wie QNAP hat und auf diese sichert und man verwendet Reverse Incremental dann dauern die Backups unglaublich lange. Die vielen I/O´s zwingen die NAS und/oder das Netzwerk dann in die Knie. Teilweise erreiche ich nicht mehr wie 8-12MB/s.
HINWEIS:
Nachdem man sich bei Veeam in seinen persönlichen Bereich eingeloggt hat, kann man sich unzählige informative Filme in deutscher Sprache ansehen die alles abdecken was man benötigt.
Hier wird auch viel intensiver eingegangen wieviele I/O´s , welcher Modi in Anspruch nimmt.
Forever Forward Incremental
Im Auslieferungszustand kommt ab B&R 8.0 das sog. Forever Forward incremental zum Einsatz.
In der Benutzoberfäche nur als Incremental (recommended) bezeichnet.
Ich möchte bei den Backupmodis auch gezielt eingehen was passiert wenn man mehr wie 7 Restorepoints festlegt. In den Beschreibungen von Veeam wird nämlich fast immer davon ausgegangen. Das ist der Idealzustand. Gibt man andere Zahlenwerte ein wird man oft erstaunt sein was dann alles passiert und warum die Festplatte vollgelaufen ist.
7 Restorepoints:
Man kann bei B&R übrigens nicht sagen, er soll am Tag x das erste Vollbackup erstellen. Also z.B. am Montag. Das erste Vollbackup läuft dann los wenn der erste Job ausgeführt wird. Man müsste also manuell bis zum Montag warten und dann den ersten Job starten. Alle weiteren Full-Backups kann man zeitlich aber steuern.
Bei 7 Restorepoints wird am ersten Tag immer ein Vollbackup gestartet mit der Endung .vbk. Danach werden inkrementelle Backupdateien erstellt mit der Endung .vib.
Am 8. Tag ( Bild 4,neuer Montag H) integriert B&R die Datei Dienstag Spalte C in das Vollbackup (Bild 4) und löscht danach die ehemalige Datei Dienstag Spalte C aus Bild 3. Die restlichen Dateien rutschen in der Reihenfolge quasi nach links nach. Dabei werden ältere Blöcke aus dem Vollbackup entfernt. Das Vollbackup hat also nicht mehr den Stand vom Montag sondern jetzt den Stand vom Dienstag. Zusätzlich wird am neuen Montag natürlich eine increm. Datei erstellt. In der Reihenfolge also jetzt die letzte Datei, Spalte H usw.
Am Dienstag wieder das gleiche Spiel. Die Blöcke vom Mittwoch werden in das Vollbackup integriert und ein gewisser Teil aus dem Vollb. entfernt. Das Vollbackup vom ehemals Montag Spalte B hat jetzt den Stand vom Mittwoch Spalte C usw.. Bei diesem Verfahren liegen auf der Festplatte immer nur die Anzahl der Restorepoints die eingetragen wurden. Also 7 Dateien. Man kann sich also Dateien wiederherstellen von vor 7 Tagen oder die ganze VM zurücksichern, max. vor 7 Tagen.
Bei z.B. 20 Restorepoints sieht die Grafik dann so aus (Bild 5).
Es gibt immer nur 1 Vollbackup und viele incrementelle Backups.
Es ändert sich also nicht viel nur dass viel mehr Restorpoints irgendwann auf der Platte liegen. Der Vorteil liegt auf der Hand, ich habe immer nur ein Vollbackup auf der HDD. Selbst nach vielen Monaten nicht und die Anzahl der Dateien ändert sich auch nie. Es bleibt immer bei 1 Voll und 19 Inkrementellen Dateien.
Ich persönlich würde von diesem Verfahren aber abraten. Man könnte ja z.B. auch 60 oder 100 Restorepoints einstellen. Die Kette wird also immer länger. Geht mir mal eine Datei kaputt habe ich unter Umständen sehr viele Backupzustände verloren. Zusätzlich gibt es vielleicht auch Probleme mit dem Vollbackup. Hier werden ja jeden Tag Blöcke entfernt und neu rein integriert. Ist das wirklich über dutzende oder hunderte Backups lang 100%ig sicher? Seit B&R 9.0 gibt es ja zum Glück einen Integritätstest. Der versucht defekte Dateien/Blöcke irgendwie zu reparieren und zu defragmentieren. Also ein Schritt weiter in Richtung Sicherheit. Dieses Verfahren kann man auch beim Sichern auf Tape verwenden. B&R sichert immer die Dateien aus einem Backupjob die sich verändert haben auf Band. Jeder hat hier aber andere Anforderungen. Firma A sichert auf Tape immer Fullbackups während andere nur die inkrementellen Daten sichern.
Reverse Incremental (Slower)
Beim Reverse Incremental Verfahren laufen die Vorgänge etwas anders ab.
Wie gehabt wird am ersten Tag ein Vollbackup erstellt (Montag) Am Folgetag werden die neu erkannten Blöcke sofort in das Vollbackup integriert und alte Blöcke nicht gelöscht wie beim Forward Incremental sondern in eine .vrb Datei rausgeschrieben. Wieder am Folgetag werden die Änderungen in das .vbk integriert und alte Blöcke in eine .vrb geschrieben.
Der Vorteil hier ist, dass das Vollbackup immer den aktuellen Stand enthält. Bei einem Restore vom Vortag benötigt B&R nur die .vbk.
Beim Forward Incremental mit z.B. 20 Restorepoints würde B&R die .vbk sowie alle 19 .vrb´s benötigen. Der Restore dauert schon mal deutlich länger und bei nur einer defekten .vrb ist kein Restore vom Vortag möglich da alle Dateien der Backupkette aufeinander aufbauen.
Das Bild 6 zeigt den Verlauf der Dateien nach 7 Tagen bzw. 7 Restorepoints.
Hat man 7 Restorepoints am Sonntag erreicht (Bild 6) werden am nächsten Tag (Montag) wieder die neuen Blöcke in die vbk integriert, alte Blöcke in eine .vrb rausgeschrieben. Siehe Bild 7
Die älteste .vrb vom damaligen Montag B (Bild 6) wird gelöscht.
Stellt man z.B. 20 Restorepoints ein wird die Kette einfach nur länger. 1x .vbk und 19x .vrb. Hat man 20 Restorepoints erreicht werden neue Blöcke in die vbk integriert, eine neue vrb rausgeschrieben und die älteste .vrb gelöscht.
Persönlich mag ich auch dieses Verfahren nicht da auch hier die .vbk ständig verändert wird. Das erzeugt eine hohe i/o Last. Bei NAS Systemen habe ich hier schon schlechte Erfahrungen wegen der Performance gemacht.
Incremental mit Active Full Backup
Kommen wir jetzt zu diversen Optionen bzw. Zwischenlösungen. Das folgende Verfahren setze ich selbst bei allen Backupjobs ein.
Man muss dazu, wie im Bild 8 zu sehen ist, Incremental Backup (1) anwählen sowie unten noch den Haken bei (2) Active Full Backup setzen und Veeam noch erklären, wann es denn die Full Backups erzeugen soll. Jeden Monat oder wöchentlich.
Ich gehe wieder von 7 Restorepoints aus. Grundsätzlich passiert die ersten 7 Tage erst einmal das gleiche wie oben beschrieben. Ich gehe von einem Backup pro Tag aus.
Ich möchte jetzt also jeden Monat ein Vollbackup erstellen. B&R wird jetzt nicht wie angenommen 7 Restorepoints erstellen und wie oben beschrieben weiterarbeiten. Nein, es werden weitere .vib Dateien erstellt bis der Monat vorbei ist und das 2. Vollbackup erstellt wird. Dies hatte ich bei meinen ersten Versuchen nicht erwartet. Obwohl ich 7 Restorepoints eingestellt hatte, liegen nach 30 Tagen auf einmal 1x .vbk und 29x .vib Dateien auf der Festplatte sowie eine neue erstellte .vbk. Wie geht es weiter und was bringt mir die Einstellung der 7 Restorepoints?
Nach dem letzten Vollbackup (also am Tag 31) werden 6 weitere inkrementelle Backups erstellt (Tag 37). Jetzt erst sind für Veeam die eingestellten 7 Restorepoints erreicht (1x .vbk + 6x .vib) die immer auf der HDD liegen MÜSSEN (Bild 9). Danach wird die komplette vorherige Kette (1x .vbk + 29x .vib) gelöscht und alles beginnt von vorne. Man hat also an einem bestimmten Tag bis zu 37 Backupdateien auf der HDD. Und die zusammen nehmen nicht gerade wenig Platz in Anspruch.!!!
Ich habe es im Bild 9 dargestellt wie das dann aussehen würde.
Laut dem Bild 9 ist es jetzt Dienstag und für Veeam ist das eingestellte Ziel von 7 Restorepoints erreicht. Das heißt, es müssten auf der Festplatte minimum 7 Restorepoints liegen. Wenn am Mittwoch das Backup losläuft wird Veeam erkennen, dass 7 Restorepoints vorhanden sind und löscht die komplette Kette vor dem letzten Voll-Backup. Also alles zw. Spalte B und AD.
Nehmen wir mal an, mir fällt am letzten Montag ein, dass ich vor 20 Tagen etwas gelöscht habe, kein Problem, mein Backup reicht ja 36 Tage zurück. Aber schon am Mittwoch habe ich verloren da B&R gnadenlos 30 Restorepoints löscht. Der ganz Vorgang beginnt wie gehabt wieder, es werden zig .vib Dateien erzeugt bis nach einigen Tagen wieder ein Fullbackup erzeugt wird usw. Genauer gesagt alle 30 Tage.
Hat man wie ich, noch ein Tape Backup, stört mich das vorzeitige Löschen nicht. Auf meine Backups vor 30 oder 40 Tagen kann ich ja zugreifen und mir die Daten vom Band holen. Vorausgesetzt ich habe eine Tape Library.
20 Restorepoints
Bei einer Einstellung von 20 Restorepoints passiert 4 Wochen lang das gleiche wie bei 7. Es werden also 30 Restorepoints erstellt dann das 2. Vollbackup. Da wir 20 Restorepoints festgelegt haben werden 19 weitere .vib´s erstellt. Jetzt erst, nachdem über 50 Dateien auf der Platte liegen kann alles vor dem letzten Vollbackup entfernt werden. B&R kann in diesem Fall immer nur ganze Ketten löschen. Einzelne vibs zu löschen macht keinen Sinn da immer aufeinander aufbauen.
Achtung!!
Man muss hier genau kalkulieren was man erreichen möchte. Am idealsten Tag kann ich bei 20 Restorepoints knapp 50 Tage zurückgreifen. Aber schon einen Tag später nur noch 20 Tage !!!! nachdem B&R eine komplette Kette gelöscht hat.
100 Restorepoints
Wenn ich z.B. 100 Restorepoints festgelegt habe ( ich möchte also ca. 3 Monate lang auf meine Daten zugreifen können, dann liegen auf meiner HDD im besten Fall, 5 Full Backups auf der HDD, bis B&R eine Kette von 1x .vbk + 29 .vib löscht und Speicher freigibt. Meine Fileserver belegen pro .vbk 2TB. Bei 100 Restorepoints belegen alleine schon die Full Backups 10TB Speicher und die .vib Dateien kommen ja auch noch hinzu.
Ist etwas verwirrend und auch etwas schwer hier in Worte/Bilder zu verfassen.
Da sich bei dieser Backupmethode das Fullbackup nie ändert kann man die Dateien auch perfekt auf Band sichern. Veeam sichert auf Band ja immer nur die Dateien die sich im Repository/Job geändert haben. Somit wird das Fullbackup File auch nur 1x auf Band gesichert. Bei den weiter oben genannten Modi wird jeden Tag das Full gesichert.
Statt dem Active Full kann man auch ein syntetisches Full fahren. Da ich Nachts die nötige Zeit habe fahre ich lieber ein Active Full. Sicher ist sicher.
Im Netz gibt es einen Kalkulator für die Sicherungen http://rps.dewin.me/
Ärgernisse
Was mich bei der Backupplanung etwas ägert ist, dass ich selbst nicht viel darüber entscheiden kann was ich im Detail einstellen will. Ich würde mir z.B. wünschen, dass ich selbst entscheiden kann wie oft B&R ein Fullbackup erzeugt. Aktuell geht nur 1x im Monat oder wöchentlich. Bei nicht ganz sooo wichtigen Daten würde ich lieber alle 60 Tage ein Fullbackup machen können aber halt mit dem Risiko, dass mal was defekt sein könnte bei so vielen Dateien. Dafür spare ich Platz.
Hin und wieder hängt auch B&R und warum auch immer wird am 30. Tag kein Full-Backup erzeugt. Sichert also einfach weiter. Da kann man sich nur nur behelfen und mal ein Full-Backup von Hand zu erzeugen
Reverse Incremental mit Active Full Backup
Hier verhält sich Veeam genau gleich wie beim Incremental Backup. Statt bei z.B. 7 Restore Points stehen zu bleiben wird auch wieder alle 30 Tage ein Full Backup erzeugt. Was das im Detail bedeut, siehe oben bei Incremental Backup mit Active Full Back.
Incremental Backup mit synthetic Full und Transform previous chains into rollbacks
Das hört sich doch mal gut an, oder? Kann man aber sich nichts darunter vorstellen.
Was ist das jetzt? Das ist eine Kombination aus Forward Incremental und Reverse Incrementeal Backup. Und dieses “previous chains into rollback” sagt folgendes aus.
Ich stelle z.B. 14 Restorepoints ein und am Samstag soll das Syn. Full erzeugt werden. Am 1. Tag wird ein Full-Backup erzeugt, jeden weiteren Tag ein .vib File. (Bild 12).
Jetzt kommt die Besonderheit. Am 6. Tag (Samstag) werden zuerst alle .vib Files in .vrb Files umgewandelt (Bild 14). Das .vbk File wandert quasi nach ganz rechts und alle reverse incrementellen Dateien nach links. Im Action Feld steht dann auch eine ganze Weil “Tansforming full backup (x% done). Das kann bei größeren Datenmengen eine ganze Zeit lang dauern. Danach läuft natürlich noch das eigentliche Backup und es wird ein .vib File erzeugt. Beides am Samstag.
Es geht jetzt wieder weiter bis zum nächsten Samstag. Die .vib Files werden wieder in .vbr Files transformiert und das .vbk File wandert nach rechts.
Jetzt sind ja irgendwann mal die eingestellten 14 Restore Points erreicht. Dann wir einfach mit jedem neu erzeugtem .vib File das letzte .vrb File in der Kette gelöscht. Damit wird erreicht dass bei diesem Backup Modi immer nur die eingestellten Restore Points auf der Festplatte liegen.
Für wenn oder was dieses Backupverfahren ist erschließt sich mir allerdings nicht. Es hat meines Erachtens keine Vorteile zum reinen Incremental Backup und erzeugt durch das ständige transformieren auch noch eine sehr hohe I/O Last. Egal wie viele Restore Points man einstellt. Spätestens alle 7 Tage wird ein syn. Backup erstellt. In der gesamten Kette gibt es immer nur Vollbackup aber das ist beim reinen rev. Incremental ja auch so, mit weniger I/O Last. Man könnte jetzt auch noch zusätzlich den Haken bei “Create active full backup” setzen aber das ändert auch nicht viel, nur dass halt aus dem Store alle 30 Tage ein Full erzeugt wird.
So, dass war´s zum Thema Veeam und die Backupmodi. Man würde nicht glauben wie lange so ein Artikel werden kann nur über dieses eine simple Thema.