Erweiterte Richtlinieneinstellungen in der Appliance-Verwaltungskonsole konfigurieren

Auf dieser Seite sind die erweiterten Einstellungen für eine Vorlage für eine Sicherungskonfigurationsrichtlinie aufgeführt. Sie können die erweiterten Richtlinieneinstellungen beim Erstellen einer Sicherungsrichtlinie definieren.

Sie können die Richtlinieneinstellungen für bestimmte Anwendungen auch aufrufen und ändern, indem Sie den Bereich „Richtlinienüberschreibungen“ auf der Seite Sicherungsplan verwalten für die Anwendung aufrufen.

Gehen Sie so vor, um die Seite mit den Richtlinieneinstellungen aufzurufen.

  1. Klicken Sie in der Appliance-Verwaltungskonsole auf den Tab Sicherungspläne und wählen Sie im Drop-down-Menü die Option Vorlagen aus.
  2. Wählen Sie die Vorlage aus, die Sie verwalten möchten, und klicken Sie dann rechts unten auf der Seite im Drop-down-Menü auf Bearbeiten.
  3. Klicken Sie auf der Vorlagenseite rechts neben der Richtlinie, die Sie verwalten möchten, auf den weißen Pfeil. Klicken Sie unten in der Auswahl auf Richtlinie bearbeiten.
  4. Klicken Sie unten im Bereich Richtlinie erstellen/bearbeiten auf Erweiterte Richtlinieneinstellungen. Daraufhin werden die erweiterten Richtlinieneinstellungen geöffnet, die in der folgenden Tabelle beschrieben werden.

  5. Wenn Sie fertig sind, klicken Sie auf Änderungen speichern, um die Einstellungen zu aktualisieren.

