Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Protokollverwaltung in StorageGRID konfigurieren

Beitragende netapp-pcarriga
Änderungen vorschlagen
PDFs

Bei Bedarf können Audit-Stufen, Protokoll-Header, der Speicherort von Audit-Meldungen und Protokollen sowie die Protokollaufbewahrung konfiguriert werden.

Alle StorageGRID-Knoten generieren Revisionsprotokoll-Meldungen und Protokolle, um Systemaktivitäten und Ereignisse zu verfolgen. Revisionsprotokoll-Meldungen und Protokolle sind unerlässliche Werkzeuge für die Überwachung und Fehlerbehebung.

Optional kann "Konfiguration eines externen Syslog-Servers" verwendet werden, um Revisionsinformationen extern zu speichern. Die Leistungsbeeinträchtigung durch die Protokollierung von Auditmeldungen lässt sich minimieren, ohne die Vollständigkeit der Auditdaten zu reduzieren, wenn ein externer Server verwendet wird. Ein externer Syslog-Server ist besonders nützlich, wenn Sie ein großes Grid betreiben, mehrere Arten von S3-Anwendungen verwenden oder alle Revisionsprotokoll-Daten speichern möchten.

Bevor Sie beginnen

Ebenen der Revisionsprotokollmeldungen ändern

Für jede der folgenden Kategorien von Meldungen im Revisionsprotokoll kann ein unterschiedliches Prüfprotokollierungsniveau festgelegt werden:

Prüfkategorie Standardeinstellung Weitere Informationen

System

Normal

"System-Revisionsmeldungen"

Storage

Fehler

"Objektspeicher Revisionsprotokollmeldungen"

Management

Normal

"Management-Revisionsprotokollmeldung"

Client-Lesevorgänge

Normal

"Client-Lese-Revisionsprotokollmeldungen"

Client schreibt

Normal

"Client schreibt Revisionsprotokollmeldungen"

ILM

Normal

"ILM-Revisionsprotokollmeldungen"

Gridübergreifende Replikation

Fehler

"CGRR: Cross-Grid-Replikationsanforderung"
Hinweis Während Aktualisierungen werden Revisionsprotokoll-Konfigurationen nicht sofort wirksam.
Schritte

  1. Konfiguration > Überwachung > Protokollverwaltung auswählen.

  2. Für jede Kategorie von Prüfmeldungen wird eine Prüfstufe aus der Dropdown-Liste ausgewählt:

    Audit-Ebene Beschreibung

    Aus

    Es werden keine Revisionsprotokollmeldungen aus dieser Kategorie protokolliert.

    Fehler

    Es werden nur Fehlermeldungen protokolliert, also Revisionsprotokoll-Meldungen, deren Ergebniscode nicht „erfolgreich“ (SUCS) war.

    Normal

    Standardmäßige Transaktionsmeldungen werden protokolliert, also die in dieser Anleitung für die jeweilige Kategorie aufgeführten Meldungen.

    Debug

    Veraltet. Diese Stufe verhält sich genauso wie die normale Revisionsprotokoll-Stufe.

    Die für eine bestimmte Stufe enthaltenen Meldungen umfassen auch diejenigen, die auf höheren Stufen protokolliert würden. Zum Beispiel enthält die Stufe Normal alle Fehlermeldungen.

    Hinweis Wenn keine detaillierte Aufzeichnung der Client-Lesevorgänge für Ihre S3-Anwendungen erforderlich ist, kann die Einstellung Client Reads optional auf Error geändert werden, um die Anzahl der im Revisionsprotokoll erfassten Audit-Meldungen zu verringern.

  3. Speichern auswählen.

HTTP-Anfrageheader festlegen

Optional können Sie beliebige HTTP-Anforderungsheader definieren, die in Audit-Meldungen für Lese- und Schreibvorgänge des Clients aufgenommen werden.

Schritte

  1. Im Abschnitt Revisionsprotokoll-Header werden die HTTP-Anforderungsheader definiert, die in die Lese- und Schreib-Revisionsprotokollmeldungen des Clients aufgenommen werden sollen.

    Ein Sternchen (*) dient als Platzhalter, um null oder mehr Zeichen abzugleichen. Die Escape-Sequenz (\*) dient dazu, ein tatsächliches Sternchen abzugleichen.

  2. Weitere Überschrift hinzufügen kann ausgewählt werden, um bei Bedarf zusätzliche Überschriften zu erstellen.

    Wenn StorageGRID HTTP-Header in einer Anfrage findet, werden diese im Prüfprotokoll unter dem Feld HTRH aufgeführt.

    Hinweis Die Header der Revisionsprotokoll-Anforderungen werden nur protokolliert, wenn die Audit-Stufe für Client Reads oder Client Writes nicht auf Aus steht.

  3. Speichern auswählen

