Wir bei Veeam lieben Protokolle. Da die meisten unserer Lösungen modular sind, schreiben sie eine Menge Protokolle. Da unser Tätigkeitsbereich die Sicherstellung der Sicherheit Ihrer Daten (also einen ruhigen Schlaf) ist, sollten die Protokolle nicht nur jeden Atemzug festhalten, sondern dies auch recht detailliert tun. Dies ist notwendig, um im Fall der Fälle zu verstehen, wie es zu diesem "Was" gekommen ist, wer schuld ist und was als nächstes zu tun ist. Hier ist es wie in der Kriminalistik: Man weiß nie, welches Detail einem hilft, den Mörder von Laura Palmer zu finden.
Daher habe ich beschlossen, eine Artikelserie zu starten, in der ich der Reihe nach erläutern werde, was wir in Protokolle schreiben, wo wir sie speichern, wie man bei ihrer Struktur nicht verrückt wird und was man innerhalb von ihnen suchen sollte.
Warum eine Artikelserie und warum nicht alles auf einmal beschreiben?
Einfach aufzulisten, welches Protokoll wo liegt und was es enthält, ist eine ziemlich törichte Idee. Darüber nachzudenken, diese Informationen aktuell zu halten, ist noch beängstigender. Eine einfache Auflistung aller möglichen Arten von Protokollen in Veeam Backup & Replication wäre eine Tabelle auf mehreren Seiten in kleiner Schrift. Außerdem wäre sie nur zum Zeitpunkt der Veröffentlichung aktuell, da mit dem Erscheinen des nächsten Patches neue Protokolle hinzukommen und die Logik der gespeicherten Informationen in den alten Protokollen sich ändern könnte usw. Daher wäre es viel vorteilhafter, ihre Struktur und den Inhalt der darin enthaltenen Informationen zu erklären. Das ermöglicht eine bessere Orientierung vor Ort, als einfach nur die Namen auswendig zu lernen.
Um also nicht sofort in den Textdschungel einzutauchen, lassen Sie uns in diesem Artikel einige Vorbereitungsarbeiten durchführen. Daher werden wir heute nicht in die Protokolle eintauchen, sondern aus der Ferne beginnen: Wir erstellen ein Glossar und diskutieren ein wenig die Struktur von Veeam aus der Perspektive der Protokollgenerierung.
Glossar und Fachbegriffe
Hier möchte ich mich zunächst bei den Verfechtern der Reinheit der russischen Sprache und den Zeugen des Wörterbuchs von Oжегов entschuldigen. Wir lieben unsere Sprache, aber die verfluchte IT-Industrie arbeitet auf Englisch. Nun, das haben wir nicht erfunden, das ist historisch so gewachsen. Ich bin nicht schuld, es ist einfach so gekommen.
In unserem Bereich hat das Problem der Anglizismen (und des Jargons) seine eigenen Besonderheiten. Während die ganze Welt unter harmlosen Wörtern wie „Host“ oder „Gast“ schon lange ganz konkrete Dinge versteht, gibt es auf ⅙ der Landmasse noch immer heroische Unordnung und Verwirrung beim Nachschlagen in Wörterbüchern. Und das unverzichtbare Argument „Bei uns in der Firma...“.
Außerdem gibt es unsere eigene Terminologie, die speziell für die Produkte von Veeam ist, obwohl einige Wörter und Formulierungen auch allgemein verwendet werden. Daher werden wir nun festlegen, was welcher Begriff bedeutet, und künftig werde ich unter dem Wort „Gast“ genau das verstehen, was in diesem Kapitel steht, und nicht das, was ihr in eurer Firma gewohnt seid. Und ja, das ist nicht nur mein persönlicher Wunsch, sondern es handelt sich um in der Branche gefestigte Begriffe. Es ist etwas sinnlos, gegen sie zu kämpfen. Obwohl ich immer dafür bin, im Kommentarbereich zu diskutieren.
Leider gibt es in unserer Arbeit und in unseren Produkten extrem viele Begriffe, sodass ich nicht versuchen werde, sie alle aufzulisten. Nur die grundlegendsten und notwendigsten Begriffe, um in einem Meer von Informationen über Backups und Logs zu überleben. Für Interessierte kann ich auch meiner Kollegen über Bänder anbieten, in dem er ebenfalls eine Liste von Begriffen aufgeführt hat, die zu diesem Funktionsbereich gehören.
Host (Host): In der Virtualisierungswelt ist dies ein Gerät mit einem Hypervisor. Physisch, virtuell, in der Cloud – das spielt keine Rolle. Wenn auf etwas ein Hypervisor (ESXi, Hyper-V, KVM etc.) läuft, wird dieses „Etwas“ als Host bezeichnet. Egal, ob es sich um einen Cluster mit zehn Rack-Einheiten oder euren Laptop mit anderthalb virtuellen Maschinen handelt – wenn ihr einen Hypervisor gestartet habt, seid ihr ein Host geworden. Denn der Hypervisor hostet virtuelle Maschinen. Es gibt sogar eine Anekdote, dass VMware damals eine starke Assoziation des Begriffs Host mit ESXi erreichen wollte. Aber sie haben es nicht geschafft.
In der modernen Welt hat sich das Konzept des „Hosts“ praktisch mit dem des „Servers“ verschmolzen, was zu einigen Verwirrungen in der Kommunikation führt, insbesondere wenn es um Windows-Infrastruktur geht. Daher kann jede Maschine, auf der ein für uns interessanter Dienst läuft, ohne Weiteres als Host bezeichnet werden. Zum Beispiel wird in den Logs von WinSock mit dem Wort Host alles Mögliche bezeichnet. Das klassische „Host not found“ ist dafür ein Beispiel. Daher sollten wir den Kontext berücksichtigen, aber dabei bedenken – in der Virtualisierungswelt ist ein Host das, was Gäste hostet (darüber in zwei Zeilen weiter unten).
In Bezug auf lokale Jargonbegriffe (eher sogar Akronyme in diesem Fall) fällt mir ein, dass VMware VI, vSphere VC und Hyper-V HV bedeutet.
Gast (Guest): Eine virtuelle Maschine, die auf einem Host läuft. Hier gibt es sogar nichts weiter zu erklären, so logisch und einfach ist es. Dennoch schleppen viele hier irgendwelche anderen Bedeutungen mit.
Warum? Ich weiß es nicht.
Gast-OS, entsprechend das Betriebssystem der Gastmaschine. Und so weiter.
Backup/Replikation Job (Job): Ein reiner VMware-Jargon, der eine der Aufgaben bezeichnet. Backup job == Backup-Job. Wie man das schön ins Deutsche übersetzt, hat niemand herausgefunden, deshalb sagt jeder „Job“. Mit Betonung auf der letzten Silbe.
Ja, so einfach sagt man einfach „Job“. Und selbst in E-Mails schreibt man so, und alles ist gut.
Alle möglichen Backup-Arbeiten, Backup-Aufträge usw., danke, aber das braucht man nicht. Einfach Job, und man wird verstanden. Das Wichtigste ist, die Betonung auf die letzte Silbe zu legen.
Backup (Backup. Für echte Oldschool-Fans ist auch Bakup erlaubt): Neben dem Offensichtlichen (eine irgendwo liegende Sicherungskopie von Daten) bedeutet es auch die eigentliche Aufgabe (die drei Zeilen zuvor, falls ihr es vergessen habt), infolgedessen die Backup-Datei erstellt wird. Wahrscheinlich sind die englischen Muttersprachler zu faul, um jedes Mal zu sagen I ran my backup job, deshalb sagen sie einfach I ran my backup, und alle verstehen sich hervorragend. Ich schlage vor, dieses großartige Vorhaben zu unterstützen.
Konsolidierung (Consolidate): Ein Begriff, der in ESXi 5.0 auftauchte. Eine Option im Menü zur Arbeit mit Snapshots, die den Prozess des Löschens sogenannter orphaned Snapshots startet. Das sind Snapshots, die physisch vorhanden sind, aber aus der angezeigten logischen Struktur gefallen sind. Theoretisch sollte dieser Prozess die im Snapshot-Manager angezeigten Dateien nicht berühren, aber es kommt vor. Der Kern des Konsolidierungsprozesses besteht darin, dass Daten aus einem Snapshot (Child-Disk) in die Hauptdisk (Parent-Disk) geschrieben werden. Der Prozess der Zusammenführung der Festplatten wird als Mergen bezeichnet. Wenn der Befehl zur Konsolidierung gegeben wurde, kann der Eintrag über den Snapshot aus der Datenbank gelöscht werden, bevor der Snapshot gemerged und gelöscht wird. Und wenn es aus irgendeinem Grund nicht gelungen ist, den Snapshot zu löschen, erscheinen diese orphaned Snapshots. Über die Arbeit mit Snapshots hat VMware ein . Und wir haben auch einmal darüber .
Datenspeicher (Datastore oder Storage): Ein sehr weit gefasster Begriff, aber in der Welt der Virtualisierung versteht man darunter den Ort, an dem die Dateien der virtuellen Maschinen gespeichert sind. In jedem Fall muss man den Kontext sehr klar verstehen und im Zweifelsfall nachfragen, was genau der Gesprächspartner gemeint hat.
Proxy (Proxy): Es ist wichtig, gleich zu verstehen, dass Veeam Proxy nicht ganz das gleiche ist, was wir aus dem Internet gewohnt sind. Innerhalb der Veeam-Produkte ist es eine Art Entität, die Daten von einem Ort an einen anderen überträgt. Kurz gesagt, VBR ist der Server und die Proxys sind seine Arbeitstiere. Das heißt, ein Proxy ist eine Maschine, durch die der Verkehr fließt und auf der die VBR-Komponenten installiert sind, die helfen, den Verkehr zu steuern. Zum Beispiel, um Daten von einem Kanal in einen anderen zu übertragen oder einfach nur Festplatten anzuschließen (HotAdd-Modus).
Repository (Repository): Technisch gesehen ist dies einfach ein Eintrag in der VBR-Datenbank, der auf den Ort hinweist, an dem die Backups gespeichert sind, und wie man sich mit diesem Ort verbindet. Tatsächlich kann es sich um ein einfaches CIFS-Share, eine separate Festplatte, einen Server oder einen Cloud-Bucket handeln. Wieder sind wir im Kontext, verstehen aber, dass ein Repository einfach der Ort ist, an dem Ihre Backups abgelegt sind.
Snapshot (Snapshot): Liebhaber der Oxford-Grammatik bevorzugen zu sagen, wer Snëpshot, wer Snëpshot, jedoch gewinnt die weitgehend analphabetische Mehrheit durch die größere Masse. Wer es nicht weiß – es ist eine Technologie, die es ermöglicht, den Zustand einer Festplatte zu einem bestimmten Zeitpunkt wiederherzustellen. Dies geschieht entweder durch vorübergehende Umleitung von I/O-Operationen weg von der Hauptfestplatte – dann nennt man es einen RoW (Redirect on Write)-Snapshot – oder durch das Verschieben der beschreibbaren Blöcke von Ihrer Festplatte auf eine andere – dies wird als CoW (Copy on Write)-Snapshot bezeichnet. Dank der umfassenden Möglichkeiten zur Anwendung dieser Funktionen kann Veeam seine Backup-Magie entfalten. Streng genommen nicht nur durch sie, aber das ist das Thema der nächsten Versionen.
In der Dokumentation und in den Protokollen von ESXi herrscht rund um diesen Begriff Chaos, und im Zusammenhang mit Snapshots können sowohl die Snapshots selbst als auch die Redo-Logs und sogar Delta-Disks vorkommen. In der Veeam-Dokumentation gibt es diese Verwirrung nicht, ein Snapshot ist ein Snapshot, und ein Redo-Log ist genau das, eine REDO-Datei, die von einem unabhängigen, nicht persistenten Datenträger erstellt wurde. REDO-Dateien werden beim Ausschalten der virtuellen Maschine gelöscht, daher ist es ein Weg zum Scheitern, sie mit Snapshots zu verwechseln.
Synthetic (Synthetisch): Synthetische Backups gehören zu den reverse incremental und forever forward Backups. Falls Sie auf diesen Begriff noch nicht gestoßen sind, handelt es sich einfach um einen der Mechanismen, die zur Umwandlung der Backup-Kette verwendet werden. In den Protokollen kann man jedoch auch den Begriff Transform antreffen, der im Rahmen der Erstellung vollständiger Kopien aus Inkrementen (synthetisches Vollbackup) verwendet wird.
Task (Aufgabe): Dies ist der Prozess, in dem jede einzelne Maschine innerhalb eines Jobs bearbeitet wird. Das heißt: Haben Sie einen Backup-Job, in den drei Maschinen integriert sind, wird jede Maschine im Rahmen einer eigenen Aufgabe bearbeitet. Insgesamt wird es vier Protokolle geben: eines für den Job und drei für die Aufgaben. Es gibt jedoch einen wichtigen Punkt: Im Laufe der Zeit ist das Wort „Aufgabe“ übermäßig mehrdeutig geworden. Wenn wir von allgemeinen Protokollen sprechen, meinen wir, dass die Aufgabe genau die VM ist. Aber es gibt auch „Aufgaben“ auf dem Proxy und auf dem Repository. Dort kann es sowohl eine virtuelle Festplatte, eine virtuelle Maschine als auch den gesamten Job bedeuten. Das heißt, es ist wichtig, den Kontext nicht zu verlieren.
Veeam %name% Service (Dienst): Mehrere Dienste arbeiten für erfolgreiche Backups, deren Liste in der Standardkonsole zu finden ist. Ihre Namen spiegeln recht transparently ihren Zweck wider, jedoch gibt es unter Gleichen den wichtigsten — den Veeam Backup Service, ohne den die anderen nicht funktionieren.
VSS: Technisch gesehen sollte VSS immer den Microsoft Volume Shadow Copy Service bedeuten. Tatsächlich wird es von vielen als Synonym für Application-Aware Image Processing verwendet. Was natürlich kategorisch falsch ist, jedoch ist das eine Geschichte aus der Kategorie „Jeder Geländewagen kann als Jeep bezeichnet werden, und man wird verstanden“.
Fantasievolle Protokolle und Orte, an denen sie leben
Ich möchte dieses Kapitel mit dem großen Geheimnis beginnen — welche Zeit wird in den Protokollen angezeigt?
Merken Sie sich:
- ESXi schreibt Protokolle immer in UTC+0.
- vCenter führt Protokolle nach der Zeit seiner Zeitzone.
- Veeam führt Protokolle nach der Zeit und Zeitzone des Servers, auf dem es installiert ist.
- Und nur Windows-Ereignisse im EVTX-Format sind von keiner Bindung betroffen. Beim Öffnen wird die Zeit auf die Maschine umgerechnet, auf der sie geöffnet wurden. Das ist die bequemste Variante, obwohl es auch hier Schwierigkeiten gibt. Die einzige spürbare Schwierigkeit ist der Unterschied in den Locale-Einstellungen. Das ist praktisch ein garantierter Weg zu unlesbaren Logs. Ja, es gibt Möglichkeiten, dies zu beheben, aber lassen Sie uns einfach nicht darüber streiten, dass alles in der IT auf Englisch läuft, und uns darauf einigen, immer die englische Locale auf den Servern einzustellen. Bitte.
Jetzt sprechen wir dennoch über die Orte, an denen die Logs gespeichert sind, und wie man sie erhält. Im Fall von VBR gibt es zwei Ansätze.
Die erste Variante eignet sich, wenn Sie nicht den Wunsch haben, in einer allgemeinen Ansammlung von Dateien nach denjenigen zu suchen, die sich auf Ihr Problem beziehen. Dafür haben wir einen separaten Wizard, dem Sie einen konkreten Job und einen bestimmten Zeitraum angeben können, für den Sie die Logs benötigen. Danach wird er selbstständig durch die Ordner laufen und alles Benötigte in einem Archiv zusammenstellen. Details dazu, wo man ihn sucht und wie man mit ihm arbeitet, sind ausführlich beschrieben in .
Der Wizard sammelt jedoch nicht die Logs aller Aufgaben, und wenn Sie beispielsweise die Logs von Restaurant-, Failover- oder Failback-Vorgängen studieren müssen, führt Ihr Weg in den Ordner %ProgramData%/Veeam/Backup. Dies ist der Hauptlogspeicher von VBR, und %ProgramData% ist ein versteckter Ordner, was normal ist. Übrigens kann der Standardspeicherort mithilfe eines Registry-Schlüssels vom Typ REG_SZ: LogDirectory im Zweig HKEY_LOCAL_MACHINE\SOFTWARE\Veeam\Veeam Backup and Replication umbenannt werden.
Auf Linux-Maschinen sollten die Logs der Arbeitsagenten in/var/log/VeeamBackup/gesucht werden, wenn ein root- oder sudo-Konto verwendet wird. Wenn Sie diese Privilegien nicht haben, suchen Sie die Logs in /tmp/VeeamBackup.
Für den Veeam Agent für %OS_name% müssen die Logs in %ProgramData%/Veeam/Endpoint (oder %ProgramData%/Veeam/Backup/Endpoint) und /var/log/veeam entsprechend.
Wenn Sie Application-Aware Image Processing verwenden (was wahrscheinlich der Fall ist), wird die Situation etwas komplizierter. Sie benötigen die Logs unseres Helpers, die innerhalb der virtuellen Maschine gespeichert sind, und die VSS-Logs. Wie und wo Sie dieses Glück beschaffen können, ist ausführlich beschrieben in . Und natürlich gibt es zum Sammeln der erforderlichen Systemlogs.
Windows-Ereignisse lassen sich bequem gemäß sammeln. Wenn Sie Hyper-V verwenden, wird es komplizierter, da Sie auch alle Logs aus dem Zweig Applications and Service Logs > Microsoft > Windows benötigen. Obwohl man immer den groberen Weg gehen kann, und einfach alle Objekte aus %SystemRoot%\System32\winevt\Logs abrufen kann.
Wenn während der Installation/Upgrade etwas kaputtgeht, finden Sie alles Notwendige im Ordner %ProgramData%/Veeam/Setup/Temp. Ich will nicht verschweigen, dass in den Ereignissen des Betriebssystems nützlichere Informationen zu finden sind als in diesen Logs. Interessante Informationen finden sich auch im %Temp%, doch dort sind hauptsächlich Protokolle der Installation von Begleitsoftware wie Datenbanken, .Net-Bibliotheken und Ähnlichem. Bedenken Sie, dass Veeam über msi installiert wird und alle seine Komponenten ebenfalls als separate msi-Pakete installiert werden, auch wenn dies nicht im GUI angezeigt wird. Folglich, wenn die Installation eines der Komponenten fehlschlägt, wird die gesamte VBR-Installation gestoppt. Daher muss man in die Logs schauen und herausfinden, was genau kaputtgegangen ist und zu welchem Zeitpunkt.
Und hier ein Lifehack zum Schluss: Wenn Sie bei der Installation eine Fehlermeldung erhalten, eilen Sie nicht, um auf OK zu drücken. Zuerst die Logs holen, dann auf OK drücken. So erhalten Sie das Log, das genau zu dem Zeitpunkt endet, an dem der Fehler aufgetreten ist, ohne unnötigen Ballast am Ende.
Es kommt auch vor, dass man in die vSphere-Logs schauen muss. Eine sehr undankbare Aufgabe, aber man muss auch solche Dinge mit hochgekrempelten Ärmeln erledigen. Im einfachsten Fall benötigen wir die Logs mit den Ereignissen der virtuellen Maschine vmware.log, die neben der .vmx-Datei zu finden sind. In komplizierteren Fällen öffnen wir Google und fragen, wo die Logs für Ihre Version des Hosts liegen, da VMware es liebt, diesen Speicherort von Version zu Version zu ändern. Hier, zum Beispiel, , und hier für . Für die vCenter-Logs wiederholen wir das Verfahren . Im Allgemeinen interessieren uns die Logs der Hostereignisse hostd.log, die Ereignisse der Hosts, die von vCenter verwaltet werden, vpxa.log, die Kernel-Protokolle vmkernel.log und die Authentifizierungsprotokolle auth.log. Und in den schlimmsten Fällen kann das SSO-Protokoll nützlich sein, das im SSO-Ordner liegt.
Umständlich? Verwirrend? Beängstigend? Und das ist noch nicht einmal die Hälfte der Informationen, mit denen unser Support täglich arbeitet. Sie sind wirklich sehr gut.
Veeam-Komponenten
Und als Abschluss dieses einführenden Artikels sprechen wir ein wenig über die Komponenten von Veeam Backup & Replication. Denn wenn man nach den Ursachen von Problemen sucht, wäre es nicht schlecht zu verstehen, wie der Patient aufgebaut ist.
Also, wie vielen bekannt sein dürfte, ist Veeam Backup eine sogenannte SQL-basierte Anwendung. Das bedeutet, dass alle Einstellungen, alle Informationen und im Grunde alles, was für ein reibungsloses Funktionieren notwendig ist, sich in seiner Datenbank befindet. Genauer gesagt in zwei Datenbanken, wenn wir über die Kombination von VBR und EM sprechen: VeeamBackup und VeeamBackupReporting, entsprechend. So ist es Brauch: Installieren wir eine weitere Anwendung, entsteht eine weitere Datenbank. Um nicht alle Eier in einen Korb zu legen.
Damit dieses Ganze harmonisch funktioniert, benötigen wir eine Reihe von Diensten und Anwendungen, die alle Komponenten miteinander verbinden. Nur als Beispiel, so sieht es in einem meiner Labore aus:
In der Rolle des Hauptdirigenten fungiert Veeam Backup Service. Er ist verantwortlich für den Informationsaustausch mit den Datenbanken. Außerdem überwacht er den Start aller Aufgaben, kümmert sich um die Orchestrierung der bereitgestellten Ressourcen und fungiert als Kommunikationszentrale für verschiedene Konsolen, Agenten und alles andere. Kurz gesagt, ohne ihn geht es nicht, aber das bedeutet keineswegs, dass er alles allein macht.
Bei der Umsetzung seiner Aufgaben wird er unterstützt von Veeam Backup Manager. Dies ist kein Dienst, sondern eine Entität, die für den Start der Jobs verantwortlich ist und den Fortschritt ihrer Ausführung überwacht. Die Arbeitskraft des Backup-Dienstes, die sich mit den Hosts verbindet, Snapshots erstellt, den Retention-Status überwacht und so weiter.
Kommen wir zurück zur Liste der Dienste. Veeam Broker Service. Er erschien in v9.5 (und das ist kein Krypto-Miner, wie einige damals dachten). Er sammelt Informationen über VMware-Hosts und hält diese aktuell. Aber rennt nicht sofort los, um wütende Kommentare zu schreiben, dass wir euch ausspionieren und alle eure Logins/Passwörter an Taumajor weitergeben. Es ist alles etwas einfacher. Wenn ihr ein Backup startet, müsst ihr zunächst eine Verbindung zum Host herstellen und alle Daten über seine Struktur aktualisieren. Das ist eine ziemlich langsame und aufwendige Angelegenheit. Denkt nur daran, wie lange bei euch der Anmeldevorgang über die Web-Oberfläche dauert, und denkt daran, dass dort nur die oberste Schicht berücksichtigt wird. Und dann müsst ihr auch noch die gesamte Hierarchie bis zum gewünschten Punkt aufschlüsseln, übrigens. Zusammengefasst: schrecklich. Wenn ihr ein Dutzend Backups startet, muss jeder Job dieses Verfahren durchlaufen. Bei großen Infrastrukturen kann dieser Prozess zehn Minuten oder mehr in Anspruch nehmen. Deshalb wurde entschieden, dafür einen eigenen Service bereitzustellen, über den man immer aktuelle Informationen erhalten kann. Er überprüft und scannt zu Beginn die gesamte hinzugefügte Infrastruktur und versucht dann, nur auf der Ebene inkrementeller Änderungen zu arbeiten. So dass selbst wenn bei euch gleichzeitig hundert Backups starten, sie alle Informationen von unserem Broker anfordern, anstatt die Hosts mit ihren Anfragen zu belasten. Wenn ihr euch um die Ressourcen sorgt, dann müssen wir schätzen, dass man für 5000 VMs nur etwa 100 Mb RAM benötigt.
Dann haben wir Veeam Console. Auch bekannt als Veeam Remote Console oder Veeam.Backup.Shell. Das ist die GUI, die wir auf den Screenshots sehen. Es ist alles einfach und offensichtlich - die Konsole kann von überall gestartet werden, solange es ein Windows-System ist und eine Verbindung zum VBR-Server besteht. Das einzige, was man sagen kann: Der FLR-Prozess wird Punkte lokal mounten (d.h. auf der Maschine, auf der die Konsole läuft). Nun, und die verschiedenen Veeam Explorers werden ebenfalls lokal gestartet, da sie Teil der Konsole sind. Aber das führt mich schon in die Tiefe…
Der nächste interessante Service ist Veeam Backup Catalog Data Service. Im Serviceverzeichnis bekannt als Veeam Guest Catalog Service. Er kümmert sich um die Indizierung von Dateisystemen auf Gastmaschinen und füllt den VBRCatalog-Ordner mit diesen Informationen. Wird nur dort eingesetzt, wo die Indizierungsoption aktiviert ist. Sie sollten sie nur aktivieren, wenn Sie über Enterprise Manager verfügen. Daher der aufrichtige Rat: Aktivieren Sie die Indizierung nicht einfach so, wenn Sie keinen EM haben. Schützen Sie Ihre Nerven und die Zeit des Supports.
Außerdem sind weitere wichtige Dienste zu erwähnen Veeam Installer Service, mit dessen Hilfe die erforderlichen Komponenten auf Proxys, Repositories und anderen Gateways geliefert und installiert werden. Tatsächlich transportiert er die benötigten .msi-Pakete zu den Servern und führt deren Installation durch.
Veeam Data Mover — mithilfe von auf Proxys (und nicht nur) ausgeführten Hilfsagenten befasst er sich mit dem Verschieben von Daten. Beispielsweise wird bei einem Backup ein Agent die Dateien von den Datenspeichern des Hosts lesen, während ein anderer sie präzise ins Backup schreiben wird.
Besonders hervorzuheben ist eine wichtige Sache, auf die viele Kunden oft reagieren — die Unterschiede in den Versionen der Dienste und in der Anzeige „Programme und Funktionen“. Ja, die Liste wird identisch sein, aber die Versionen können völlig unterschiedlich sein. Das sieht aus visueller Sicht nicht so gut aus, ist jedoch völlig normal, wenn alles stabil funktioniert. Zum Beispiel, die Versionsnummer des Installer-Dienstes hinkt stark hinter den Nachbarn her. Horrorgeschichte? Nein, denn er wird nicht vollständig neu installiert, sondern lediglich sein DLL wird aktualisiert. Im Patch v9.5 U4 erlebte der Support einen Albtraum: Bei der Aktualisierung erhielten alle Dienste neue Versionen, nur der wichtigste nicht. Im Patch U4b überholte der Transportdienst alle anderen um gleich zwei Versionen (wenn man die Zahlen betrachtet). Und das ist auch normal — darin wurde ein schwerwiegender Bug gefunden, weshalb er ein zusätzliches Update im Vergleich zu den anderen erhielt. Daher, zusammenfassend gesagt: Unterschiedliche Versionen KÖNNEN ein Problem darstellen, aber wenn Unterschiede vorhanden sind und alles reibungslos funktioniert, ist es wahrscheinlich so, wie es sein sollte. Doch niemand hindert Sie daran, dies beim Support zu klären.
Das waren die sogenannten obligatorischen oder Mandatory Services. Daneben gibt es noch eine ganze Reihe von Hilfsdiensten, wie Tape Service, Mount Service, vPowerNFS Service und so weiter.
Für Hyper-V ist im Grunde alles dasselbe, nur gibt es spezifisch Veeam Backup Hyper-V Integration Service und seinen eigenen Treiber für die CBT-Integration.
Und am Ende sprechen wir darüber, wer während des Backups auf den virtuellen Maschinen arbeitet. Für das Ausführen von Pre- und Post-Freeze-Skripten, das Erstellen von Shadow-Copies, das Sammeln von Metadaten, die Arbeit mit SQL-Transaktionsprotokollen und mehr wird Veeam Guest Helperverwendet. Und wenn die Indizierung von Dateisystemen erfolgt, Veeam Guest Indexer , handelt es sich um temporäre Dienste, die während des Backups bereitgestellt und danach wieder entfernt werden.
Bei Linux-Systemen ist alles viel einfacher, da es viele integrierte Bibliotheken und Funktionen des Systems gibt. Zum Beispiel erfolgt die Indizierung über mlocate.
Das wäre vorerst alles.
Ich möchte Sie nicht weiter quälen und beende das kurze Einführung in den Inneren von Veeam. Ja, wir sind noch nicht einmal annähernd zu den Protokollen gekommen, aber glauben Sie mir, um die Informationen, die sie enthalten, nicht als zusammenhangloser Strom des Bewusstseins erscheinen zu lassen, ist eine solche Einleitung auf jeden Fall notwendig. Ich plane, erst im dritten Artikel zu den Protokollen überzugehen, und mein Plan für den nächsten Artikel ist es, zu erklären, wer die Protokolle generiert, was genau darin angezeigt wird und warum es so und nicht anders ist.
Quelle: habr.com
