Wie bei jedem Backup System gibt es auch bei Veeam Backup einige Begrifflichkeiten die vielleicht nicht jeder kennt.
Ich habe früher Symantec Backup Exec bei vielen Kunden eingesetzt oder Acronis Produkte. Da kannte ich z.B. den Begriff Repository noch nicht den ich aber dann bei Veeam kennengelernt habe.
Mit diesem Artikel möchte ich ein paar Begrifflichkeiten von Veeam erklären. Meistens nur zum Verständniss. Ich möchte bei einigen Dingen auch nicht zu tief in die Materie gehen. Viele der Begrifflichkeiten finden sich heute auch in den zahllosen anderen Backupsystemen wieder. Sind also nicht speziell auf Veeam B&R bezogen.
Repository: Das ist einfach nur der Speicherort von den einzelnen Backupdaten. Das kann alles mögliche sein. Eine USB-Festplatte, lokale Festplatten, eine NAS oder ein SAN aber auch ein Cloudspeicher. Man kann 1 oder mehrere Repositorys verwenden. Seit der V9 gibt es auch ein sog. Scaleout Repository. Hier fast man einfach mehrere Speicherorte unterschiedlichster Größe und Typ zusammen und B&R legt selbständig die Backupdateien optimal ab. Man hat dadurch quasi einen großen Speicherplatz. Vor der V9 habe ich z.B. 2 Repositorys im Einsatz gehabt. Eines auf Laufwerk C: und eines auf D:
In den Backupjobs in Veeam gibt man dann das jeweilige Repository an, wo es die Backup Dateien ablegen soll.
Fullbackup/Incrementalbackup/Reverseincremental:
B&R kennt eigentlich nur 2 Backupverfahren, Full- und Incremetal Backups. Am Anfang gibt es wie bei jedem anderen Backupsystem immer ein Fullbackup (Dateiendung .vbk). Hier wird die gesamte VM gesichert.
Beim nächsten Backup wird ein Incremental Backup gefahren (Dateiendung .vib). Dabei wird immer zum vorherigen Backup nur die Änderungen von Blöcken gesichert was sehr platzsparend ist und auch sehr schnelle Backups ermöglicht. B&R kennt noch ein paar Spezialvarianten dazu komme ich aber speziel in einem Artikel, der sich nur um die Backupmodi kümmert. Differental Backups kennen viele andere Backupsysteme, B&R aber nicht. Beim differential Backup wird auch erst ein Fullbackup erzeugt, dann ein differentielles Backup. Also der unterschied zum Fullbackup. Am 3. Tag wird wieder ein diff. Backup erzeugt welches wieder alle Änderungen zum Fullbackup hält. Es wächst also in der Regel jeden Tag an und auch die Backupzeit steigt jeden Tag etwas an.
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.
Woran das liegt? Erkläre ich mal in einem anderen Eintrag. Ich wollte ja nicht zu tief gehen.
Komprimieren und Deduplizieren: Ich will auch hier eigentlich nicht zu tief in die Materie einsteigen weil dann wird dieser Artikel hier dutzende Seiten lang. Wichtig wären mir noch diese beiden Begrifflichkeiten grob zu klären. Komprimieren ist wahrscheinlich jedem klar der schon mal Dateien mit ZIP/RAR oder 7zip gepackt hat. B&R kann während des Backups die Blöcke, die gesichert werden gleich packen/komprimieren. Dabei stehen verschieden starke Modi zur Verfügung.
Das höchste ist dabei nicht unbedingt das Beste. In meinen Test´s wurden in der höchsten Stufe (Extreme) die Dateien nur unwesentlich kleiner aber das Backup lief deutlich länger.
Ich fahre meine Backups alle auf der Stufe (High). Das ist ein guter Kompromiss zwischen Backupgröße und Backupzeiten.
Deduplizieren ist ein interessantes Thema aber wenn man sich im Bekanntenkreis umhört kann fast keiner was damit anfangen.
B&R kann die zu sichernden Blöcke deduplizieren. Das heißt, gleiche Blöcke, also mit gleichem Inhalt werden zusammengefasst und im Backup nur 1x gehalten. Hat man z.B. auf einem Fileserver zig mal die gleiche Datei liegen wird diese auch nur 1x im Backup gehalten. Die anderen Dateien gehen deswegen aber nicht verloren. Bei einem Restore wird wieder alles richtig zusammengesetzt. Dies nennt man bei B&R Inlinededuplizierung weil es sich innerhalb einer VM abspielt. Da B&R Blöcke sichert müssen es auch nicht immer gleiche Dateien sein. Hat man z.B. einen Exchange Server im Einsatz dann liegen in der einen Datenbank sicherlich zahllose Mails und Dateianhänge mehrfach vor. Die DB wird in viele Blöcke zerteilt. Findet B&R jetzt gleiche Blöcke, werden diese auch 1x gesichert.
Zusätzlich kennt B&R auch noch die Möglichkeit alle VM´s innerhalb eines Backup Jobs zu deduplizieren.
Wenn man z.B. in einem Backupjob 5 VM´s sichert. Jede VM läuft unter Server 2016 dann spart man sich schon jede Menge Platz weil z.B. das Windows Verzeichnis mit seinen unzähligen DLL.Dateien nur 1x gesichert wird. Deswegen kann es von Vorteil sein, in die Backupjobs, Server reinzupacken, die unter dem gleichen Betriebssystem laufen.
Auch hier gibt es wieder Einstellmöglichkeiten. Wir stark die Deduplizierung verwendung finden soll.
Beim Deduplizieren habe ich keine großartigen Ersparnisse bei den unterschiedlichen Modi feststellen können. Ich verwende die Einstellung (Lan-Target). Komprimieren und Deduplizieren arbeiten schneller je schneller die CPU ist. Hier spielen die Ghz die gleiche Rolle wie die Anzahl der Kerne. Veeam B&R nutzt hier sehr stark die CPU und Ihre Möglichkeiten aus.
Restorepoints: B&R spicht bei der Anzahl der Backups nicht von Backupdateien oder von Tagen/Wochen etc. an denen gesichert wird sondern von sog. Restorepoints.
Ein Restorepoint entspricht einer Backupdatei. Kann also eine Vollbackupdatei (.vbk) sein aber auch einen incrementelle Datei (.vib). In B&R legt man nicht fest, dass man 20 Tage vorhalten will, nein, man legt die Anzahl der Restorepoints fest. Stellt man also z.B. 20 ein und sichert jeden Tag dann kann man auch 20 Tage zurückgreifen weil 20 Backupdateien auf dem Repository liegen. Sichert man aber 2x am Tag kann man nur 10 Tage zurückgreifen. Es werden auch nur 20 Restorepoints erzeugt. Man muss hier also immer selbst rechnen wie viele Tage man einen Restore haben möchte und muss die nötige Anzahl von Restorepoints festlegen. Im Artikel über die Backupmodi erkläre ich noch im Detail warum man irgendwann mal 40 oder mehr Dateien im Repository liegen hat obwohl man doch nur 20 eingetragen hat.
Bitlooker: nicht zu verwechseln mit MS Bitlocker, dem Dateiverschlüsselungssystem. Bitlooker wurde mit V9 eingeführt und ist auf Servern wo viele Dateien hinzukommen und gelöscht werden eine große Bereicherung. Seit ich Bitlooker aktiviert hatte, schrumpften meine Backupdateien um fast 50%.
Wie weiter oben schon beschrieben sichert B&R Blöcke. Löscht man auf einem Server viele Dateien bekommt dies B&R eigentlich nicht mit und sichert weiterhin die Blöcke wo es Dateien vermutet.
Wenn man unter Windows Daten löscht werden die ja nicht mit Nullen überschrieben sondern nur als gelöscht gekennzeichnet. Somit ändern sich nach dem Löschen auch nicht die Blöcke. Durch Bitlooker erkennt die Software jetzt aber diese gelöschten Dateien und lässt die passenden Blöcke beim Sichern aus.
Die Funktion kann auch deaktiviert werden.
Backup Job: In B&R legt man einen oder mehrere Backupjobs an. In einem Job definiert man dann welche Server man sichern möchte, welche Komprimierung/Dedup. man einsetzen will, die Anzahl der Restorepoints, das Repository und wann der Job laufen soll.
Ich halte es aktuell eigentlich so, dass ich mehrere Jobs habe, aufgeteilt auf die Art der Systeme.
Also z.B. Job 1 für alle Fileserver, Job 2 für die Terminalserver, Job 3 für die Mailserver etc.
Die Jobs lasse ich dann hintereinander laufen. Dies kann man in B&R einstellen. Ist Job 1 fertig, startet autom. Job2 . Hier stellt aber jeder bestimmt nach eigenen Vorstellungen etwas anderes ein. Veeam selbst schlägt, glaube ich, vor, alle Job´s gleichzeitig zu starten. Die Software kümmert sich dann selbst um die richtige Verteilung der Ressourcen. Man kann dies nämlich zentral einstellen wie viele Server gleichzeitig gesichert werden sollen/können. Das hängt ab vom Zielsystem und der Anzahl der Kerne.
Je nach Server Größe würde ich abraten, einen einzigen Job zu erstellen. Man ist dann manchmal etwas unflexibel wenn man Backupdateien von meheren TB hat. Vorallem wenn man diese dann noch auf Tape sichert. Bei einem Restore kann es ewig dauern bis man die Daten vom Band geladen hat.
So, dass war´s erst einmal mit den Begrifflichkeiten.