Protokollspeicherort konfigurieren

Standardmäßig werden Revisionsprotokoll-Meldungen und Protokolle auf den Knoten gespeichert, auf denen sie generiert werden. StorageGRID rotiert und löscht Audit-Meldungen und Protokolle regelmäßig, um zu verhindern, dass sie übermäßig viel Speicherplatz belegen. Um Audit-Meldungen und eine Teilmenge der Protokolle extern zu speichern, einen externen Syslog Server verwenden.

Wenn Sie die Protokolldateien intern speichern möchten, wählen Sie einen Mandanten und einen Bucket für die Protokollspeicherung und aktivieren Sie die Protokollarchivierung.

Einen externen Syslog-Server verwenden

Optional kann ein externer Syslog-Server konfiguriert werden, um Revisionsprotokolle, Anwendungsprotokolle und Sicherheitsereignisprotokolle an einem Ort außerhalb Ihres Grids zu speichern.

Hinweis Wenn kein externer Syslog-Server verwendet werden soll, diesen Schritt überspringen und zu Protokollspeicherort auswählen gehen.
Tipp Wenn die in diesem Verfahren verfügbaren Konfigurationsoptionen nicht flexibel genug sind, um Ihre Anforderungen zu erfüllen, können zusätzliche Konfigurationsoptionen mithilfe der audit-destinations Endpunkte angewendet werden, die sich im privaten API-Bereich der "Grid Management API" befinden. Beispielsweise kann die API verwendet werden, wenn für verschiedene Knotengruppen unterschiedliche Syslog-Server genutzt werden sollen.

Syslog-Informationen eingeben

Im Assistenten „Externen Syslog-Server konfigurieren“ werden die Informationen bereitgestellt, die StorageGRID für den Zugriff auf den externen Syslog-Server benötigt.

Schritte

  1. Auf der Registerkarte „Lokaler Knoten und externer Server“ die Option Externen Syslog-Server konfigurieren auswählen. Oder, falls zuvor bereits ein externer Syslog-Server konfiguriert wurde, die Option Externen Syslog-Server bearbeiten auswählen.

    Der Assistent zum Konfigurieren des externen Syslog-Servers wird angezeigt.

  2. Für den Schritt Syslog-Informationen eingeben des Assistenten ist im Feld Host eine gültige vollqualifizierte Domain oder eine IPv4- oder IPv6-Adresse für den externen Syslog-Server einzugeben.

  3. Geben Sie den Zielport auf dem externen Syslog-Server ein (muss eine ganze Zahl zwischen 1 und 65535 sein). Der Standardport ist 514.

  4. Das Protokoll, das zum Senden von Revisionsprotokollinformationen an den externen Syslog-Server verwendet wird, auswählen.

    Die Verwendung von TLS oder RELP/TLS wird empfohlen. Zum Verwenden einer dieser Optionen muss ein Serverzertifikat hochgeladen werden. Die Verwendung von Zertifikaten trägt zur Absicherung der Verbindungen zwischen Ihrem Grid und dem externen Syslog-Server bei. Weitere Informationen finden sich unter "Sicherheitszertifikate verwalten".

    Alle Protokolloptionen erfordern die Unterstützung und Konfiguration durch den externen Syslog-Server. Es ist eine Option auszuwählen, die mit dem externen Syslog-Server kompatibel ist.

    Hinweis Das Reliable Event Logging Protocol (RELP) erweitert die Funktionalität des Syslog-Protokolls und gewährleistet die zuverlässige Zustellung von Ereignismeldungen. Durch den Einsatz von RELP kann der Verlust von Revisionsprotokollinformationen verhindert werden, falls Ihr externer Syslog-Server neu gestartet werden muss.

  5. Wählen Sie Weiter.

  6. Wenn TLS oder RELP/TLS ausgewählt wurde, sind die Server-CA-Zertifikate, das Client-Zertifikat und der private Client-Schlüssel hochzuladen.

    1. Wählen Sie Durchsuchen für das Zertifikat oder den Schlüssel aus, den Sie verwenden möchten.

    2. Wählen Sie die Zertifikats- oder Schlüsseldatei aus.

    3. Öffnen auswählen, um die Datei hochzuladen.

      Neben dem Namen der Zertifikats- oder Schlüsseldatei erscheint ein grünes Häkchen, das anzeigt, dass die Datei erfolgreich hochgeladen wurde.

  7. Wählen Sie Weiter.

