{"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 des Troubleshootings durch Logs fort. In vorherigen Artikel<\/a><\/noindex> haben wir uns \u00fcber die Bedeutung grundlegender Begriffe verst\u00e4ndigt und einen kurzen Blick auf die allgemeine Struktur von Veeam als einer einzigen Anwendung geworfen. Die Aufgabe besteht darin, zu verstehen, wie Logdateien erstellt werden, welche Informationen sie enthalten und warum sie so aussehen, wie sie aussehen.<\/p>\n

Was denken Sie, was sind eigentlich diese \u201eLogs\u201c? Die meisten sind der Meinung, dass Logs jeder Anwendung wie eine allm\u00e4chtige Entit\u00e4t zugeordnet werden sollten, die den Gro\u00dfteil der Zeit irgendwo im Hintergrund vegetiert, aber im entscheidenden Moment wie aus dem Nichts in strahlender R\u00fcstung auftaucht und jeden rettet. Das hei\u00dft, sie sollten alles enthalten, von kleinsten Fehlern in jeder Komponente bis hin zu einzelnen Datenbanktransaktionen. Und nach einem Fehler sollte sofort vermerkt werden, wie man ihn beheben kann. Dabei sollte das alles in ein paar Megabyte passen, nicht mehr. Es ist schlie\u00dflich nur Text! Textdateien k\u00f6nnen keine Dutzenden von Gigabyte gro\u00df sein, das habe ich irgendwo geh\u00f6rt!<\/p>\n

So, Logs<\/h2>\n

Im realen Leben sind Logs lediglich Archive diagnostischer Informationen. Und was dort gespeichert wird, woher die Informationen f\u00fcr die Speicherung kommen und wie detailliert sie sein m\u00fcssen, entscheiden die Entwickler selbst. Einige gehen den minimalistischen Weg und speichern nur Eintr\u00e4ge auf dem Niveau EIN\/AUS, w\u00e4hrend andere alles sorgf\u00e4ltig zusammentragen, was sie nur erreichen k\u00f6nnen. Es gibt jedoch auch eine Zwischenl\u00f6sung mit der M\u00f6glichkeit, das sogenannte Logging Level auszuw\u00e4hlen, bei dem man selbst angibt, wie detailliert die Informationen, die man speichern m\u00f6chte, sein sollen und wie viel Platz man auf den Festplatten hat =) VBR hat \u00fcbrigens sechs solcher Stufen. Und glauben Sie mir, Sie m\u00f6chten nicht sehen, was passiert, wenn man mit der maximalen Detailgenauigkeit loggt und gleichzeitig freien Speicherplatz auf Ihrer Festplatte hat.<\/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 durch unsere internen Prozesse selbst erzeugt. Aber was ist zu tun, wenn es Interaktionen mit der Au\u00dfenwelt gibt? Um nicht in einen teuflischen Albtraum aus Hacks und Fahrr\u00e4dern abzurutschen, hat Veeam die Tendenz, bereits erfundene L\u00f6sungen nicht neu zu erfinden. Immer wenn es bereits eine fertige API, eine integrierte Systemfunktion, eine Bibliothek usw. gibt, werden wir den bereits vorhandenen Optionen den Vorzug geben, bevor wir beginnen, unsere ausgekl\u00fcgelten L\u00f6sungen zu entwickeln. Obwohl es davon auch genug gibt. Daher ist es beim Analysieren von Logs wichtig zu verstehen, dass der L\u00f6wenanteil der Fehler auf Nachrichten von Drittanbieter-APIs, Systemaufrufen und anderen Bibliotheken zur\u00fcckzuf\u00fchren ist. In diesem Fall reduziert sich die Rolle von VBR darauf, diese Fehler unver\u00e4ndert in Logdateien weiterzuleiten. Die Hauptaufgabe des Benutzers besteht darin, zu lernen, welche Zeile von wem stammt und wof\u00fcr dieses \u201ewer\u201c verantwortlich ist. Daher ist es normal und korrekt, wenn der Fehlercode im VBR-Log Sie zur MSDN-Seite f\u00fchrt.<\/p>\n

