{"id":97729,"date":"2020-10-21T08:42:22","date_gmt":"2020-10-21T06:42:22","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving"},"modified":"2020-10-21T08:42:22","modified_gmt":"2020-10-21T06:42:22","slug":"otkuda-berutsya-logi-veeam-log-diving","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","title":{"rendered":"Woher kommen die Logs? Veeam Log Diving","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Woher<\/p>\n

Wir setzen unser Eintauchen in die faszinierende Welt der Fehlerbehebung anhand von Logs fort. In im vorherigen Artikel<\/a><\/noindex> haben wir die Bedeutung grundlegender Begriffe gekl\u00e4rt und einen ersten Blick auf die Gesamtstruktur von Veeam als einheitlicher Anwendung geworfen. Die Aufgabe f\u00fcr diese Sitzung ist es, herauszufinden, wie Protokolldateien erstellt werden, welche Informationen sie enthalten und warum sie so aussehen, wie sie aussehen.<\/p>\n

Was denken Sie, was diese \"Logs\" \u00fcberhaupt sind? Nach Meinung der meisten sollte jedem Anwendungslauf ein gewisser omnipotenter Charakter zugeordnet werden, der die meiste Zeit irgendwo im Hintergrund verweilt, aber im entscheidenden Moment aus dem Nichts in strahlender R\u00fcstung erscheint und alle rettet. Das hei\u00dft, in ihnen sollte alles enthalten sein, von den kleinsten Fehlern in jedem Bauteil bis hin zu einzelnen Datenbanktransaktionen. Und nach einem Fehler sollte sofort vermerkt werden, wie man ihn beheben kann. Und all dies sollte in ein paar Megabyte passen, nicht mehr. Das ist doch nur Text! Textdateien k\u00f6nnen doch keine Dutzende Gigabyte gro\u00df sein, das habe ich irgendwo geh\u00f6rt!<\/p>\n

Also, Logs<\/h2>\n

Im wirklichen Leben sind Protokolle lediglich Archive von Diagnosedaten. Die Entscheidung dar\u00fcber, was dort gespeichert werden soll, woher die Informationen f\u00fcr die Speicherung stammen und wie detailliert sie sein sollten, liegt bei den Entwicklern selbst. Manche entscheiden sich f\u00fcr einen minimalistischen Ansatz und speichern nur Eintr\u00e4ge \u00fcber EIN\/AUS, w\u00e4hrend andere alles, was erreichbar ist, gewissenhaft sammeln. Es gibt aber auch eine Zwischenl\u00f6sung mit der M\u00f6glichkeit, das sogenannte Logging Level auszuw\u00e4hlen, bei dem man selbst angibt, wie detaillierte Informationen man speichern m\u00f6chte und wie viel Speicherplatz auf den Festplatten verf\u00fcgbar ist. \u00dcbrigens hat VBR sechs solcher Levels. Und glauben Sie mir, Sie m\u00f6chten nicht sehen, was passiert, wenn bei maximal detaillierter Protokollierung der Speicherplatz auf Ihrer Festplatte nahezu ersch\u00f6pft ist.<\/p>\n

Gut. Wir haben ungef\u00e4hr verstanden, was wir speichern wollen, aber es stellt sich die berechtigte Frage: Woher nehmen wir diese Informationen? Ein Teil der Ereignisse f\u00fcr das Logging wird nat\u00fcrlich von unseren internen Prozessen selbst generiert. Aber was passiert, wenn es zu Interaktionen mit der externen Umgebung kommt? Um nicht in ein Chaos aus Notl\u00f6sungen und eigenen L\u00f6sungen zu geraten, tendiert Veeam dazu, bereits erfundene Erfindungen nicht neu zu erfinden. Immer wenn ein bestehendes API, eine im System integrierte Funktion, eine Bibliothek usw. verf\u00fcgbar ist, ziehen wir die vorhandenen Optionen dem Bau eigener komplizierter L\u00f6sungen vor. Obwohl es auch davon reichlich gibt. Daher ist es wichtig, bei der Analyse von Logs zu verstehen, dass der Gro\u00dfteil der Fehler auf Nachrichten von Drittanbieter-APIs, systembezogenen Aufrufen und anderen Bibliotheken zur\u00fcckzuf\u00fchren ist. In diesem Fall besteht die Rolle von VBR darin, diese Fehler in die Log-Dateien unver\u00e4ndert weiterzuleiten. Die Hauptaufgabe des Benutzers besteht darin, zu lernen, welche Zeile von wem kommt und wof\u00fcr dieses \u201ewer\u201c verantwortlich ist. Daher ist es normal und richtig, wenn ein Fehlercode aus dem VBR-Log Sie auf eine MSDN-Seite weiterleitet.<\/p>\n

Wie bereits zuvor besprochen: Veeam ist eine SQL-basierte Anwendung. Das bedeutet, dass alle Einstellungen, alle Informationen und alles, was f\u00fcr eine ordnungsgem\u00e4\u00dfe Funktion erforderlich ist, in seiner Datenbank gespeichert wird. Daraus ergibt sich die einfache Wahrheit: Was nicht in den Logs steht, ist h\u00f6chstwahrscheinlich in der Datenbank. Aber das ist auch keine Silberkugel: Manche Dinge sind weder in den lokalen Logs der Veeam-Komponenten noch in seiner Datenbank zu finden. Daher muss man lernen, die Logs des Hosts, die Logs der lokalen Maschine und die Logs von allem, was am Backup- und Wiederherstellungsprozess beteiligt ist, zu untersuchen. Manchmal kann es sogar vorkommen, dass die ben\u00f6tigten Informationen \u00fcberhaupt nirgendwo vorhanden sind. So ist der Weg. <\/p>\n

Einige Beispiele f\u00fcr solche APIs<\/h4>\n

Diese Liste erhebt keinen Anspruch auf Vollst\u00e4ndigkeit, daher sollte man nicht darin nach der letzten Wahrheit suchen. Ihre Aufgabe ist lediglich, die h\u00e4ufigsten externen APIs und Technologien, die in unseren Produkten verwendet werden, aufzuzeigen.<\/p>\n

Lassen Sie uns beginnen mit VMware<\/strong>. <\/p>\n

An erster Stelle steht vSphere API<\/strong>. Wird zur Authentifizierung, zum Lesen der Hierarchie, zum Erstellen und L\u00f6schen von Snapshots, zur Abfrage von Informationen \u00fcber Maschinen und f\u00fcr vieles (sehr vieles) andere verwendet. Die Funktionalit\u00e4t der L\u00f6sung ist sehr umfangreich, daher kann ich allen Interessierten die VMware vSphere API Reference f\u00fcr die Version empfehlen. 5.5<\/u><\/a><\/noindex> und 6.0<\/u><\/a><\/noindex>. F\u00fcr aktuellere Versionen l\u00e4sst sich alles einfach googeln.<\/p>\n

VIX API<\/strong>. Schwarze Magie des Hypervisors, f\u00fcr die es eine separate Fehlerliste<\/u><\/a><\/noindex>. VMware API, um Dateien auf dem Host ohne Netzwerkverbindung zu bearbeiten. Eine letzte Rettung, wenn eine Datei auf eine Maschine \u00fcbertragen werden muss, f\u00fcr die es keinen besseren Kommunikationskanal gibt. Es ist eine m\u00fchsame Angelegenheit, wenn die Datei gro\u00df ist und der Host stark ausgelastet. Aber hier gilt die Regel, dass selbst 56,6 kB\/s besser sind als 0 kB\/s. In Hyper-V nennt sich solch eine Funktion PowerShell Direct. Doch das war nur bis zum Erscheinen von<\/p>\n

vSphere Web Services API<\/strong> . Seit vSphere 6.0 (ungef\u00e4hr, da diese API erstmals in Version 5.5 vorgestellt wurde) wird sie zur Verwaltung von Gastmaschinen verwendet und hat mittlerweile praktisch die VIX abgel\u00f6st. Im Grunde genommen ist dies eine weitere API zur Verwaltung von vSphere. Interessierten kann ich empfehlen, sich das ausgezeichnete<\/u><\/a><\/noindex> Handbuch anzusehen. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Eine Bibliothek, die teilweise bereits erw\u00e4hnt wurde in dieser Artikel<\/u><\/a><\/noindex>. Wird verwendet, um virtuelle Festplatten zu lesen. Einst war es Teil von VIX, wurde aber im Laufe der Zeit in ein eigenst\u00e4ndiges Produkt \u00fcberf\u00fchrt. Dennoch nutzt es als Nachfolger die gleichen Fehlercodes wie VIX.  Aus irgendeinem Grund enth\u00e4lt das SDK jedoch keine Beschreibung dieser Fehler. Daher wurde durch Erfahrung herausgefunden, dass VDDK-Fehler mit anderen Codes lediglich eine \u00dcbersetzung von bin\u00e4r in dezimal darstellen. Es besteht aus zwei Teilen \u2013 die erste H\u00e4lfte ist nicht dokumentierte Kontextinformationen, w\u00e4hrend der zweite Teil die traditionellen VIX\/VDDK-Fehler umfasst. Zum Beispiel, wenn wir sehen:<\/p>\n

VDDK-Fehler: 21036749815809.Unknown error<\/code><\/p>\n

K\u00f6nnen wir das problemlos in hexadezimal umrechnen und erhalten 132200000001. Der wenig informative Anfang 132200 wird einfach ignoriert, und der Rest ist unser Fehlercode (VDDK 1: Unbekannter Fehler).  Vor kurzem gab es eine separate Diskussion \u00fcber die h\u00e4ufigsten VDDK-Fehler. Artikel<\/u><\/a><\/noindex>.<\/p>\n

Jetzt schauen wir uns Windows<\/strong>. <\/p>\n

Hier finden wir alles Wichtige und Notwendige in der Standard- Ereignisanzeige<\/strong>. Aber es gibt ein kleines Problem: traditionell protokolliert Windows nicht den vollst\u00e4ndigen Fehlertext, sondern nur die Fehlernummer. Zum Beispiel ist Fehler 5 \u2013 \u201cZugriff verweigert\u201d, und 1722 \u2013 \u201cDer RPC-Server ist nicht verf\u00fcgbar\u201d, und 10060 \u2013 \u201cVerbindung ist abgelaufen\u201d. Nat\u00fcrlich ist es gro\u00dfartig, wenn du die bekanntesten Fehler kennst, aber was ist mit den bisher unbekannten? <\/p>\n

Um das Leben nicht allzu s\u00fc\u00df erscheinen zu lassen, werden die Fehler auch in hexadezimaler Form gespeichert, mit dem Pr\u00e4fix 0x8007. Zum Beispiel, 0x8007000e \u2014 das bedeutet tats\u00e4chlich 14, Out of Memory. Warum und f\u00fcr wen das so gemacht wurde, bleibt ein Geheimnis. Eine vollst\u00e4ndige Liste der Fehler kann jedoch kostenlos und ohne SMS von devcenter<\/u><\/a><\/noindex>.<\/p>\n

\u00dcbrigens gibt es manchmal auch andere Pr\u00e4fixe, nicht nur 0x8007. In so einem traurigen Fall muss man f\u00fcr das Verst\u00e4ndnis von HRESULT (\u201eResult Handle\u201c) noch tiefer in die Materie eintauchen Dokumentation<\/u><\/a><\/noindex> f\u00fcr Entwickler. Im Alltag w\u00fcrde ich dir so etwas nicht empfehlen, aber falls du mal in der Klemme steckst oder einfach nur neugierig bist, wei\u00dft du jetzt, was zu tun ist.<\/p>\n

Aber die Kollegen bei Microsoft haben ein wenig Mitleid mit uns gehabt und die Utility ERR<\/u><\/a><\/noindex>. Es ist ein kleines St\u00fcck Konsolen-Gl\u00fcck, das Fehlercodes in eine verst\u00e4ndliche Sprache \u00fcbersetzen kann, ohne Google verwenden zu m\u00fcssen. Es funktioniert ungef\u00e4hr so.<\/p>\n

C:UsersrootDesktop>err.exe 0x54f\n# f\u00fcr hex 0x54f \/ dezimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Ein interner Fehler ist aufgetreten.\n# als HRESULT: Schwere: ERFOLG (0), FACILITY_NULL (0x0), Code 0x54f\n# f\u00fcr hex 0x54f \/ dezimal 1359\n  ERROR_INTERNAL_ERROR                                           winerror.h\n# Ein interner Fehler ist aufgetreten.\n# 2 \u00dcbereinstimmungen f\u00fcr \"0x54f\" gefunden<\/code><\/pre>\n
Es stellt sich die berechtigte Frage: Warum schreiben wir die Entschl\u00fcsselung nicht sofort in die Logs, sondern belassen es bei diesen mysteri\u00f6sen Codes? Die Antwort liegt in externen Anwendungen. Wenn du selbst einen WinAPI-Aufruf machst, ist es einfach, die Antwort zu entschl\u00fcsseln, denn daf\u00fcr gibt es sogar einen speziellen WinAPI-Aufruf. Aber wie bereits erw\u00e4hnt, kommt alles, was wir in den Antworten erhalten, in unsere Logs. Und hier m\u00fcsste man st\u00e4ndig diesen Fluss des Bewusstseins \u00fcberwachen, die Fehlerteile herausfiltern, sie entschl\u00fcsseln und zur\u00fcckf\u00fcgen. Ehrlich gesagt, das ist nicht gerade eine fesselnde Aufgabe.<\/p>\n
Windows Dateiverwaltungs-API <\/strong>wird bei der Arbeit mit Dateien vielf\u00e4ltig eingesetzt. Erstellung von Dateien, L\u00f6schung, \u00d6ffnung zum Schreiben, Arbeit mit Attributen und so weiter.<\/p>\n
Oben erw\u00e4hnt PowerShell Direct<\/strong> wie das VIX API in der Hyper-V-Welt. Leider nicht so flexibel: es gibt zahlreiche funktionale Einschr\u00e4nkungen, es funktioniert nicht mit jeder Hostversion und weit nicht mit allen G\u00e4sten.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Ich denke, es gibt niemanden, der mit Windows gearbeitet hat und noch nie auf RPC-Fehler gesto\u00dfen ist. Trotz der weit verbreiteten Annahme handelt es sich hierbei nicht um ein einheitliches Protokoll, sondern um jedes client-serverbasierte Protokoll, das eine Reihe von Kriterien erf\u00fcllt. Wenn wir jedoch in unseren Logs einen RPC-Fehler sehen, handelt es sich in 90% der F\u00e4lle um einen Fehler von Microsoft RPC, das Teil von DCOM (Distributed Component Object Model) ist. Im Internet gibt es eine enorme Menge an Dokumentation zu diesem Thema, allerdings ist der Gro\u00dfteil davon stark veraltet. Wenn jedoch ein brennendes Interesse besteht, das Thema zu erforschen, kann ich Artikel empfehlen Was ist RPC?<\/u><\/a><\/noindex>, Wie funktioniert RPC<\/u> <\/a><\/noindex>und eine lange Liste von RPC-Fehlern<\/u><\/a><\/noindex>.<\/p>\n
Die Hauptursachen f\u00fcr RPC-Fehler in unseren Logs sind fehlgeschlagene Versuche zur Interaktion zwischen VBR-Komponenten (Server > Proxy, zum Beispiel) und meist aufgrund von Kommunikationsproblemen.<\/p>\n
Der Spitzenreiter unter allen Spitzenreitern \u2014 der Fehler The RPC server is unavailable (1722). Einfach gesagt, der Client konnte keine Verbindung zum Server herstellen. Warum und wie \u2014 eine einheitliche Antwort gibt es nicht, aber in der Regel handelt es sich um ein Authentifizierungsproblem oder um Netzwerkzugang bis Port 135. Letzteres ist charakteristisch f\u00fcr Infrastrukturen mit dynamischer Portzuweisung. Zu diesem Thema gibt es sogar ein eigenes KB<\/u><\/a><\/noindex>. Microsoft hat dazu - ausf\u00fchrlichen Leitfaden<\/u><\/a><\/noindex> zur Fehlersuche ver\u00f6ffentlicht.<\/p>\n
Der zweith\u00e4ufigste Fehler: Es sind keine weiteren Endpunkte vom Endpunkt-Mapper verf\u00fcgbar (1753). Der RPC-Client oder -Server konnte keinen Port zuweisen. Dies tritt typischerweise auf, wenn der Server (in unserem Fall die virtuelle Maschine) so konfiguriert ist, dass er Ports aus einem engen Pool dynamisch zuweist, dessen Kapazit\u00e4t ersch\u00f6pft ist. Und aus der Sicht des Clients (in unserem Fall des VBR-Servers) bedeutet das, dass unser VeeamVssAgent entweder nicht gestartet wurde oder nicht als RPC-Schnittstelle registriert wurde. Auch zu diesem Thema gibt es ein eigenes KB<\/u><\/a><\/noindex>.<\/p>\n
Um die Top-3-Fehler im RPC abzuschlie\u00dfen, erinnern wir uns an den Fehler \"RPC function call failed (1726)\". Dieser tritt auf, wenn die Verbindung hergestellt wurde, aber RPC-Anfragen nicht verarbeitet werden. Zum Beispiel, wenn wir Informationen \u00fcber den Status von VSS anfragen (vielleicht wird gerade eine Schattenkopie erstellt und wir versuchen, darauf zuzugreifen), und stattdessen erhalten wir Stille und Ignoranz.<\/p>\n
Windows Tape Backup API <\/strong>ist erforderlich, um mit Bandbibliotheken oder -laufwerken zu arbeiten. Wie ich zu Beginn erw\u00e4hnte: Es macht uns keinen Spa\u00df, eigene Treiber zu schreiben und dann mit der Unterst\u00fctzung jedes Ger\u00e4ts zu k\u00e4mpfen. Deshalb gibt es bei Vima keine eigenen Treiber. Alles erfolgt \u00fcber die Standard-API, deren Unterst\u00fctzung von den Hardwareanbietern selbst bereitgestellt wird. So ist es doch viel logischer, oder?<\/p>\n
SMB\/CIFS<\/strong> Alle schreiben sie aus Gewohnheit nebeneinander, obwohl sich nur wenige daran erinnern, dass CIFS (Common Internet File System) einfach eine private Version von SMB (Server Message Block) ist. Es ist also nichts Schlechtes daran, diese Begriffe zu verallgemeinern. Samba hingegen ist die Linux\/Unix-Implementierung und hat ihre eigenen Besonderheiten, aber das ist ein anderer Punkt. Was hier wichtig ist: Wenn Veeam darum bittet, etwas \u00fcber einen UNC-Pfad (serverdirectory) zu schreiben, verwendet der Server die Hierarchie der Datei\u00adsystemtreiber, einschlie\u00dflich mup und mrxsmb, um auf die Freigabe zu schreiben. Entsprechend werden auch Fehler von diesen Treibern erzeugt.<\/p>\n
Man kommt nicht umhin Winsock API<\/strong>. Wenn etwas \u00fcber das Netzwerk gemacht werden muss, kommuniziert VBR \u00fcber das Windows Socket API, allgemein bekannt als Winsock. Wenn wir also im Protokoll eine Verbindung IP:Port sehen, ist das es. In der offiziellen Dokumentation gibt es eine ganz passable Liste m\u00f6glicher Fehler<\/u><\/a><\/noindex>.<\/p>\n
Oben erw\u00e4hnt WMI<\/strong> (Windows Management Instrumentation) \u2014 ist eine umfassende API zur Verwaltung aller Aspekte der Windows-Welt. Beispielsweise erfolgen bei der Arbeit mit Hyper-V nahezu alle Anfragen an den Host \u00fcber diese Schnittstelle. Kurz gesagt, es ist ein unverzichtbares und leistungsstarkes Werkzeug in seiner Funktionalit\u00e4t. Bei der Fehlersuche hilft das integrierte Tool WBEMtest.exe erheblich.<\/p>\n
Und der letzte auf der Liste, aber keineswegs der unwichtigste \u2014 VSS<\/strong> (Volume Shadow Storage). Das Thema ist so umfassend und mysteri\u00f6s, wie die Menge an Dokumentation, die dar\u00fcber geschrieben wurde. Shadow Copy l\u00e4sst sich am besten als eine spezielle Art von Snapshot verstehen, und genau das ist es auch. Dank ihm k\u00f6nnen in VMware anwendungskonsistente Backups erstellt werden, und in Hyper-V ist es sogar fast alles m\u00f6glich. Ich plane, einen separaten Artikel mit einem \u00dcberblick \u00fcber VSS zu erstellen, aber bis dahin k\u00f6nnen Sie versuchen, diese Beschreibung<\/u><\/a><\/noindex>zu lesen. Seien Sie jedoch vorsichtig, da der Versuch, VSS im Vorbeigehen zu verstehen, zu Gehirnverletzungen f\u00fchren kann.<\/p>\n
Damit k\u00f6nnen wir wohl auch aufh\u00f6ren. Ich betrachte die Aufgabe, die grundlegendsten Dinge zu erkl\u00e4ren, als erf\u00fcllt, und im n\u00e4chsten Kapitel werden wir uns die Protokolle ansehen. Wenn Sie jedoch Fragen haben, z\u00f6gern Sie nicht, diese in den Kommentaren zu \u00e4u\u00dfern.<\/p>\n<\/p>\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u043d\u0430\u0448\u0435 \u043f\u043e\u0433\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u0432 \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043c\u0438\u0440 \u0433\u0430\u0434\u0430\u043d… \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043d\u0433\u0430 \u043f\u043e \u043b\u043e\u0433\u0430\u043c. \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0434\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043b\u0438\u0441\u044c \u043e \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0438 \u0431\u0430\u0437\u043e\u0432\u044b\u0445 \u0442\u0435\u0440\u043c\u0438\u043d\u043e\u0432 \u0438 \u043e\u0434\u043d\u0438\u043c \u0433\u043b\u0430\u0437\u043a\u043e\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043b\u0438 \u043e\u0431\u0449\u0443\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 Veeam, \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u0417\u0430\u0434\u0430\u0447\u0430 \u043d\u0430 \u044d\u0442\u0443 — \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u0442\u044c\u0441\u044f \u043a\u0430\u043a \u0444\u043e\u0440\u043c\u0438\u0440\u0443\u044e\u0442\u0441\u044f \u043b\u043e\u0433 \u0444\u0430\u0439\u043b\u044b, \u0447\u0442\u043e \u0437\u0430 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u0432 \u043d\u0438\u0445 \u043e\u0442\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u0430 \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u043e\u043d\u0438 \u0432\u044b\u0433\u043b\u044f\u0434\u044f\u0442 \u043a\u0430\u043a \u0432\u044b\u0433\u043b\u044f\u0434\u044f\u0442. \u041a\u0430\u043a \u0432\u044b \u0434\u0443\u043c\u0430\u0435\u0442\u0435, \u0447\u0442\u043e \u0432\u043e\u043e\u0431\u0449\u0435 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":97730,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-97729","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Woher kommen die Logs? Veeam Log Diving | ProHoster","description":"Wir setzen unser Eintauchen in die faszinierende Welt des Log-Trace-Troubleshootings fort. In dem vorherigen Artikel haben wir die Bedeutung grundlegender Begriffe gekl\u00e4rt und einen kurzen \u00dcberblick \u00fcber die gesamte Struktur von Veeam als einheitliche Anwendung gegeben. Das Ziel in diesem Artikel ist es, zu verstehen, wie Logdateien erstellt werden, welche Informationen sie enthalten und warum sie so aussehen, wie sie aussehen. Was denken Sie, was sind Logs \u00fcberhaupt?","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0442\u043a\u0443\u0434\u0430 \u0431\u0435\u0440\u0443\u0442\u0441\u044f \u043b\u043e\u0433\u0438? Veeam Log Diving | ProHoster","og:description":"\u041f\u0440\u043e\u0434\u043e\u043b\u0436\u0430\u0435\u043c \u043d\u0430\u0448\u0435 \u043f\u043e\u0433\u0440\u0443\u0436\u0435\u043d\u0438\u0435 \u0432 \u0443\u0432\u043b\u0435\u043a\u0430\u0442\u0435\u043b\u044c\u043d\u044b\u0439 \u043c\u0438\u0440 \u0433\u0430\u0434\u0430\u043d... \u0442\u0440\u0430\u0431\u043b\u0448\u0443\u0442\u0438\u043d\u0433\u0430 \u043f\u043e \u043b\u043e\u0433\u0430\u043c. \u0412 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0435\u0439 \u0441\u0442\u0430\u0442\u044c\u0435 \u043c\u044b \u0434\u043e\u0433\u043e\u0432\u043e\u0440\u0438\u043b\u0438\u0441\u044c \u043e \u0437\u043d\u0430\u0447\u0435\u043d\u0438\u0438 \u0431\u0430\u0437\u043e\u0432\u044b\u0445 \u0442\u0435\u0440\u043c\u0438\u043d\u043e\u0432 \u0438 \u043e\u0434\u043d\u0438\u043c \u0433\u043b\u0430\u0437\u043a\u043e\u043c \u0440\u0430\u0441\u0441\u043c\u043e\u0442\u0440\u0435\u043b\u0438 \u043e\u0431\u0449\u0443\u044e \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0443 Veeam, \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u043e\u0433\u043e \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f. \u0417\u0430\u0434\u0430\u0447\u0430 \u043d\u0430 \u044d\u0442\u0443 - \u0440\u0430\u0437\u043e\u0431\u0440\u0430\u0442\u044c\u0441\u044f \u043a\u0430\u043a \u0444\u043e\u0440\u043c\u0438\u0440\u0443\u044e\u0442\u0441\u044f \u043b\u043e\u0433 \u0444\u0430\u0439\u043b\u044b, \u0447\u0442\u043e \u0437\u0430 \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u044f \u0432 \u043d\u0438\u0445 \u043e\u0442\u043e\u0431\u0440\u0430\u0436\u0435\u043d\u0430 \u0438 \u043f\u043e\u0447\u0435\u043c\u0443 \u043e\u043d\u0438 \u0432\u044b\u0433\u043b\u044f\u0434\u044f\u0442 \u043a\u0430\u043a \u0432\u044b\u0433\u043b\u044f\u0434\u044f\u0442.\u041a\u0430\u043a \u0432\u044b \u0434\u0443\u043c\u0430\u0435\u0442\u0435, \u0447\u0442\u043e \u0432\u043e\u043e\u0431\u0449\u0435 \u0442\u0430\u043a\u043e\u0435","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/otkuda-berutsya-logi-veeam-log-diving","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-10-21T06:42:22+00:00","article:modified_time":"2020-10-21T06:42:22+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"97729","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 10:14:39","updated":"2022-09-30 13:30:55"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/97729","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=97729"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/97729\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/97730"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=97729"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=97729"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=97729"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}