Syslog-Inhalte verwalten

Sie können auswählen, welche Informationen an den externen Syslog Server gesendet werden.

Schritte

  1. Für den Schritt Syslog-Inhalte verwalten des Assistenten wird jede Art von Revisionsinformationen ausgewählt, die an den externen Syslog-Server gesendet werden soll.

    • Revisionsprotokolle senden: Sendet StorageGRID Ereignisse und Systemaktivitäten

    • Sicherheitsereignisse senden: Sendet Sicherheitsereignisse, wie wenn ein nicht autorisierter Benutzer versucht, sich anzumelden, oder ein Benutzer sich als Root anmeldet

    • Anwendungsprotokolle senden: Sendet "Protokolldateien der StorageGRID Software" nützliche Informationen zur Fehlerbehebung, einschließlich:

      • bycast-err.log

      • bycast.log

      • jaeger.log

      • nms.log (nur für Administratorknoten)

      • prometheus.log

      • raft.log

      • hagroups.log

    • Zugriffsprotokolle senden: Sendet HTTP-Zugriffsprotokolle für externe Anfragen an Grid Manager, Tenant Manager, konfigurierte Load Balancer-Endpunkte und Grid Federation-Anfragen von Remote-Systemen.

  2. Mit den Dropdown-Menüs lassen sich der Schweregrad und die Einrichtung (Nachrichtentyp) für jede Kategorie von Revisionsprotokoll-Informationen auswählen, die Sie senden möchten.

    Die Festlegung von Schweregrad- und Anlagenwerten kann dabei helfen, die Protokolle auf anpassbare Weise zu aggregieren und so die Analyse zu erleichtern.

    1. Für Schweregrad entweder Durchleitung auswählen oder einen Schweregradwert zwischen 0 und 7 festlegen.

      Wenn Sie einen Wert auswählen, wendet StorageGRID den ausgewählten Wert auf alle Nachrichten dieses Typs an. Details zu verschiedenen Schweregraden gehen verloren, wenn der Schweregrad durch einen festen Wert überschrieben wird.

      Schwere Beschreibung

      Durchleitung

      Jede an das externe Syslog gesendete Nachricht weist denselben Schweregrad auf wie bei der lokalen Protokollierung auf dem Knoten:

      • Für Revisionsprotokolle ist der Schweregrad "info".

      • Für Sicherheitsereignisse werden die Schweregrade von der Linux-Distribution auf den Knoten generiert.

      • Für Anwendungsprotokolle variieren die Schweregrade je nach Problem zwischen „info“ und „notice“. Beispielsweise ergibt das Hinzufügen eines NTP-Servers und das Konfigurieren einer HA-Gruppe den Wert „info“, während das absichtliche Stoppen des SSM- oder RSM-Dienstes den Wert „notice“ ergibt.

      • Für Zugriffsprotokolle ist der Schweregrad "info".

      0

      Notfall: System ist nicht verwendbar

      1

      Warnung: Sofortiges Handeln erforderlich

      2

      Kritisch: Kritische Bedingungen

      3

      Fehler: Fehlerbedingungen

      4

      Warnung: Warnbedingungen

      5

      Hinweis: Normaler, aber bedeutsamer Zustand

      6

      Informational: Informationsmeldungen

      7

      Debug: Meldungen auf Debug-Ebene

    2. Für Anlage ist entweder Durchleitung auszuwählen oder ein Anlagenwert zwischen 0 und 23.

      Wenn Sie einen Wert auswählen, wird dieser auf alle Nachrichten dieses Typs angewendet. Informationen zu verschiedenen Facilities gehen verloren, wenn Sie Facility mit einem festen Wert überschreiben.

    Einrichtung Beschreibung

    Durchleitung

    Jede an das externe Syslog gesendete Nachricht hat denselben Facility-Wert wie bei der lokalen Protokollierung auf dem Knoten:

    • Für Revisionsprotokolle wird die Facility "local7" an den externen Syslog-Server gesendet.

    • Für Sicherheitsereignisse werden die Facility-Werte von der Linux-Distribution auf den Knoten generiert.

    • Für Anwendungsprotokolle haben die an den externen Syslog-Server gesendeten Anwendungsprotokolle die folgenden Facility-Werte:

      • bycast.log: Benutzer oder Daemon

      • bycast-err.log: Benutzer, Daemon, local3 oder local4

      • jaeger.log: local2

      • nms.log: local3

      • prometheus.log: local4

      • raft.log: local5

      • hagroups.log: local6

    • Für Zugriffsprotokolle wird die Facility "local0" an den externen Syslog-Server gesendet.

    0

    kern (Kernelmeldungen)

    1

    Benutzer (Meldungen auf Benutzerebene)

    2

    E-Mail

    3

    Daemon (Systemdaemons)

    4

    auth (Sicherheits-/Autorisierungsmeldungen)

    5

    syslog (Meldungen, die intern von syslogd generiert werden)

    6

    lpr (Zeilendrucker Subsystem)

    7

    Nachrichten (Netzwerknachrichten Subsystem)

    8

    UUCP

    9

    cron (Uhr-Daemon)

    10

    Sicherheit (Sicherheits-/Autorisierungsmeldungen)

    11

    FTP

    12

    NTP

    13

    logaudit (Revisionsprotokoll)

    14

    logalert (Protokollwarnung)

    15

    Uhr (Uhr-Daemon)

    16

    local0

    17

    local1

    18

    local2

    19

    local3

    20

    local4

    21

    local5

    22

    local6

    23

    local7

  3. Wählen Sie Weiter.