In der folgenden Tabelle werden die erweiterten Richtlinieneinstellungen beschrieben.

               
Erweiterte Einstellung Beschreibung
Anwendungskonsistent
(gilt nur für Google Cloud VMware Engine-VMs und Compute Engine-VMs)		 Wählen Sie eine der folgenden Optionen aus:
  • Absturzkonsistente Sicherung: Eine absturzkonsistente Sicherung ist eine schnelle Sicherung von Anwendungsdaten im Speicher, als ob in diesem Moment die Stromversorgung unterbrochen worden wäre. Die Ein-/Ausgabe von Anwendungsdaten wird dadurch nicht pausiert. Alle Daten auf der Festplatte werden gespeichert, Daten im Arbeitsspeicher gehen verloren. Die Wiederherstellung einer absturzkonsistenten Sicherung kann länger dauern und Ausnahmen verursachen. Je nach Gastbetriebssystem, Dateisystemen und Anwendungen sind während der Wiederherstellung möglicherweise zusätzliche manuelle Wiederherstellungsschritte erforderlich. Wählen Sie „Absturzkonsistent“ aus, wenn der anwendungskonsistente Prozess aufgrund des Ruhezustands Probleme für Ihre Anwendungen oder Arbeitslasten verursacht. Bei Absturzkonsistenz kann es zu einer längeren RTO kommen, da das Dateisystem oder die Anwendung eine Wiederherstellung aus dem inkonsistenten Snapshot durchführen muss. In extremen Fällen kann dies sogar zu einem nicht wiederherstellbaren Snapshot führen.
  • Anwendungskonsistente Sicherung erstellen: Bei der anwendungskonsistenten Sicherung werden inaktive Snapshots verwendet, bei denen das Dateisystem der VM mithilfe von VMware-Tools oder einer Google Cloud Gastumgebung inaktiviert wird. Bei einem Quiesce-Vorgang werden die integrierten Funktionen von Windows genutzt, um Dateisysteme und Anwendungen, die VSS unterstützen, in den Ruhezustand zu versetzen. Außerdem werden alle vom Kunden bereitgestellten Freeze- oder Thaw-Skripts (auf allen Plattformen) verwendet, um eine höhere Anwendungsübereinstimmung zu erzielen. Das Ergebnis ist ein höheres Konfidenzniveau in Bezug auf die Wiederherstellbarkeit der Sicherung sowie in den meisten Fällen kürzere Wiederherstellungszeiten. Anwendungskonsistente Sicherungen können manchmal zu einer kurzen Pause bei der Ein-/Ausgabe führen. Bei einigen stark ausgelasteten Anwendungen können zum Zeitpunkt der Sicherung Ein-/Ausgabefehler auftreten. Gelegentlich schlagen anwendungskonsistente Sicherungen fehl, wenn VMware die VM während des Snapshot-Vorgangs nicht innerhalb eines vorgegebenen Zeitlimits in den Ruhezustand versetzen kann. Verwenden Sie anwendungskonsistente Sicherungen, wenn die Wiederherstellbarkeit am wichtigsten ist und die Anwendungen auf der VM nicht empfindlich auf die kurze E/A-Pause reagieren.
    Weitere Informationen finden Sie im Abschnitt Anwendungskonsistenten Snapshot von nichtflüchtigem Speicher unter Linux erstellen.

    Wenn Sie einen Windows Compute Engine-Snapshot als neue oder vorhandene VM einbinden möchten, die mit der Option Anwendungskonsistent erfasst wurde, müssen Sie das Laufwerk vom Lesemodus in den Lese-/Schreibmodus ändern. Folgen Sie dazu der Anleitung unter Optional: Laufwerk als für Lesen/Schreiben verfügbar markieren.
  • Beim letzten Versuch eine absturzkonsistente Sicherung erstellen: Diese Option erstellt zuerst anwendungskonsistente Sicherungen. Wenn eine anwendungskonsistente Sicherung aus irgendeinem Grund fehlschlägt, wird eine absturzkonsistente Sicherung erstellt.
    •
    Snapshot-Speicherort
    (gilt nur für Compute Engine- und SAP HANA-Instanzen)    		 Wählen Sie die Region aus, in der die Persistent Disk-Snapshots gespeichert werden sollen. Standardmäßig ist „Multiregion“ ausgewählt (basierend auf dem Standort des Quelllaufwerks). Sie können den Speicherort des Snapshots auch in eine andere Region als die Region des Quelllaufwerks ändern. Wenn Sie Snapshots an einem anderen Speicherort als dem Ihres Quelllaufwerks speichern, werden die Daten über das Netzwerk zwischen diesen Speicherorten übertragen. Dabei können Netzwerkgebühren anfallen. Für Snapshots fallen dieselben Gebühren wie für den Cloud Storage-Datentransfer an. Weitere Informationen zu Snapshots von nichtflüchtigem Speicher Weitere Preisinformationen finden Sie unter Laufwerk-Preise.
    Snapshot-Typ      
    (gilt nur für Compute Engine- und SAP HANA-Instanzen)    		Wählen Sie den Typ des Persistent Disk-Snapshots aus, der für Compute Engine-Instanzsicherungen verwendet werden soll. Mit Snapshots lassen sich Daten von nichtflüchtigen Speichern schrittweise sichern. Bei Sicherungen wird ein neuer Snapshot erstellt, um den aktuellen Zustand des nichtflüchtigen Speichers zu erfassen. Dieser kann später verwendet werden, um ein neues Laufwerk für Mounts oder Wiederherstellungen zu erstellen. Compute Engine speichert mehrere Kopien jedes Snapshots an mehreren Speicherorten mit automatischen Prüfsummen, um die Integrität der Daten zu gewährleisten. Weitere Informationen zu Snapshots von nichtflüchtigem Speicher Weitere Preisinformationen finden Sie unter Laufwerk-Preise.
  • Standard: Der Snapshot-Typ „Standard“ ist standardmäßig ausgewählt. Wir empfehlen, den Standardtyp zu verwenden, wenn Sie die Sicherungen weniger als 90 Tage lang aufbewahren möchten.
  • Archiv: Wählen Sie den Archivtyp aus, wenn Sie die Sicherungen über einen längeren Zeitraum aufbewahren möchten. Der Mindestabrechnungszeitraum für den Archiv-Snapshot beträgt unabhängig von der in der Richtlinie definierten Aufbewahrungsdauer 90 Tage. Für den Archivtyp fallen außerdem zusätzliche Abrufgebühren an, wenn er in einem Mount- oder Wiederherstellungsjob verwendet wird.
    •       
    Überbelegung des Staging-Laufwerks
    (in Prozent)    		 Geben Sie den zusätzlichen Speicherplatz an, der für das Staging-Laufwerk zugewiesen wird (zusätzlich zum tatsächlich benötigten Speicherplatz), um dem Wachstum der Anwendung Rechnung zu tragen. Diese Einstellung liegt zwischen 0 und 1.000 %.
    Globale Pfade kürzen Diese Verzeichnisse nicht sichern (vollständigen Pfad angeben). Weitere Informationen finden Sie auch unter „Globale Werte für das Kürzen von Pfaden auf Richtlinienebene“.
    Streamsnap-Replikation komprimieren Die Komprimierung für die Streamsnap-Replikation ist standardmäßig aktiviert. Die Komprimierung erhöht die Effizienz der Streamsnap-Replikation auf das Remote-Sicherungs-/Wiederherstellungsgerät bei der Übertragung von Daten über das Netzwerk, z. B. beim Replizieren von Sicherungen und Videos. Wenn die Komprimierung aktiviert ist, werden alle Pakete komprimiert. Das Zielgerät für die Sicherung/Wiederherstellung dekomprimiert die Pakete, bevor sie auf die Staging-Festplatte geschrieben werden. Wenn für die Streamsnap-Replikation auf das zweite Sicherungs-/Wiederherstellungsgerät keine Komprimierung erforderlich ist, ändern Sie die erweiterte Einstellung „Streamsnap-Replikation komprimieren“ in Nicht komprimieren und klicken Sie dann auf Änderungen speichern.
    Hinweis: Die Streamsnap-Replikation wird nur für die Sicherungs-/Wiederherstellungsgeräte unterstützt, die in einem einzelnen Netzwerk bereitgestellt werden.
    Nicht entkoppeln Gibt an, ob temporäre Staging-Laufwerke, die dem Host zugeordnet sind und während der Datenübertragung für die Sicherung verwendet werden, dem Host zugeordnet bleiben sollen. LUNs werden während des ersten Jobs zugeordnet und alle nachfolgenden Jobs verwenden dieselbe zugeordnete LUN. Wählen Sie eine der folgenden Optionen aus:
  • Staging-Laufwerke zwischen Jobs zuordnen Wählen Sie diese Option aus, wenn die temporären Staging-Laufwerke, die dem Host zugeordnet und während der Datenübertragung verwendet werden, dem Host zugeordnet bleiben sollen. LUNs werden während des ersten Jobs zugeordnet und alle nachfolgenden Jobs verwenden dieselbe zugeordnete LUN. Diese Option ist standardmäßig ausgewählt.
    Hinweis: Bei Anwendungen, die mit dem Backup and DR-Agent verwaltet werden (z. B. SQL-Datenbank), wenn sich die Anwendung auf einem Betriebssystem befindet, das in einer VMware-VM ausgeführt wird, wird diese Option ignoriert. Das Staging-Laufwerk wird nach jedem Job immer von der VM getrennt.
    •
  • Heben Sie die Zuordnung von Staging-Laufwerken nach jedem Job auf. Mit dieser Option wird das Staging-Laufwerk am Ende jedes Jobs sowohl vom Betriebssystem unmountet (Mount-Punkte oder Laufwerkbuchstaben werden entfernt) als auch vollständig vom Host entkoppelt. Bei dieser Option muss der Host zu Beginn des nächsten Jobs nach SCSI-LUNs suchen, da die neu zugeordneten Staging-Festplatten neu erkannt werden müssen, bevor sie wieder gemountet werden können.
    •
    Log nach der Sicherung kürzen (bereinigen) Geben Sie an, ob die Datenbankprotokolle nach jeder Sicherung gekürzt (gelöscht) werden sollen. Wenn Log nach Sicherung kürzen aktiviert ist, werden anwendungsbezogene Logs bis zur letzten oder aktuellen Sicherung gekürzt. Wenn Sie Protokolle kürzen, müssen Sie auch das Transaktionsprotokoll sichern, um eine Rollforward-Wiederherstellung zu ermöglichen.
    Folgende Optionen sind verfügbar:
  • Protokoll nach der Sicherung nicht kürzen oder löschen
    •
  • Protokoll nach der Sicherung kürzen oder löschen
    •
    Offline-Anwendungen überspringen
    (Nur für die Verwaltung von Konsistenzgruppen)    		 Geben Sie an, ob nicht verfügbare Anwendungen, die Teil einer Konsistenzgruppe sind, ignoriert werden sollen. Sie erstellen eine Konsistenzgruppe, um die Daten aller Mitgliedsanwendungen gemeinsam zu sichern und so die Konsistenz der Daten in den Mitgliedsanwendungen zu wahren. Konsistenzgruppen sind Sammlungen erkannter Anwendungen vom selben Host.
    Folgende Optionen sind verfügbar:
  • Sicherung fehlgeschlagen, wenn Offlineanwendungen gefunden werden
    •
  • Offlineanwendungen bei der Sicherung überspringen
    •
    Staging-Laufwerke allen Knoten in einem Anwendungscluster zuordnen Wenn sich Ihre Knoten in einem Anwendungscluster befinden, können Sie damit sicherstellen, dass die Knoten eines Anwendungsclusters im Falle eines Failovers während der Sicherung geschützt sind.
  • Ordnen Sie das Staging-Laufwerk nicht allen Knoten des Anwendungsclusters zu.
    •
  • Staging-Laufwerk allen Knoten des Anwendungsclusters zuordnen
    Im Falle eines Ausfalls des Anwendungsclusters werden mit dieser Option Failover-Kopien geschützt.
    •
    Staging-Festplatte allen ESX-Hosts in einem Cluster zuordnen
    (Nur für VMware-VMs)     		Wenn sich Ihre ESX-Server in einem Gerät befinden, können Sie mit dieser Einstellung dafür sorgen, dass die VMs im Falle eines Failovers während der Sicherung verwaltet werden. Bei einem ESX-Hostfehler werden mit dieser Option Failover-Kopien von VMware-VMs verwaltet. (Oracle, lokale Dateisysteme, SMB, NFS, SQL Server):
  • Staging-Laufwerk nur für VM dem ESX-Host zuordnen
    •
  • Staging-Festplatte allen ESX-Hosts im Cluster zuordnen
    •
  • Staging-Festplatte zwei ESX-Hosts im Cluster zuordnen
    •
    SQL Server-Nutzeranmeldungen sichern Erfasst die Anmeldedaten für die SQL Server-Datenbank. Wenn die Datenbank als virtuelle Anwendung eingebunden wird (app-aware mount), enthält die virtuelle Datenbank alle Anmeldedaten, die von der Quelle verwendet werden. Die Optionen sind Ja oder Nein.
    Datenbank-Log-Sicherung aktivieren Mit der Option Enable Database Log Backup (Datenbank-Logsicherung aktivieren) kann die Richtlinie des Sicherungsplans eine Datenbank und alle zugehörigen Transaktionslogdateien sichern. Die Logs werden gesichert, wenn der Log-Snapshot-Job ausgeführt wird. Mögliche Werte sind „Ja“ und „Nein“. Wenn Ja festgelegt ist, sind die zugehörigen Optionen aktiviert.
    Hinweis: Weitere Informationen zum Log-Schutz finden Sie unter Datenbank-Log-Schutz in einer Sicherungsplanrichtlinie.
    RPO Wenn Datenbank-Log-Sicherung aktivieren auf Ja gesetzt ist, definiert der RPO-Wert die Häufigkeit der Datenbank-Log-Sicherung. Die Häufigkeit wird in Minuten festgelegt und darf das Intervall für die Datenbanksicherung nicht überschreiten. Der kleinste Wert, der festgelegt werden kann (in Minuten), ist 15.
    Aufbewahrungsdauer für Logsicherungen
    (in Tagen)    		 Wenn Datenbank-Log-Sicherung aktivieren auf Ja festgelegt ist, wird die Log-Aufbewahrung separat von der Aufbewahrung der Snapshot-Richtlinie definiert. Durch einen separaten Aufbewahrungszeitraum können Sie Logs in Verbindung mit Kopien der Datenbank verwenden, die im Snapshot-Pool gespeichert sind. Die Aufbewahrungsdauer für Logs ist eine Pflichteinstellung.
    Logs replizieren
    (mit Streamsnap-Technologie)    		 Wenn Enable Database Log Backup auf Enable festgelegt ist, können Datenbankprotokolle mit der erweiterten Einstellung Replicate Logs auf ein Remote-Gerät repliziert werden. Damit ein Job zur Protokollreplikation ausgeführt werden kann, muss im Template eine Streamsnap-Replikationsrichtlinie zusammen mit einem Ressourcenprofil enthalten sein, in dem ein Remote-Gerät angegeben ist. Außerdem muss mindestens eine erfolgreiche Replikation der Datenbank abgeschlossen sein. Sie können die Logs dann am Remote-Standort für alle Datenbanksicherungen innerhalb des Aufbewahrungszeitraums der replizierten Logs verwenden. Diese Funktion ist standardmäßig aktiviert.
    Bei der Logreplikation wird die StreamSnap-Technologie verwendet, um die Replikation zwischen den lokalen und Remote-Appliances durchzuführen. Die Logreplikation erfolgt direkt vom lokalen Snapshot-Pool zum Snapshot-Pool auf der Remote-Appliance.
    Hinweis: Die Protokollreplikation erfolgt erst, wenn die Datenbank geschützt und die Sicherung auf die Remote-Appliance repliziert wurde.
    Logs an OnVault-Pool senden Wenn Sie Ja festlegen, werden Protokolle in einen oder mehrere OnVault-Speicherpools repliziert, sodass die Wiederherstellung zu einem bestimmten Zeitpunkt von OnVault an einem anderen Standort möglich ist.
    Hinweis: Wenn Sie diese Option auswählen, sendet Backup and DR Logs an jeden OnVault-Pool, der im Profil für diese Anwendung definiert ist. Wenn das Profil zwei Pools enthält, werden im Monitor OnVault-Jobs (Log) für jedes Log-Backup angezeigt, einer für jeden Pool. Die Logs werden nur für OnVault-Pools im Profil für diese SLA abgerufen.
    • Die Aufbewahrung von Logs, die in OnVault repliziert werden, ähnelt der Aufbewahrung von Snapshot-Logs.
    • Das Replizieren von Datenbanklogs in einen OnVault-Bucket unterscheidet sich von einer Datenbanksicherung. Wenn Sie Logs an OnVault-Pool senden auswählen, repliziert Backup and DR die Logs kontinuierlich in OnVault-Buckets, ähnlich wie bei Log-Snapshot-Sicherungen. Wenn beispielsweise alle 15 Minuten eine Logsicherung erstellt wird, werden die Logs alle 15 Minuten in OnVault repliziert, damit alle Log-Snapshots in OnVault-Pools repliziert werden.
    • Die in der Appliance-Verwaltungskonsole angezeigte Richtlinien-ID ist die Snapshot-Richtlinien-ID, da diese Replikation von Logs in OnVault-Buckets an die Snapshot-Richtlinie gebunden ist.
    Hinweis: Die OnVault-Richtlinien für täglich, wöchentlich, monatlich und jährlich gelten nur für Datenbanksicherungen und nicht für Logsicherungen.
    Größe des Log-Staging-Laufwerks (in Prozent) Wenn Enable Database Log Backup auf Yes festgelegt ist, wird mit Log Staging Disk Growth Size die Größe für die automatische Erweiterung des Staging-Laufwerks definiert, auf dem sich die Logs befinden. Diese Einstellung liegt zwischen 5 und 100 %.
    Geschätzte Änderungsrate Wenn Datenbank-Log-Sicherung aktivieren auf Ja gesetzt ist, wird mit dieser Einstellung die tägliche Änderung (in Prozent) definiert, mit der die Appliance die Größe des Staging-Laufwerks, das zum Speichern von Logs benötigt wird, besser berechnen kann. Diese Einstellung kann einen Wert zwischen 0 und 100 haben.
    Datenbank-Logsicherung komprimieren Wenn Enable Database Log Backup auf Yes gesetzt ist, wird die Quelldatenbank angewiesen, ihre Protokolle zu komprimieren, bevor sie von der Appliance-Verwaltungskonsole erfasst werden. Der Datenbankserver führt die Logkomprimierung während der Logsicherung durch. Die Optionen sind Ja oder Nein. Wenn die Option auf Ja festgelegt ist, ist die Option Datenbank-Log-Sicherung komprimieren aktiviert.
    Erzwungene Aufbewahrung Der Nutzer kann den Zeitraum für die Unveränderlichkeit zwischen 0 und 36.525 Tagen konfigurieren. Standardmäßig ist der Wert für alle vorhandenen Richtlinien auf null gesetzt.
    Sie können eine Richtlinie, die bereits zum Schutz einer Anwendung verwendet wird, ändern, indem Sie einen längeren erzwungenen Aufbewahrungszeitraum festlegen. Sie können die erzwungene Aufbewahrungsdauer jedoch nicht verkürzen.
    Sie können keine erzwungene Aufbewahrung für eine Streamsnap-Richtlinie festlegen, deren Aufbewahrung „Nur das neueste Remote-Bild behalten“ ist.
    Hinweis: Erzwungene Aufbewahrung kann nicht pro Anwendung überschrieben werden. Die Option wird auf der Seite Richtlinienüberschreibungen nicht angezeigt.
    Hinweis: Die erweiterte Richtlinieneinstellung Erzwungene Aufbewahrung ist nicht mit dem Anwendungsschutz kompatibel, der auf einen Backup-Vault verweist. Wenn ein Backup Vault das Speicherziel ist, wird die erzwungene Aufbewahrungsdauer durch den Backup Vault bestimmt.
    Jobverhalten, wenn für die Ziel-VM eine Snapshot-Konsolidierung erforderlich ist Wählen Sie eine Aktion aus, wenn die VM konsolidiert werden muss:
  • Job fehlgeschlagen, wenn VM konsolidiert werden muss: Point-in-Time-Jobs schlagen fehl.
    •
  • Job ohne Konsolidierung ausführen: Alle Jobs werden normal ausgeführt, auch wenn eine Konsolidierung aussteht.
    •
  • Konsolidierung zu Beginn des Jobs durchführen: Bei Point-in-Time-Jobs wird versucht, die Konsolidierung zu Beginn des Jobs durchzuführen. Wenn die Konsolidierung fehlschlägt, schlägt auch der Job fehl und es wird eine Fehlermeldung angezeigt.
    •
    Fail On Missing Start Path Wenn ein oder mehrere Startpfade angegeben sind und einer dieser Startpfade nicht vorhanden ist, schlägt der Job mit der Meldung „UDSAgent: Specified start path doesn't exist“ fehl. Wenn keine Startpfade angegeben sind, hat diese Option keine Auswirkungen. Die Optionen sind Ja oder Nein.
    Hinweis: Der Standardstatus für diese Option ist „Nein“ (deaktiviert). Das entspricht dem Verhalten der vorherigen Versionen des Backup and DR-Agents. Der Job schlägt nicht fehl, wenn kein Startpfad vorhanden ist.
    Modus für eingeschränkte Aufnahme aktivieren Im eingeschränkten Erfassungsmodus werden inkrementelle Daten erfasst, wenn der Change Block Tracking-Dienst (CBT) nicht verfügbar ist. Die Datenerhebung kann länger dauern. Die Optionen sind Ja oder Nein.
    Zeitlimit für Script
    (gilt nur für agentbasierte Sicherungen)    		 Mit dem Backup and DR-Agenten können Sie hostseitige Skripts erstellen, die auf dem Host einer Anwendung vor oder nach der Ausführung einer Richtlinie ausgeführt werden. Die vier Zeitüberschreitungen in einer Richtlinienvorlage entsprechen direkt den vier Phasen eines hostseitigen Skripts.
    Hinweis: Standardmäßig gelten für die Zeitüberschreitung des Skripts die folgenden Werte. Wenn kein Script-Zeitlimit angegeben ist, ist der Wert leer und der Standardwert wird verwendet.
  • Script Init Timeout: Definiert, wie lange ein Job auf das Script warten soll, das auf dem Host aufgerufen wird, bevor eine Aktion vom Job ausgeführt wird. Wenn das Skript nicht innerhalb dieses Zeitlimits abgeschlossen wird, schlägt der Job fehl. Der Standardwert beträgt 60 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden.
    •
  • Zeitlimit für das Einfrieren von Scripts: Definiert, wie lange eine Richtlinie auf das Script warten soll, das aufgerufen wird, um eine Anwendung einzufrieren, bevor ein Snapshot erstellt wird. Wenn das Skript nicht innerhalb dieses Zeitlimits abgeschlossen wird, schlägt der Job fehl. Der Standardwert beträgt 60 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden.
  • Script Unfreeze Timeout: Definiert, wie lange eine Richtlinie auf das aufgerufene Skript warten soll, um eine Anwendung nach der Erstellung eines Snapshots zu deaktivieren. Wenn das Skript nicht innerhalb dieses Zeitlimits abgeschlossen wird, schlägt der Job fehl. Der Standardwert beträgt 60 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden.
  • Zeitüberschreitung für Script-Abschluss: Definiert, wie lange eine Richtlinie auf das Script warten soll, das ganz am Ende des Jobs aufgerufen wird. Wenn das Skript nicht innerhalb dieses Zeitlimits abgeschlossen wird, schlägt der Job fehl. Der Standardwert beträgt 60 Sekunden. Der zulässige Bereich liegt zwischen 1 und 86.400 Sekunden.
    		•

    Nächste Schritte