Wie zuvor vereinbart: Veeam ist eine sogenannte SQL-basierte Anwendung. Das bedeutet, dass alle Einstellungen, alle Informationen und alles, was f\u00fcr ein normales Funktionieren notwendig ist, in seiner Datenbank gespeichert wird. Daher die einfache Wahrheit: Wenn es nicht in den Logs steht, ist es wahrscheinlich in der Datenbank vorhanden. Aber das ist auch keine universelle L\u00f6sung: Einige 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 studieren. Es kann sogar vorkommen, dass die ben\u00f6tigten Informationen \u00fcberhaupt nirgendwo zu finden sind. So sieht der Weg aus. <\/p>\n

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

Diese Liste hat nicht das Ziel, eine vollst\u00e4ndige Wahrheit zu bieten, also suchen Sie darin bitte nicht nach absoluten Wahrheiten. Ihre Aufgabe besteht lediglich darin, die h\u00e4ufigsten externen APIs und Technologien zu zeigen, die in unseren Produkten verwendet werden.<\/p>\n

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

Der erste in der Liste wird sein vSphere API<\/strong>. Wird zur Authentifizierung, zum Lesen der Hierarchie, zum Erstellen und L\u00f6schen von Snapshots, zum Abfragen von Informationen \u00fcber Maschinen und vielen (viel) anderen Dingen verwendet. Die Funktionalit\u00e4t der L\u00f6sung ist sehr umfassend, daher kann ich allen Interessierten die VMware vSphere API-Referenz f\u00fcr die Version empfehlen 5.5<\/u><\/a><\/noindex> und 6.0<\/u><\/a><\/noindex>. F\u00fcr aktuellere Versionen findet man alles leicht mit einer Google-Suche.<\/p>\n

VIX API<\/strong>. Schwarze Magie des Hypervisors, f\u00fcr die es eine separate Fehlerliste<\/u><\/a><\/noindex>. VMware API zur Arbeit mit Dateien auf dem Host ohne Netzwerkverbindung. Eine letzte Hoffnung, wenn man eine Datei auf einen Rechner legen muss, zu dem es keinen besseren Kommunikationskanal gibt. Das bringt Schmerzen und Leiden mit sich, wenn die Datei gro\u00df ist und der Host ausgelastet. Aber hier gilt die Regel, dass selbst 56,6 Kb\/s besser ist als 0 Kb\/s. In Hyper-V wird so etwas PowerShell Direct genannt. Aber das war nur bis zum Erscheinen<\/p>\n

des vSphere Web Services API<\/strong> Seit vSphere 6.0 (ungef\u00e4hr, da dieses API erstmals in Version 5.5 vorgestellt wurde) wird es zur Verwaltung von Gastmaschinen verwendet und hat VIX mittlerweile praktisch \u00fcberall verdr\u00e4ngt. Im Grunde genommen ist es ein weiteres API zur Steuerung von vSphere. Interessierten kann ich empfehlen, das zu studieren eine ausgezeichnete<\/u><\/a><\/noindex> Dokumentation. <\/p>\n

VDDK<\/strong> (Virtual Disk Development Kit). Eine Bibliothek, \u00fcber die teilweise in diesem Artikel<\/u><\/a><\/noindex>. Wird zum Lesen virtueller Festplatten verwendet. Einst war es Teil von VIX, wurde jedoch im Laufe der Zeit in ein eigenes Produkt ausgelagert. Daf\u00fcr nutzt es als Nachfolger die gleichen Fehlercodes wie VIX. Aber aus irgendeinem Grund enth\u00e4lt das SDK selbst keine Beschreibung dieser Fehler. Deshalb wurde durch Erfahrung herausgefunden, dass die VDDK-Fehler mit anderen Codes nur eine Umwandlung von bin\u00e4r in dezimal darstellen. Es besteht aus zwei Teilen \u2013 die erste H\u00e4lfte ist undocumented information about the context, und der zweite Teil sind die traditionellen VIX\/VDDK-Fehler. Wenn wir zum Beispiel sehen:<\/p>\n

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