Testnachrichten senden

Bevor ein externer Syslog-Server verwendet wird, sollte veranlasst werden, dass alle Knoten im Grid Testnachrichten an den externen Syslog-Server senden. Diese Testnachrichten unterstützen die Validierung der gesamten Protokollerfassungsinfrastruktur, bevor die Übertragung von Daten an den externen Syslog-Server festgelegt wird.

Achtung Die Konfiguration des externen Syslog Servers sollte erst verwendet werden, nachdem bestätigt wurde, dass der externe Syslog Server von jedem Knoten in Ihrem Grid eine Testnachricht erhalten hat und dass die Nachricht wie erwartet verarbeitet wurde.
Schritte

  1. Wenn Sie keine Testnachrichten senden möchten, weil Sie sicher sind, dass Ihr externer Syslog Server ordnungsgemäß konfiguriert ist und Revisionsprotokoll-Informationen von allen Knoten in Ihrem Grid empfangen kann, wählen Sie Überspringen und beenden.

    Ein grünes Banner signalisiert, dass die Konfiguration gespeichert wurde.

  2. Andernfalls Testnachrichten senden auswählen (empfohlen).

    Testergebnisse werden fortlaufend auf der Seite angezeigt, bis der Test beendet wird. Während der Test läuft, werden Ihre Revisionsprotokollmeldungen weiterhin an die zuvor konfigurierten Ziele gesendet.

  3. Wenn während der Konfiguration des Syslog-Servers oder zur Laufzeit Fehler auftreten, sollten diese behoben werden und Testnachrichten senden erneut ausgewählt werden.

    Siehe "Fehlerbehebung bei einem externen Syslog Server" zur Unterstützung bei der Behebung etwaiger Fehler.

  4. Warten Sie, bis ein grünes Banner angezeigt wird, das bestätigt, dass alle Knoten die Tests bestanden haben.

  5. Prüfen Sie auf Ihrem Syslog-Server, ob Testnachrichten wie erwartet empfangen und verarbeitet werden.

    Hinweis Wenn Sie UDP verwenden, überprüfen Sie Ihre gesamte Infrastruktur zur Protokollerfassung. Das UDP-Protokoll ermöglicht keine so strenge Fehlererkennung wie die anderen Protokolle.

  6. Stoppen und beenden auswählen.

    Sie werden zurück zur Seite Audit und syslog server geleitet. Ein grünes Banner zeigt an, dass die syslog server-Konfiguration gespeichert wurde.

    Hinweis StorageGRID Revisionsprotokollinformationen werden erst an den externen Syslog-Server gesendet, wenn ein Ziel ausgewählt wird, das den externen Syslog-Server enthält.

