Bei Veeam lieben wir Protokolle. Da die meisten unserer Lösungen modular sind, produzieren sie entsprechend viele Protokolle. Unser Ziel ist es, die Sicherheit Ihrer Daten zu gewährleisten, damit Sie ruhig schlafen können. Daher sollten die Protokolle nicht nur jedes kleinste Ereignis erfassen, sondern dies auch detailliert tun. Es ist entscheidend, um im Falle eines Problems nachzuvollziehen, wie es dazu gekommen ist, wer verantwortlich ist und was als Nächstes zu tun ist. Hier gilt die Logik der Kriminalistik: Man weiß nie, welches Detail Ihnen helfen könnte, den Mörder von Laura Palmer zu finden.
Deshalb habe ich beschlossen, eine Serie von Artikeln zu beginnen, in denen ich systematisch erläutere, was wir in die Protokolle schreiben, wo wir sie speichern, wie man den Überblick über ihre Struktur behält und wonach man darin suchen sollte.
Warum eine Artikelsserie und warum nicht alles auf einmal beschreiben?
Es wäre eine ziemlich mühsame Aufgabe, einfach nur aufzulisten, wo welches Log zu finden ist und was darin enthalten ist. Und daran zu denken, diese Informationen auf dem neuesten Stand zu halten, ist schon beängstigend. Eine einfache Aufzählung aller möglichen Logarten in Veeam Backup & Replication würde mehrere Seiten in kleiner Schrift umfassen. Und sie wäre auch nur zum Zeitpunkt der Veröffentlichung relevant, denn mit dem nächsten Patch könnten neue Logdateien hinzukommen oder sich die Logik der gespeicherten Informationen in den alten Dateien ändern, und so weiter. Deshalb ist es viel vorteilhafter, ihre Struktur und den Inhalt der Informationen, die sie enthalten, zu erklären. Das ermöglicht eine bessere Orientierung vor Ort, als das bloße Auswendiglernen von Bezeichnungen.
Um also nicht kopfüber in den Strudel der Textmengen zu springen, lassen Sie uns in diesem Artikel eine gewisse Vorarbeit leisten. Deshalb werden wir heute nicht direkt auf die Logs selbst eingehen, sondern uns aus der Ferne nähern: Wir erstellen ein Glossar und besprechen ein wenig die Struktur von Veeam aus der Perspektive der Loggenerierung.
Glossar und Fachbegriffe
Hier möchte ich mich zunächst bei den Verfechtern der Reinheit der deutschen Sprache und den Zeugen des Wörterbuchs von Duden entschuldigen. Wir alle lieben unsere Muttersprache sehr, aber die verdammte IT-Branche arbeitet auf Englisch. Nun, das haben wir nicht erfunden, sondern es hat sich historisch so ergeben. Ich bin unschuldig, es kam von selbst.
In unserem Geschäft hat das Problem der Anglizismen (und des Jargons) seine eigene Spezifik. Wenn die Welt unter harmlosen Worten wie 'Host' oder 'Gast' längst ganz konkrete Dinge versteht, gibt es auf ⅙ der Erdoberfläche eine heroische Zerrissenheit und Unsicherheit mit dem Stochern in Wörterbüchern. Und das streng zwingende Argument: 'Aber bei uns im Job...'.
Außerdem gibt es spezifische Terminologie, die ausschließlich mit Veeam-Produkten verbunden ist, obwohl einige Wörter und Wendungen in die Allgemeinsprache übergegangen sind. Daher werden wir jetzt klarstellen, was jeder Begriff bedeutet, und künftig werde ich beim Wort 'Gast' genau das im Sinn haben, was in diesem Kapitel geschrieben steht, und nicht das, was Sie gewöhnlich bei Ihrer Arbeit verwenden. Und ja, das ist keine persönliche Laune von mir, sondern etablierte Begriffe in der Branche. Es ist etwas sinnlos, dagegen zu kämpfen. Obwohl ich immer bereit bin, in den Kommentaren zu diskutieren.
Leider gibt es in unserer Arbeit und unseren Produkten unglaublich viele Begriffe, daher werde ich nicht versuchen, sie alle aufzulisten. Ich nenne nur die grundlegenden und notwendigen, um im Meer der Informationen über Backups und Logs zu überleben. Für Interessierte kann ich auch meines Kollegen über Begriffe anbeiten, in dem er auch eine Liste von Begriffen zu diesem Funktionalitätsbereich anführt.
Host (Host): In der Virtualisierungswelt ist dies eine Maschine mit einem Hypervisor. Ob physisch, virtuell oder in der Cloud — das spielt keine Rolle. Wenn ein Hypervisor (ESXi, Hyper-V, KVM usw.) auf etwas läuft, wird dieses „Etwas“ als Host bezeichnet. Sei es ein Cluster mit zehn Racks oder Ihr Laptop mit einer Testumgebung auf anderthalb virtuellen Maschinen — sobald Sie einen Hypervisor gestartet haben, sind Sie ein Host. Denn der Hypervisor hostet virtuelle Maschinen. Es gibt sogar die Anekdote, dass VMware einst eine starke Assoziation des Begriffs Host speziell mit ESXi erreichen wollte. Aber das hat nicht geklappt.
In der heutigen Welt sind die Begriffe „Host“ und „Server“ praktisch identisch geworden, was zu Verwirrung in Gesprächen führt, insbesondere wenn es um Windows-Infrastrukturen geht. Jede Maschine, auf der ein für uns interessanter Dienst läuft, kann daher getrost als Host bezeichnet werden. Zum Beispiel wird im WinSock-Log der Begriff Host für alles Mögliche verwendet. Ein klassisches Beispiel ist „Host nicht gefunden“. Wir müssen also den Kontext berücksichtigen, aber denken wir daran: In der Welt der Virtualisierung ist ein Host das, was Gäste hostet (wie zwei Zeilen weiter unten beschrieben).
Unter den lokalen Jargons (oder genauer gesagt, Akronymen in diesem Fall) fallen hier Begriffe wie VMware – VI, vSphere – VC und Hyper-V – HV.
Guest (Gast): Eine virtuelle Maschine, die auf einem Host arbeitet. Hier ist die Erklärung so klar und einfach, dass es kaum einer weiteren Erläuterung bedarf. Dennoch gibt es viele, die versuchen, andere Bedeutungen hinein zu bringen.
Warum? Ich weiß es nicht.
Guest OS bezieht sich entsprechend auf das Betriebssystem der Gastmaschine. Und so weiter.
Backup/Replication Job (Job): Ein reiner VMware-Jargon, der eine der Aufgaben beschreibt. Backup-Job == Backup-Job. Wie man das elegant ins Deutsche übersetzen kann, hat bisher niemand herausgefunden, deshalb sagt einfach jeder „Job“. Mit Betonung auf der letzten Silbe.
Ja, so einfach sagen sie «Job». Sie schreiben das sogar in E-Mails, und alles ist gut.
Verschiedene Backup-Arbeiten, Backup-Aufträge usw. Danke, aber das brauchen wir nicht. Einfach Job, und man wird verstanden. Das Wichtigste ist, die Betonung auf die letzte Silbe zu setzen.
Backup (Backup, für echte Alte: Bakup): Neben dem Offensichtlichen (eine vorhandene Datensicherung) bedeutet es auch den eigentlichen Job (drei Zeilen oben, falls ihr es schon vergessen habt), durch den die besagte Backup-Datei entsteht. Wahrscheinlich sind die englischen Muttersprachler zu faul, um jedes Mal zu sagen: I ran my backup job, also sagen sie einfach I ran my backup, und jeder versteht sich gut. Ich schlage vor, dieses großartige Vorhaben zu unterstützen.
Konsolidierung (Konsolidierung): Ein Begriff, der in ESXi 5.0 eingeführt wurde. Eine Option im Snapshot-Menü, die den Prozess zum Entfernen sogenannter verwaister Snapshots startet. Das sind Snapshots, die physisch vorhanden sind, aber aus der angezeigten logischen Struktur herausgefallen sind. Theoretisch sollte dieser Prozess die im Snapshot-Manager angezeigten Dateien nicht beeinträchtigen, aber das passiert manchmal. Der Kern des Konsolidierungsprozesses besteht darin, dass die Daten aus dem Snapshot (Child-Disk) auf die Hauptdisk (Parent-Disk) geschrieben werden. Der Vorgang des Zusammenführens der Disks wird als Merge bezeichnet. Wenn der Konsolidierungsbefehl erteilt wurde, kann der Snapshot-Eintrag aus der Datenbank gelöscht werden, bevor der Snapshot zusammengeführt und entfernt wird. Wenn der Snapshot aus irgendeinem Grund nicht gelöscht werden kann, entstehen diese verwaisten Snapshots. VMware hat Informationen zur Arbeit mit Snapshots in einem . Und wir haben auch einmal darüber .
Datastore (Speicherorte oder Storage): Ein sehr umfassender Begriff, jedoch versteht man in der Virtualisierungswelt darunter den Ort, an dem die Dateien von virtuellen Maschinen gespeichert werden. In jedem Fall muss man hier den Kontext sehr genau verstehen und bei geringsten Zweifeln klären, was genau der Gesprächspartner meint.
Proxy (Proxy): Es ist wichtig, von Anfang an zu verstehen, dass Veeam Proxy nicht ganz das ist, was wir aus dem Internet gewohnt sind. Innerhalb der Produkte von Veeam ist es eine Entität, die dafür verantwortlich ist, Daten von einem Ort an einen anderen zu verschieben. Einfach ausgedrückt, VBR ist der Steuerungsserver, während der Proxy seine Arbeitspferde sind. Der Proxy ist also die Maschine, durch die der Datenverkehr fließt und auf der die VBR-Komponenten installiert sind, die dabei helfen, diesen Datenverkehr zu steuern. Zum Beispiel kann es Daten von einem Kanal in einen anderen verschieben oder einfach Festplatten (HotAdd-Modus) anschließen.
Repository (Repository): Technisch gesehen ist das einfach ein Eintrag in der VBR-Datenbank, der angibt, wo die Backups gespeichert sind und wie man auf diesen Speicherort zugreifen kann. Das kann sowohl ein einfaches CIFS-Share als auch eine separate Festplatte, ein Server oder ein Bucket in der Cloud sein. Wir befinden uns wieder im Kontext, aber das Wichtigste ist, dass das Repository einfach der Ort ist, an dem Ihre Backups liegen.
Snapshot (Snapshot): Liebhaber der Oxford-Grammatik bevorzugen es, entweder "Schnappschuss" oder "SnapShot" zu sagen, doch die ungebildete Mehrheit hat durch ihre größere Masse die Oberhand. Wer nicht weiß, was das ist: Es handelt sich um eine Technologie, die es ermöglicht, den Zustand einer Festplatte zu einem bestimmten Zeitpunkt wiederherzustellen. Dies geschieht entweder durch temporäre Umleitung von I/O-Vorgängen weg von der Hauptfestplatte – das wird als RoW (Redirect on Write) Schnappschuss bezeichnet – oder indem überschreibbare Blöcke von Ihrer Festplatte auf eine andere verschoben werden – das wird als CoW (Copy on Write) Schnappschuss bezeichnet. Gerade die vielfältigen Anwendungsmöglichkeiten dieser Funktionen ermöglichen Veeam, seine Backup-Magie zu entfalten. Streng genommen nicht nur ihnen, sondern auch in nahen Releases.
In der Dokumentation und den Protokollen von ESXi gibt es rund um diesen Begriff Chaos, und im Kontext von Schnappschüssen begegnet man sowohl den Schnappschüssen selbst als auch Redo-Logs und sogar Delta-Disks. In der Dokumentation von Veeam gibt es solchen Durcheinander nicht; hier ist ein Schnappschuss ein Schnappschuss, und ein Redo-Log ist genau das, eine REDO-Datei, die von einer unabhängigen, nicht persistierenden Disk erstellt wurde. REDO-Dateien werden beim Ausschalten der virtuellen Maschine gelöscht, sodass es ein Fehler wäre, sie mit Schnappschüssen zu verwechseln.
Synthetisch: Synthetische Backups gehören zu den reverse incremental und forever forward Backups. Falls Sie mit diesem Begriff noch nicht vertraut sind, handelt es sich dabei um einen Mechanismus zur Erstellung einer Backup-Kette. In den Protokollen finden Sie auch den Begriff Transform, der im Rahmen der Erstellung vollständiger Kopien aus Inkrementen (synthetisches Voll-Backup) verwendet wird.
Aufgabe (Task): Dies ist der Prozess der Verarbeitung jeder einzelnen Maschine innerhalb des Jobs. Wenn Sie also einen Backup-Job haben, der drei Maschinen umfasst, wird jede Maschine in einer separaten Aufgabe verarbeitet. Insgesamt gibt es vier Protokolle: eines für den Job und drei für die Aufgaben. Hierbei gibt es jedoch einen wichtigen Aspekt: Der Begriff „Aufgabe“ ist im Laufe der Zeit mehrdeutig geworden. Wenn wir von allgemeinen Protokollen sprechen, meinen wir, dass eine Aufgabe genau die VM ist. Es gibt jedoch auch eigene „Aufgaben“ für den Proxy und das Repository. Dort kann es sowohl eine virtuelle Festplatte, eine virtuelle Maschine als auch den gesamten Job bedeuten. Es ist wichtig, den Kontext nicht zu verlieren.
Veeam %name% Dienst (Service): Für erfolgreiche Backups arbeiten mehrere Dienste gleichzeitig, deren Liste in den Standardwerkzeugen zu finden ist. Ihre Namen spiegeln ihren Zweck ziemlich transparent wider, jedoch gibt es unter ihnen einen besonders wichtigen – den Veeam Backup Service, ohne den die anderen nicht funktionieren werden.
VSS: Technisch gesehen steht VSS immer für den Microsoft Volume Shadow Copy Service. In der Praxis wird er von vielen als Synonym für Application-Aware Image Processing verwendet. Das ist jedoch kategorisch falsch, aber das ist eine Geschichte wie: „Jeder Geländewagen kann als Jeep bezeichnet werden, und man wird dich verstehen.“
Fantastische Logs und ihre Lebensräume
Ich möchte dieses Kapitel mit dem Aufdecken eines großen Geheimnisses beginnen – welche Uhrzeit wird in den Logs angezeigt?
Merken Sie sich:
- ESXi schreibt Logs immer in UTC+0.
- vCenter führt Logs nach der Zeit seiner Zeitzone.
- Veeam protokolliert die Zeit und die Zeitzone des Servers, auf dem es läuft.
- Und nur Windows-Ereignisse im EVTX-Format sind nicht an irgendetwas gebunden. Beim Öffnen wird die Zeit an den Computer angepasst, auf dem sie geöffnet werden. Das ist die bequemste Option, obwohl es auch damit Schwierigkeiten geben kann. Die einzige spürbare Schwierigkeit ist der Unterschied in den Regionen. Das ist nahezu ein garantierter Weg zu unlesbaren Logs. Ja, es gibt Möglichkeiten, das zu beheben, aber lass uns einfach nicht darüber streiten, dass alles in der IT auf Englisch funktioniert, und lass uns immer die englische Locale auf den Servern einstellen. Bitte.
Jetzt sprechen wir doch über die Orte, an denen die Logs leben und wie man sie bekommt. Im Fall von VBR gibt es zwei Ansätze.
Die erste Option eignet sich, wenn Sie nicht brennen, die Dateien in einem allgemeinen Haufen zu suchen, die speziell mit Ihrem Problem zu tun haben. Dafür haben wir einen separaten Wizard, dem Sie einen bestimmten Job und einen bestimmten Zeitraum angeben können, für den Sie die Logs benötigen. Anschließend wird dieser automatisch durch die Ordner gehen und alles Notwendige in ein Archiv packen. Wo Sie es suchen und wie Sie damit arbeiten, steht ausführlich in .
Der Assistent sammelt nicht alle Protokolle. Wenn Sie zum Beispiel die Protokolle für das Restaurant, Failover oder Failback überprüfen müssen, finden Sie diese im Verzeichnis. %ProgramData%/Veeam/Backup. Dies ist der Hauptspeicherort für Protokolle von VBR, und %ProgramData% ist ein verstecktes Verzeichnis, was normal ist. Übrigens kann der Standardort mithilfe des Registrierungsschlüssels REG_SZ: LogDirectory im Zweig HKEY_LOCAL_MACHINESOFTWAREVeeamVeeam Backup and Replication geändert werden.
Auf Linux-Maschinen sollten die Protokolle der Arbeitsagenten unter / gesucht werden.var/log/VeeamBackup/, wenn Sie ein Root- oder Sudo-Konto verwenden. Wenn Sie solche Berechtigungen nicht haben, suchen Sie die Protokolle in. /tmp/VeeamBackup.
Für Veeam Agent für %OS_name% sollten die Protokolle unter %ProgramData%/Veeam/Endpoint (oder %ProgramData%/Veeam/Backup/Endpoint) und /var/log/veeam entsprechend.
Wenn Sie Application-Aware Image Processing verwenden (und das tun Sie wahrscheinlich), wird die Situation etwas komplizierter. Sie benötigen die Protokolle unseres Helpers, die innerhalb der virtuellen Maschine gespeichert sind, sowie die VSS-Protokolle. Wie und wo Sie diese Informationen erhalten, erfahren Sie detailliert in. . Und natürlich gibt es zum Sammeln der erforderlichen Systemprotokolle.
Windows-Ereignisse lassen sich bequem sammeln gemäß. . Wenn Sie Hyper-V nutzen, wird es komplizierter, da Sie auch alle Protokolle aus dem Zweig Applications and Service Logs > Microsoft > Windows benötigen. Natürlich können Sie auch den einfacheren Weg gehen und einfach alle Objekte aus %SystemRoot%System32winevtLogs herunterladen.
Wenn während der Installation/Upgrade etwas schiefgeht, finden Sie alle erforderlichen Dateien im Ordner %ProgramData%/Veeam/Setup/Temp. Ich möchte jedoch nicht verschweigen, dass in den Ereignissen des Betriebssystems oft nützlichere Informationen zu finden sind als in diesen Protokollen. Interessantes bleibt auch in %Temp% liegen, wo sich hauptsächlich Protokolle der Installation von begleitender Software wie Datenbanken, .Net-Bibliotheken und ähnlichem befinden. Beachten Sie, dass Veeam über msi installiert wird und alle Komponenten ebenfalls als separate msi-Pakete installiert werden, auch wenn sie nicht im GUI angezeigt werden. Wenn die Installation einer der Komponenten fehlschlägt, wird die gesamte VBR-Installation gestoppt. Daher sollten Sie die Protokolle überprüfen und herausfinden, was genau fehlgeschlagen ist und wann.
Und ein letzter Tipp: Wenn Sie während der Installation einen Fehler erhalten, drücken Sie nicht sofort OK. Zuerst die Protokolle sichern, dann OK drücken. So erhalten Sie ein Protokoll, das an dem Punkt der Fehlermeldung endet, ohne überflüssige Informationen am Ende.
Manchmal muss man in die vSphere-Logs eintauchen. Diese Aufgabe ist oft mühsam, aber wenn es darauf ankommt, muss man auch das übernehmen. Im einfachsten Fall benötigen wir die Logs mit den Ereignissen der virtuellen Maschine vmware.log, die sich im gleichen Verzeichnis wie die .vmx-Datei befindet. Im komplizierteren Fall öffnen Sie Google und suchen, wo die Logs für Ihre Host-Version gespeichert sind, denn VMware ändert diesen Speicherort gerne mit jeder neuen Version. Hier ein Beispiel für , und hier für . Für die Logs von vCenter wiederholen wir den Vorgang . Im Allgemeinen sind uns jedoch die Logs der Host-Ereignisse hostd.log, die Ereignisse der unter vCenter verwalteten Hosts vpxa.log, die Kernel-Logs vmkernel.log und die Authentifizierungs-Logs auth.log wichtig. Und in besonders schwierigen Fällen kann das SSO-Log, das im SSO-Ordner gespeichert ist, nützlich sein.
Überwältigend? Verwirrend? Beängstigend? Und das ist noch nicht einmal die Hälfte der Informationen, mit denen unser Support täglich arbeitet. Sie sind also wirklich sehr kompetent.
Veeam-Komponenten
Als Abschluss dieses einführenden Artikels wollen wir noch ein wenig über die Komponenten von Veeam Backup & Replication sprechen. Wenn man nach den Ursachen für Probleme sucht, ist es hilfreich zu verstehen, wie der Patient konstruiert ist.
Wie schon viele wissen, ist Veeam Backup eine SQL-basierte Anwendung. Das bedeutet, dass sämtliche Einstellungen, alle Informationen und grundsätzlich alles, was für den ordnungsgemäßen Betrieb erforderlich ist, in seiner Datenbank gespeichert ist. Genauer gesagt, in zwei Datenbanken, wenn wir die Kombination von VBR und EM betrachten: VeeamBackup und VeeamBackupReporting. So hat es sich ergeben: Bei der Installation einer weiteren Anwendung wird eine zusätzliche Datenbank erstellt. Um nicht alle Eier in einem Korb zu lagern.
Damit all diese Komponenten reibungslos zusammenarbeiten, benötigen wir eine Reihe von Diensten und Anwendungen, die alle Elemente miteinander verbinden. Zur Veranschaulichung sieht es so in einem meiner Labore aus:
In der Rolle des Hauptdirigenten fungiert Veeam Backup Service. Dieser ist verantwortlich für den Austausch von Informationen mit den Datenbanken. Er startet außerdem alle Aufgaben, orchestriert die zugewiesenen Ressourcen und fungiert als Kommunikationszentrale für verschiedene Konsolen, Agenten und alles andere. Kurz gesagt, ohne ihn geht nichts, aber das bedeutet nicht, dass er alles allein macht.
Bei der Umsetzung seiner Aufgaben erhält er Unterstützung von Veeam Backup Manager. Dies ist kein Dienst, sondern eine Entität, die Jobs ausführt und den Fortschritt ihrer Ausführung überwacht. Die Arbeitskräfte des Backup-Service, die sich mit den Hosts verbinden, erstellen Snapshots, überwachen die Retention usw.
Aber zurück zur Liste der Dienste. Veeam Broker Service. Eingeführt in v9.5 (und das ist kein Krypto-Miner, wie einige damals dachten). Es sammelt Informationen über VMware-Hosts und hält sie aktuell. Aber bitte schreiben Sie nicht sofort wütende Kommentare, dass wir Sie ausspionieren und alle Ihre Logins/Passwörter an Dritte weitergeben. Es ist alles ein wenig einfacher. Wenn Sie ein Backup starten, müssen Sie zunächst eine Verbindung zum Host herstellen und alle Daten über dessen Struktur aktualisieren. Das ist ein ziemlich langsamer und umständlicher Prozess. Denken Sie nur daran, wie lange Sie für den Login über die Weboberfläche brauchen, und bedenken Sie, dass dort nur die oberste Schicht betrachtet wird. Außerdem muss die gesamte Hierarchie bis zum benötigten Punkt aufgedeckt werden. Kurz gesagt, es ist schrecklich. Wenn Sie ein Dutzend Backups starten, muss jeder Job diesen Prozess durchlaufen. In großen Infrastrukturen kann dieser Prozess zehn Minuten oder länger dauern. Daher wurde beschlossen, dafür einen separaten Dienst bereitzustellen, über den immer aktuelle Informationen abgerufen werden können. Bei der Initialisierung überprüft und scannt er die gesamte hinzugefügte Infrastruktur und versucht dann, nur auf der Ebene inkrementeller Änderungen zu arbeiten. Selbst wenn Sie hundert Backups gleichzeitig ausführen, werden sie alle Informationen von unserem Broker anfragen und die Hosts nicht mit ihren Anfragen belasten. Wenn Sie sich um die Ressourcen sorgen, haben unsere Berechnungen ergeben, dass für 5000 virtuelle Maschinen nur etwa 100 MB Speicher benötigt werden.
Als Nächstes betrachten wir Veeam Console. Auch bekannt als Veeam Remote Console oder Veeam.Backup.Shell. Das ist die GUI, die wir in den Screenshots sehen. Es ist einfach und unkompliziert – 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 die Punkte lokal einbinden (also auf dem Rechner, auf dem die Konsole läuft). Auch die verschiedenen Veeam Explorers werden lokal gestartet, da sie Teil der Konsole sind. Aber das führt hier zu weit…
Der nächste interessante Dienst ist Veeam Backup Catalog Data Service. Im Serviceverzeichnis bekannt als Veeam Guest Catalog Service. Er ist zuständig für die Indizierung von Dateisystemen auf Gastmaschinen und befüllt den VBRCatalog-Ordner mit diesen Informationen. Wird nur dort verwendet, wo die Indizierung aktiviert ist. Und es macht nur Sinn, die Indizierung zu aktivieren, wenn Sie einen Enterprise Manager haben. Daher der gut gemeinte Rat: Aktivieren Sie die Indizierung nicht einfach so, wenn Sie keinen EM haben. Schonen Sie Ihre Nerven und die Zeit des Supports.
Ebenfalls erwähnenswert sind andere wichtige Dienste wie Veeam Installer Service, über den die notwendigen Komponenten auf Proxys, Repositories und andere Gateways geliefert und installiert werden. Tatsächlich bringt er die benötigten .msi-Pakete auf die Server und führt deren Installation durch.
Veeam Data Mover — indem er über Proxys (und nicht nur) ausgeführte Hilfsagenten verwendet, die sich um die Datenverschiebung kümmern. Zum Beispiel wird beim Backup ein Agent die Dateien von den Datastores des Hosts lesen, während ein anderer sie sorgfältig ins Backup schreibt.
Ein wichtiger Punkt, den ich oft von Kunden höre, ist die Diskrepanz zwischen den Versionen der Dienste und den Informationen im Programmbereich der Systemeinstellungen. Ja, die Liste wird identisch sein, aber die Versionsnummern können stark variieren. Das sieht aus visueller Sicht nicht optimal aus, ist jedoch völlig normal, solange alles stabil funktioniert. Zum Beispiel hinkt die Versionsnummer des Installers stark hinter den anderen zurück. Ein Albtraum? Nicht unbedingt, denn er wird nicht komplett neu installiert, sondern lediglich sein DLL aktualisiert. Im Patch v9.5 U4 erlebte der Support einen Albtraum: Bei der Aktualisierung erhielten alle Dienste neue Versionen, außer dem wichtigsten. Im Patch U4b überholte der Transportdienst alle anderen um gleich zwei Versionen (wenn man die Zahlen betrachtet). Auch das ist normal – darin wurde ein schwerwiegender Fehler gefunden, weshalb er ein zusätzliches Update im Vergleich zu den anderen erhielt. Zusammenfassend lässt sich sagen: Die Unterschiede in den Versionen KÖNNEN ein Problem darstellen, aber wenn Unterschiede bestehen und alles reibungslos funktioniert, dann ist das wahrscheinlich so beabsichtigt. Niemand hindert Sie daran, dies beim Support zu hinterfragen.
Dies sind die sogenannten Pflichtdienste oder Mandatory Services. Darüber hinaus gibt es eine Vielzahl von unterstützenden Diensten, wie z.B. Tape Service, Mount Service, vPowerNFS Service und andere.
Für Hyper-V gilt im Wesentlichen das Gleiche, jedoch gibt es spezifische Aspekte. Veeam Backup Hyper-V Integrationsdienst und einen eigenen Treiber für die Arbeit mit CBT.
Und am Ende sprechen wir darüber, wer während des Backups auf den virtuellen Maschinen arbeitet. Für den Start von Pre- und Post-Freeze-Skripten, zur Erstellung von Schattenkopien, für das Sammeln von Metadaten, die Arbeit mit SQL-Transaktionsprotokollen und mehr wird Veeam Guest Helperverwendet. Und wenn die Dateisysteme indexiert werden, verwendet man den Veeam Guest Indexer. Dies sind temporäre Dienste, die während des Backups bereitgestellt und nach dessen Abschluss entfernt werden.
Im Falle von Linux-Maschinen ist alles erheblich einfacher, da es eine Vielzahl von integrierten Bibliotheken und Funktionen des Systems gibt. Zum Beispiel erfolgt die Indizierung über mlocate.
Das ist vorerst alles.
Ich möchte Sie nicht weiter belästigen und eine kurze Ich betrachte die Einführung in den Bereich hinter Veeam als abgeschlossen. Ja, wir sind noch nicht einmal in die Protokolle eingetaucht, aber glauben Sie mir, damit die dort präsentierten Informationen nicht wie ein zusammenhangloser Bewusstseinsstrom erscheinen, ist eine solche Einführung absolut notwendig. Ich plane, erst im dritten Artikel zu den Protokollen selbst überzugehen. Der Plan für den nächsten Artikel ist, zu erklären, wer die Protokolle generiert, was genau darin angezeigt wird und warum es auf diese Weise und nicht anders ist.
Quelle: habr.com