Dann konvertieren wir das mutig in hex und erhalten 132200000001. Den wenig informativen Anfang 132200 lassen wir einfach weg, und der Rest wird unser Fehlercode sein (VDDK 1: Unknown error). K\u00fcrzlich gab es sogar eine separate Diskussion \u00fcber die h\u00e4ufigsten VDDK-Fehler. Artikel<\/u><\/a><\/noindex>.<\/p>\n

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

Hier finden wir alles Wichtige und Notwendige im standardm\u00e4\u00dfigen Ereignisanzeiger<\/strong>. Aber es gibt einen Haken: Nach alter Tradition protokolliert Windows nicht den vollst\u00e4ndigen Fehlertext, sondern nur die Nummer. Zum Beispiel bedeutet Fehler 5 'Access denied', Fehler 1722 ist 'Der RPC-Server ist nicht verf\u00fcgbar', und 10060 steht f\u00fcr 'Verbindungstimeout'. Nat\u00fcrlich ist es gro\u00dfartig, wenn Sie die bekanntesten im Kopf haben, aber was ist mit bisher unbekannten Fehlern? <\/p>\n

Und damit das Leben nicht zu s\u00fc\u00df scheint, werden die Fehler auch in hexadezimaler Form gespeichert, mit dem Pr\u00e4fix 0x8007. Zum Beispiel ist 0x8007000e \u2014 in Wirklichkeit 14, Out of Memory. Warum und f\u00fcr wen das so gemacht wurde \u2014 bleibt ein R\u00e4tsel. Eine vollst\u00e4ndige Liste der Fehler kann kostenlos und ohne SMS heruntergeladen werden aus devcenrum<\/u><\/a><\/noindex>.<\/p>\n

\u00dcbrigens gibt es manchmal auch andere Pr\u00e4fixe und nicht nur 0x8007. In solch einer bedauerlichen Situation muss man noch tiefer in die HRESULT-Interpretation (\u201eresult handle\u201c) eintauchen Dokumentation<\/u><\/a><\/noindex> f\u00fcr Entwickler. Im normalen Leben w\u00fcrde ich Ihnen so etwas nicht raten, aber falls Sie einmal gegen die Wand gedr\u00e4ngt werden oder einfach nur neugierig sind, wissen Sie jetzt, was zu tun ist.<\/p>\n