Protokollspeicherort auswählen

Sie können festlegen, wohin Revisionsprotokolle, Sicherheitsereignisprotokolle, "StorageGRID Anwendungsprotokolle" und Zugriffsprotokolle gesendet werden.

Hinweis

StorageGRID verwendet standardmäßig lokale Knoten als Revisionsprotokollziele und speichert die Revisionsprotokollinformationen in /var/local/log/localaudit.log.

Bei Verwendung von `/var/local/log/localaudit.log`Grid Manager und Tenant Manager Revisionsprotokoll werden die Revisionsprotokoll-Einträge möglicherweise an einen Storage Node gesendet. Es lässt sich mit dem `run-each-node --parallel "zgrep MGAU /var/local/log/localaudit.log | tail"`Befehl feststellen, welcher Node die aktuellsten Einträge enthält.

Einige Ziele sind nur verfügbar, wenn ein externer Syslog-Server konfiguriert wurde.
Schritte

  1. Wählen Sie Protokollspeicherort > Lokaler Knoten und externer Server.

  2. Zum Ändern des Speicherorts für die Protokolltypen kann eine andere Option ausgewählt werden.

    Tipp Nur lokale Knoten und Externer Syslog-Server bieten in der Regel bessere Leistung.
    Option Beschreibung

    Nur lokale Knoten (Standard)

    Audit-Meldungen, Sicherheitsereignisprotokolle und Anwendungsprotokolle werden nicht an Admin-Nodes gesendet. Stattdessen werden sie nur auf den Knoten gespeichert, die sie generiert haben („dem lokalen Knoten“). Die auf jedem lokalen Knoten generierten Audit-Informationen werden in /var/local/log/localaudit.log gespeichert.

    Hinweis: StorageGRID entfernt lokale Protokolle regelmäßig in einer Rotation, um Speicherplatz freizugeben. Wenn die Protokolldatei eines Knotens 1 GB erreicht, wird die bestehende Datei gespeichert und eine neue Protokolldatei gestartet. Das Rotationslimit für das Protokoll beträgt 21 Dateien. Wenn die 22. Version der Protokolldatei erstellt wird, wird die älteste Protokolldatei gelöscht. Im Durchschnitt werden auf jedem Knoten etwa 20 GB Protokolldaten gespeichert. Um Protokolle über einen längeren Zeitraum zu speichern, Ein Mandant und ein Bucket für die Protokollspeicherung verwenden.

    Admin Nodes/lokale Knoten

    Audit-Meldungen werden an das Revisionsprotokoll auf den Admin Nodes gesendet, und Sicherheitsereignisprotokolle sowie Anwendungsprotokolle werden auf den Nodes gespeichert, die sie generiert haben. Die Audit-Informationen werden in den folgenden Dateien gespeichert:

    • Admin Nodes (primäre und nicht-primäre): /var/local/audit/export/audit.log

    • Alle Knoten: Die /var/local/log/localaudit.log Datei ist in der Regel leer oder fehlt. Sie kann sekundäre Informationen enthalten, wie eine zusätzliche Kopie einiger Nachrichten.

    Externer Syslog Server

    Audit-Informationen werden an einen externen Syslog-Server gesendet und auf den lokalen Knoten gespeichert (/var/local/log/localaudit.log). Die Art der gesendeten Informationen hängt davon ab, wie der externe Syslog-Server konfiguriert wurde. Diese Option ist erst aktiviert, nachdem Sie einen externen Syslog Server konfiguriert.

    Admin Nodes und externer Syslog-Server

    Audit-Meldungen werden an das Revisionsprotokoll (/var/local/audit/export/audit.log) auf den Admin-Knoten gesendet, und Audit-Informationen werden an den externen Syslog-Server gesendet und auf dem lokalen Knoten gespeichert (/var/local/log/localaudit.log). Die Art der gesendeten Informationen hängt davon ab, wie der externe Syslog-Server konfiguriert wurde. Diese Option ist erst aktiviert, nachdem Sie einen externen Syslog Server konfiguriert haben.

  3. Speichern auswählen.

    Es erscheint eine Warnmeldung.

  4. Wählen Sie OK, um zu bestätigen, dass Sie das Ziel für die Revisionsprotokollinformationen ändern möchten.

    Neue Protokolldateien werden an die von Ihnen ausgewählten Ziele gesendet. Vorhandene Protokolldateien bleiben an ihrem aktuellen Speicherort.

Einen Bucket verwenden

Protokolldateien werden regelmäßig rotiert. Ein S3-Bucket im selben Grid dient zur Speicherung von Protokolldateien über einen längeren Zeitraum.

  1. Wählen Sie Protokollspeicherort > Bucket verwenden.

  2. Das Kontrollkästchen Archivprotokolle aktivieren auswählen.

  3. Falls der angezeigte Mandant und Bucket nicht die gewünschten sind, Mandant und Bucket ändern auswählen und anschließend entweder Mandant und Bucket erstellen oder Mandant und Bucket auswählen wählen.

    Mandant und Bucket erstellen

    1. Einen neuen Mieternamen eingeben.

    2. Ein Passwort für den neuen Mandanten eingeben und bestätigen.

    3. Geben Sie einen neuen Bucket Namen ein.

    4. Erstellen und aktivieren auswählen.

    Mandant und Bucket auswählen

    1. Einen Mandantennamen aus der Auswahlliste auswählen.

    2. Einen Bucket aus dem Dropdown-Menü auswählen.

    3. Auswählen und aktivieren auswählen.

  4. Speichern auswählen.

    Die Protokolle werden im von Ihnen angegebenen Mandanten und Bucket gespeichert. Der Objektschlüsselname für die Protokolle hat folgendes Format:

    system-logs/{node_hostname}/{absolute_path_to_log_file_on_node}--{last_modified_time}.gz

    Beispiel:

    system-logs/DC1-SN1/var/local/log/localaudit.log--2025-05-12_13:41:44.gz

Protokollaufbewahrung verwalten

Sie können steuern, wie lange StorageGRID Protokolle aufbewahrt, indem Sie eine ILM-Regel erstellen oder eine S3-Bucket-Lebenszyklusrichtlinie konfigurieren.

ILM Regel

Eine ILM-Regel für den Bucket erstellen und diese Regel zur aktiven ILM-Richtlinie hinzufügen.

Schritte

  1. Wählen Sie ILM > Regeln.

  2. Die Option Create wird ausgewählt. "Schritt 1 (Details eingeben)"Der Assistent zum Erstellen einer ILM-Regel wird angezeigt:

    1. Geben Sie einen eindeutigen Namen für die Regel ein. Zum Beispiel: ILM Regel für archivierte Protokolle.

    2. Das S3-Mandantenkonto für die Protokollarchivierung auswählen.

    3. Geben Sie den S3-Bucket für die Protokollarchivierung an.

  3. Weiter zu "Schritt 2 (Platzierungen definieren)" und die Platzierung für die Regel für archivierte Protokolle definieren. Beispielsweise speichert die ILM-Regel im ersten Jahr eine replizierte Kopie an Standort 1 und eine replizierte Kopie an Standort 2. Nach einem Jahr wird eine 2+1 erasure-coded Kopie erstellt und nur an einem Standort gespeichert.

  4. Nach dem Erstellen der Regel wird sie einer aktiven ILM-Richtlinie hinzugefügt.

S3 Bucket Lebenszyklus

Eine S3-Bucket-Lebenszyklusrichtlinie für den S3-Bucket zur Protokollarchivierung konfigurieren:

{
      "Rules": [
        {
            "ID": "Retain logs forever",
            "Filter": {},
            "Status": "Enabled"，
            "Expiration": {}
        }
      ]
}

Wenn Sie eine S3-Bucket-Lifecycle-Richtlinie für den S3-Bucket zur Protokollarchivierung konfigurieren, überschreiben die Ablaufaktionen die ILM-Richtlinie für Objekte, die dem Bucket-Lifecycle-Filter entsprechen. Objekte, die dem Bucket-Lifecycle-Filter nicht entsprechen, verwenden die Aufbewahrungseinstellungen der ILM-Richtlinie. Wenn ein Objekt einem Bucket-Lifecycle-Filter entspricht und keine Ablaufaktionen explizit angegeben sind, werden die Aufbewahrungseinstellungen der ILM-Richtlinie nicht verwendet, und es gilt, dass Objektversionen unbegrenzt aufbewahrt werden.