Aber die Leute bei Microsoft haben uns ein bisschen erbarmt und die Utility ERR<\/u><\/a><\/noindex>herausgebracht. Es ist ein kleines St\u00fcck Konsolenfreude, das in der Lage ist, Fehlercodes in verst\u00e4ndliche Sprache zu \u00fcbersetzen, ohne Google zu benutzen. 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 nicht sofort die Entschl\u00fcsselung in die Logs, sondern lassen diese geheimnisvollen Codes stehen? Die Antwort ist in Drittanbieteranwendungen zu finden. Wenn Sie selbst einen bestimmten WinAPI-Aufruf t\u00e4tigen, ist es nicht schwierig, dessen Antwort zu entschl\u00fcsseln, denn daf\u00fcr gibt es sogar einen speziellen WinAPI-Aufruf. Aber wie bereits erw\u00e4hnt, gelangen in unsere Logs alles, was wir als Antworten erhalten. Und hier m\u00fcsste man diesen Bewusstseinsstrom st\u00e4ndig \u00fcberwachen, um St\u00fccke mit Windows-Fehlern herauszufiltern, sie zu entschl\u00fcsseln und wieder einzuf\u00fcgen. Um es ehrlich zu sagen, das ist kein aufregendes Unterfangen.<\/p>\n
Windows File Management API <\/strong>wird bei der Arbeit mit Dateien in s\u00e4mtlicher Hinsicht verwendet. Dateierstellung, -l\u00f6schen, -\u00f6ffnen zum Schreiben, Arbeit mit Attributen und vieles mehr.<\/p>\n
Das oben erw\u00e4hnte PowerShell Direct<\/strong> ist das \u00c4quivalent zum VIX API in der Welt von Hyper-V. Leider nicht so flexibel: Es gibt viele funktionale Einschr\u00e4nkungen, es funktioniert nicht mit jeder Host-Version und bei weitem nicht mit allen G\u00e4sten.<\/p>\n
RPC<\/strong> (Remote Procedure Call) Ich denke, es gibt keinen Menschen, der mit Windows gearbeitet hat, der nicht schon einmal auf RPC-bezogene Fehler gesto\u00dfen ist. Trotz des weit verbreiteten Missverst\u00e4ndnisses handelt es sich dabei nicht um ein einziges Protokoll, sondern um jedes Client-Server-Protokoll, das eine Reihe von Kriterien erf\u00fcllt. Wenn wir jedoch einen RPC-Fehler in unseren Protokollen haben, ist in 90% der F\u00e4lle der Fehler von Microsoft RPC, das Teil von DCOM (Distributed Component Object Model) ist. Im Internet gibt es eine riesige Menge an Dokumentationen zu diesem Thema, aber der Gro\u00dfteil ist ziemlich veraltet. Wenn ich jedoch das dringende Bed\u00fcrfnis habe, das Thema zu studieren, kann ich die Artikel empfehlen Was ist RPC?<\/u><\/a><\/noindex>, Wie funktioniert RPC<\/u> <\/a><\/noindex>und eine endlose Liste von RPC-Fehlern<\/u><\/a><\/noindex>.<\/p>\n
Die Hauptursachen f\u00fcr RPC-Fehler in unseren Protokollen sind fehlgeschlagene Versuche der Interaktion zwischen VBR-Komponenten (Server > Proxy, zum Beispiel) und meistens aufgrund von Kommunikationsproblemen.<\/p>\n
Die Spitzenposition unter allen Fehlern belegt der Fehler The RPC server is unavailable (1722). Wenn man es einfach ausdr\u00fcckt, konnte der Client keine Verbindung zum Server herstellen. Warum das so ist \u2014 eine einheitliche Antwort gibt es nicht, aber normalerweise handelt es sich um ein Authentifizierungsproblem oder um den Netzwerkzugang zum Port 135. Letzteres ist typisch f\u00fcr Infrastrukturen mit dynamischer Portzuweisung. Dazu gibt es sogar ein separates KB<\/u><\/a><\/noindex>. Und bei Microsoft \u2014 umfassenden Leitfaden<\/u><\/a><\/noindex> zur Fehlersuche.<\/p>\n
Der zweith\u00e4ufigste Fehler: There are no more endpoints available from the endpoint mapper (1753). Der RPC-Client oder -Server konnte sich keinen Port zuweisen. Dies tritt normalerweise auf, wenn der Server (in unserem Fall die Gastmaschine) f\u00fcr die dynamische Portzuweisung aus einem engen Bereich konfiguriert war, der ersch\u00f6pft ist. Wenn wir vom Client aus (in unserem Fall vom VBR-Server) betrachten, bedeutet das, dass unser VeeamVssAgent entweder nicht gestartet wurde oder nicht als RPC-Schnittstelle registriert wurde. Auch zu diesem Thema gibt es ein separates KB<\/u><\/a><\/noindex>.<\/p>\n
Und um die Top-3 der RPC-Fehler abzuschlie\u00dfen, erinnern wir an RPC function call failed (1726). Dieser tritt auf, wenn die Verbindung hergestellt wurde, aber die RPC-Anfragen nicht bearbeitet werden. Zum Beispiel fragen wir Informationen \u00fcber den Status von VSS an (vielleicht wird gerade eine Schattenkopie erstellt, w\u00e4hrend wir versuchen darauf zuzugreifen), und wir erhalten nur Stille und Ignorieren als Antwort.<\/p>\n
Windows Tape Backup API <\/strong>ben\u00f6tigt f\u00fcr die Arbeit mit Bandbibliotheken oder Laufwerken. Wie ich zu Beginn erw\u00e4hnt habe: eigene Treiber zu schreiben und sich dann mit der Unterst\u00fctzung jedes Ger\u00e4ts herumzuschlagen, macht uns keinen Spa\u00df. Deshalb gibt es bei Veeam keine eigenen Treiber. Alles l\u00e4uft \u00fcber die standardm\u00e4\u00dfige API, deren Unterst\u00fctzung die Hardwareanbieter selbst realisieren. Das ist doch viel logischer, oder?<\/p>\n
SMB\/CIFS<\/strong> Alle schreiben sie gewohnheitsm\u00e4\u00dfig nebeneinander, obwohl l\u00e4ngst nicht alle wissen, dass CIFS (Common Internet File System) einfach eine private Version von SMB (Server Message Block) ist. Daher ist es nicht schlecht, diese Begriffe zu verallgemeinern. Samba ist bereits die Linux\/Unix-Implementierung, und es gibt eigene Besonderheiten, aber das lenkt ab. Was hier wichtig ist: Wenn Veeam darum bittet, etwas \u00fcber einen UNC-Pfad (serverdirectory) zu schreiben, verwendet der Server die Hierarchie der Dateisystemtreiber, einschlie\u00dflich mup und mrxsmb, um auf die Freigabe zu schreiben. Dementsprechend werden auch diese Treiber Fehler generieren.<\/p>\n
L\u00e4sst sich nicht umgehen Winsock API<\/strong>. Wenn etwas \u00fcber das Netzwerk gemacht werden muss, arbeitet VBR \u00fcber die Windows Socket API, allgemein bekannt als Winsock. Wenn wir also im Protokoll die Kombination IP:Port sehen, ist das es. In der offiziellen Dokumentation gibt es eine ganz ordentliche Liste m\u00f6glicher Fehler<\/u><\/a><\/noindex>.<\/p>\n
Das oben erw\u00e4hnte WMI<\/strong> (Windows Management Instrumentation) \u2014 ist eine umfassende API zur Verwaltung aller Aspekte der Windows-Welt. Zum Beispiel erfolgen beim Arbeiten mit Hyper-V nahezu alle Anfragen an den Host \u00fcber diese API. Es ist eine unverzichtbare und \u00e4u\u00dferst leistungsstarke Ressource. In Versuchen, herauszufinden, wo und was kaputt ist, ist das integrierte Tool WBEMtest.exe \u00e4u\u00dferst hilfreich.<\/p>\n
Und der letzte auf der Liste, jedoch keineswegs weniger bedeutend \u2014 VSS<\/strong> (Volume Shadow Storage). Das Thema ist so unergr\u00fcndlich und geheimnisvoll, wie viel dar\u00fcber dokumentiert wurde. Shadow Copy l\u00e4sst sich am besten als eine besondere Art von Snapshot verstehen, der im Grunde genau das ist. Dank ihm k\u00f6nnen in VMware anwendungskonsistente Backups erstellt werden, w\u00e4hrend in Hyper-V beinahe alles getan werden kann. Ich plane, einen eigenen Artikel mit einer Art Zusammenfassung zu VSS zu erstellen, aber bis dahin k\u00f6nnt ihr versuchen, diese Beschreibung<\/u><\/a><\/noindex>. Seid nur vorsichtig, denn der Versuch, VSS aus dem Stegreif zu verstehen, kann zu Gehirnersch\u00fctterungen f\u00fchren.<\/p>\n
Damit k\u00f6nnen wir wohl auch aufh\u00f6ren. Ich betrachte die Aufgabe, die grundlegendsten Dinge zu erkl\u00e4ren, als erf\u00fcllt, sodass wir im n\u00e4chsten Kapitel bereits die Protokolle betrachten werden. Aber wenn noch Fragen offenbleiben, z\u00f6gert nicht, sie 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 Wahrsagens fort...","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...","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}