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 auf der Seite Sicherungsplan verwalten für die Anwendung den Bereich „Richtlinienüberschreibungen“ 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 auf den weißen Pfeil neben der Richtlinie, die Sie verwalten möchten. Klicken Sie unten in der Auswahl auf Richtlinie bearbeiten.
  4. Klicken Sie unten im Abschnitt Richtlinie erstellen/bearbeiten auf Erweiterte Richtlinieneinstellungen. Daraufhin werden die erweiterten Richtlinieneinstellungen geöffnet, die in der folgenden Tabelle beschrieben sind.

  5. 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, so als ob der Strom in diesem Moment ausgefallen wäre. Die E/A von Anwendungsdaten wird nicht pausiert. Alle Daten auf dem Laufwerk werden gespeichert und Daten im Arbeitsspeicher gehen verloren. Die Wiederherstellung einer absturzkonsistenten Sicherung kann länger dauern und zu Ausnahmen führen. Je nach Gastbetriebssystem, Dateisystemen und Anwendungen müssen während der Wiederherstellung möglicherweise zusätzliche manuelle Wiederherstellungsschritte ausgeführt werden. Wählen Sie „Absturzkonsistent“ aus, wenn der anwendungskonsistente Prozess aufgrund des Stilllegungsprozesses Probleme für Ihre Anwendungen oder Arbeitslasten verursacht. Absturzkonsistent kann zu einer längeren RTO führen, 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 stillgelegte Snapshots verwendet. Dabei werden VMware-Tools oder eine Google Cloud -Gastumgebung verwendet, um das Dateisystem der virtuellen Maschine stillzulegen. Bei einem Stilllegungsvorgang werden die integrierten Funktionen des Windows-Betriebssystems genutzt, um Dateisysteme und Anwendungen, die VSS unterstützen, stillzulegen. Außerdem werden alle vom Kunden bereitgestellten Freeze- oder Thaw-Skripts (auf allen Plattformen) genutzt, um eine höhere Anwendungskonsistenz zu erreichen. Das Ergebnis ist ein höheres Vertrauen in die Wiederherstellbarkeit der Sicherung sowie in den meisten Fällen kürzere Wiederherstellungszeiten. Anwendungskonsistente Sicherungen können manchmal zu einer kurzen Pause bei der E/A führen. Obwohl dies selten vorkommt, können einige ausgelastete Anwendungen zum Zeitpunkt der Sicherung E/A-Fehler melden. Gelegentlich schlagen anwendungskonsistente Sicherungen fehl, wenn VMware die VM während des Snapshot-Vorgangs nicht innerhalb eines vordefinierten Zeitlimits stilllegen kann. Verwenden Sie anwendungskonsistente Sicherungen, wenn die Wiederherstellbarkeit am wichtigsten ist und die Anwendungen in der VM nicht empfindlich auf die kurze E/A-Pause reagieren.
    Weitere Informationen finden Sie im Abschnitt Anwendungskonsistenten Snapshot eines nichtflüchtigen Speichers für Linux erstellen.

    Wenn Sie einen Windows Compute Engine-Snapshot als neue oder vorhandene VM bereitstellen 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.
  • Absturzkonsistente Sicherung beim letzten Versuch erstellen: Bei dieser Option werden zuerst anwendungskonsistente Sicherungen erstellt. Wenn eine anwendungskonsistente Sicherung jedoch 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 „Multiregional“ 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 Speicherort 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 an wie für die Cloud Storage-Datenübertragung. Weitere Informationen zu Snapshots von nichtflüchtigem Speicher Preisdetails finden Sie unter Laufwerk-Preise.
    Snapshot-Typ      
    (gilt nur für Compute Engine- und SAP HANA-Instanzen)    		Wählen Sie den Persistent Disk-Snapshot-Typ aus, der für Compute Engine-Instanzsicherungen verwendet werden soll. Mit Snapshots lassen sich Daten von nichtflüchtigen Speichern schrittweise sichern. Während der Sicherung wird ein neuer Snapshot erstellt, um den aktuellen Status des nichtflüchtigen Speichers zu erfassen. Dieser kann später verwendet werden, um ein neues Laufwerk für Bereitstellungen oder Wiederherstellungen zu erstellen. Compute Engine speichert mehrere Kopien jedes Snapshots verteilt über mehrere Speicherorte mit automatischen Prüfsummen, um die Integrität der Daten zu gewährleisten. Weitere Informationen zu Snapshots von nichtflüchtigem Speicher Preisdetails finden Sie unter Laufwerk-Preise.
  • Standard: Standardmäßig ist der Snapshot-Typ „Standard“ ausgewählt. Es wird empfohlen, den Standardtyp zu verwenden, wenn Sie die Sicherungen weniger als 90 Tage aufbewahren möchten.
  • Archiv: Wählen Sie den Typ „Archiv“ aus, wenn Sie die Sicherungen über einen längeren Zeitraum aufbewahren möchten. Der Mindestabrechnungszeitraum für den Archiv-Snapshot beträgt 90 Tage, unabhängig von der in der Richtlinie definierten Aufbewahrungsdauer. Außerdem fällt für den Archivtyp eine zusätzliche Abrufgebühr an, wenn er in einem Bereitstellungs- oder Wiederherstellungsjob verwendet wird.
    •       
    Überbelegung des Staging-Laufwerks
    (in Prozent)    		 Geben Sie den zusätzlichen Speicherplatz an, der für das Staging-Laufwerk zugewiesen werden soll (zusätzlich zu dem, was tatsächlich benötigt wird), um das Wachstum der Anwendung zu berücksichtigen. Diese Einstellung kann zwischen 0 und 1.000 % liegen.
    Globale Prune-Pfade Diese Verzeichnisse nicht sichern (vollständigen Pfad angeben). Sehen Sie sich auch die Werte für „Globale Bereinigungspfade“ auf Richtlinienebene an.
    Streamsnap-Replikation komprimieren Standardmäßig ist die Komprimierung für die Streamsnap-Replikation aktiviert. Die Komprimierung erhöht die Effizienz der Streamsnap-Replikation auf die Remote-Sicherungs-/Wiederherstellungs-Appliance, wenn Daten über das Netzwerk übertragen werden, z. B. beim Replizieren von Sicherungen und Videos. Wenn die Komprimierung aktiviert ist, werden alle Pakete komprimiert. Die Ziel-Sicherungs-/Wiederherstellungs-Appliance dekomprimiert die Pakete, bevor sie auf das Staging-Laufwerk geschrieben werden. Wenn für die Streamsnap-Replikation auf die zweite Sicherungs-/Wiederherstellungs-Appliance 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 Sicherungs-/Wiederherstellungs-Appliances unterstützt, die in einem einzelnen Netzwerk bereitgestellt werden.
    Zuordnung nicht aufheben Gibt an, ob temporäre Staging-Laufwerke, die dem Host zugeordnet sind und während der Datenverschiebung 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 wieder. Wählen Sie eine der folgenden Optionen aus:
  • Staging-Laufwerke zwischen Jobs zugeordnet lassen. Wählen Sie diese Option aus, wenn die temporären Staging-Laufwerke, die dem Host zugeordnet sind und während der Datenverschiebung verwendet werden, dem Host zugeordnet bleiben sollen. LUNs werden während des ersten Jobs zugeordnet und alle nachfolgenden Jobs verwenden dieselbe zugeordnete LUN wieder. Diese Option ist standardmäßig ausgewählt.
    Hinweis: Bei Anwendungen, die mit dem Backup und DR-Agenten verwaltet werden (z. B. SQL-Datenbank), wobei 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.
    •
  • Staging-Laufwerke nach jedem Job trennen. Mit dieser Option wird das Staging-Laufwerk am Ende jedes Jobs vom Betriebssystem getrennt (Bereitstellungspunkte oder Laufwerksbuchstaben werden entfernt) und die Zuordnung zum Host wird vollständig aufgehoben. Bei dieser Option muss der Host zu Beginn des nächsten Jobs einen Scan nach SCSI-LUNs durchführen, da die neu zugeordneten Staging-Laufwerke neu erkannt werden müssen, bevor sie wieder bereitgestellt werden können.
    •
    Truncate (Purge) Log After Backup Geben Sie an, ob die Datenbanklogs 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 Logs kürzen, müssen Sie auch das Transaktionslog sichern, um eine Rollforward-Wiederherstellung zu ermöglichen.
    Folgende Optionen sind verfügbar:
  • Protokoll nach Sicherung nicht kürzen oder löschen
    •
  • Protokoll nach 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 die Datenkonsistenz über die Mitgliedsanwendungen hinweg zu wahren. Konsistenzgruppen sind Sammlungen erkannter Anwendungen vom selben Host.
    Folgende Optionen sind verfügbar:
  • Sicherung fehlschlagen lassen, wenn Offline-Anwendungen gefunden werden
    •
  • Offline-Anwendungen bei der Sicherung überspringen
    •
    Staging-Laufwerke allen Knoten in einem Anwendungscluster zuordnen Wenn sich Ihre Knoten in einem Anwendungscluster befinden, können Sie damit dafür sorgen, 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
    Bei einem Ausfall des Anwendungsclusters schützt diese Option Failover-Kopien.
    •
    Staging-Laufwerk allen ESX-Hosts in einem Cluster zuordnen
    (nur für VMware-VMs)     		Wenn sich Ihre ESX-Server in einer Appliance 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-Laufwerk allen ESX-Hosts im Cluster zuordnen
    •
  • Staging-Laufwerk 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 bereitgestellt wird (anwendungsspezifische Bereitstellung), hat die virtuelle Datenbank alle Anmeldedaten, die von der Quelle verwendet werden. Die Optionen sind Ja oder Nein.
    Datenbank-Log-Sicherung aktivieren Mit der Option Datenbank-Logsicherung aktivieren kann die Sicherungsplanrichtlinie eine Datenbank und alle zugehörigen Transaktionslogdateien sichern. Die Logs werden gesichert, wenn der Log-Snapshot-Job ausgeführt wird. Die Optionen sind „Ja“ oder „Nein“. Wenn Sie Ja auswählen, werden die zugehörigen Optionen aktiviert.
    Hinweis: Weitere Informationen zum Logschutz finden Sie unter Datenbank-Logschutz in einer Sicherungsplanrichtlinie.
    RPO Wenn Datenbank-Log-Sicherung aktivieren auf Ja festgelegt 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, ist 15 Minuten.
    Aufbewahrungsdauer für Protokollsicherungen
    (in Tagen)    		 Wenn Datenbank-Log-Sicherung aktivieren auf Ja gesetzt ist, wird die Logaufbewahrung separat von der Aufbewahrung der Snapshot-Richtlinie definiert. Mit einer separaten Aufbewahrungsdauer können Sie Logs in Verbindung mit Kopien der Datenbank verwenden, die im Snapshot-Pool gespeichert sind. Die Aufbewahrungsdauer für Logs ist eine obligatorische Einstellung.
    Logs replizieren
    (verwendet Streamsnap-Technologie)    		 Wenn Datenbank-Log-Sicherung aktivieren auf Aktivieren gesetzt ist, können mit der erweiterten Einstellung Logs replizieren Datenbank-Logs auf eine Remote-Appliance repliziert werden. Damit ein Logreplikationsjob ausgeführt werden kann, muss die Streamsnap-Replikationsrichtlinie in der Vorlage enthalten sein, zusammen mit einem Ressourcenprofil, das eine Remote-Appliance angibt. Außerdem muss zuerst mindestens eine erfolgreiche Replikation der Datenbank abgeschlossen werden. Sie können die Logs am Remote-Standort dann für jede Datenbanksicherung 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 Logs in einen oder mehrere OnVault-Speicherpools repliziert, sodass Wiederherstellungen zu einem bestimmten Zeitpunkt von OnVault an einem anderen Standort möglich sind.
    Hinweis: Wenn Sie diese Option auswählen, sendet Backup und 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 für jede Protokollsicherung OnVault-Jobs (Protokoll) angezeigt, einer für jeden Pool. Nur OnVault-Pools, die im Profil für dieses SLA enthalten sind, erhalten die Logs.
    • 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, werden die Logs von Backup und DR kontinuierlich in OnVault-Buckets repliziert, ähnlich wie bei Log-Snapshot-Sicherungen. Wenn beispielsweise alle 15 Minuten eine Log-Sicherung 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: Tägliche, wöchentliche, monatliche und jährliche OnVault-Richtlinien gelten nur für Datenbanksicherungen, nicht für Protokollsicherungen.
    Größe des Log-Staging-Laufwerks (in Prozent) Wenn Datenbank-Logsicherung aktivieren auf Ja festgelegt ist, definiert Größe des Log-Staging-Laufwerks das Wachstum, das beim automatischen Vergrößern des Staging-Laufwerks, auf dem sich die Logs befinden, verwendet werden soll. Diese Einstellung kann zwischen 5 % und 100 % liegen.
    Geschätzte Änderungsrate Wenn Datenbank-Log-Sicherung aktivieren auf Ja gesetzt ist, definiert diese Einstellung die tägliche Änderung (in Prozent). Dadurch kann die Appliance die Größe des Staging-Laufwerks, das zum Speichern von Logs erforderlich ist, besser berechnen. Diese Einstellung kann zwischen 0 und 100 liegen.
    Datenbankprotokollsicherung komprimieren Wenn Datenbankprotokollsicherung aktivieren auf Ja gesetzt ist, weist diese Einstellung die Quelldatenbank an, ihre Protokolle zu komprimieren, bevor sie von der Appliance-Verwaltungskonsole erfasst werden. Der Datenbankserver führt während der Logsicherung eine Logkomprimierung durch. Die Optionen sind Ja oder Nein. Wenn Sie Ja auswählen, wird die Option Datenbank-Log-Sicherung komprimieren aktiviert.
    Erzwungene Aufbewahrung Ermöglicht dem Nutzer, die Unveränderlichkeitsdauer zwischen null und 36.525 Tagen zu 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 eine längere erzwungene Aufbewahrungsdauer 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-Image behalten“ ist.
    Hinweis: Die erzwungene Aufbewahrung kann nicht für einzelne Anwendungen überschrieben werden. Die Option wird nicht auf der Seite Richtlinienüberschreibungen angezeigt.
    Hinweis: Die erweiterte Richtlinieneinstellung Erzwungene Aufbewahrung ist nicht mit dem Anwendungsschutz kompatibel, der auf ein Backup Vault verweist. Wenn ein Backup Vault das Speicherziel ist, bestimmt der Backup Vault die erzwungene Aufbewahrungsdauer.
    Jobverhalten, wenn die Ziel-VM eine Snapshot-Konsolidierung erfordert Wählen Sie eine Aktion aus, wenn die VM konsolidiert werden muss:
  • Job fehlschlagen lassen, wenn die VM konsolidiert werden muss: Jobs zu einem bestimmten Zeitpunkt schlagen fehl.
    •
  • Job ohne Konsolidierung ausführen: Alle Jobs werden normal ausgeführt, auch wenn eine Konsolidierung aussteht.
    •
  • Konsolidierung zu Beginn des Jobs ausführen: Bei zeitpunktbezogenen Jobs wird versucht, die Konsolidierung zu Beginn des Jobs auszuführen. Wenn die Zusammenführung fehlschlägt, schlägt der Job mit einer Fehlermeldung fehl.
    •
    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: Angegebener Startpfad ist nicht vorhanden“ 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 und DR-Agents. Der Job schlägt nicht fehl, wenn ein Startpfad nicht vorhanden ist.
    Modus für eingeschränkte Erfassung aktivieren Im eingeschränkten Erfassungsmodus werden inkrementelle Daten erfasst, wenn der Dienst Change Block Tracking (CBT) nicht verfügbar ist. Die Datenerfassung kann länger dauern. Die Optionen sind Ja oder Nein.
    Zeitlimit für Script
    (gilt nur für agentenbasierte Sicherungen)    		 Mit dem Backup und DR-Agenten können Sie hostseitige Skripts erstellen, die vor oder nach der Ausführung einer Richtlinie auf dem Host einer Anwendung ausgeführt werden. Die vier Zeitlimits, die in einer Richtlinienvorlage angegeben sind, werden direkt den vier Phasen eines hostseitigen Scripts zugeordnet.
    Hinweis: Standardmäßig entsprechen die Zeitüberschreitungswerte für Skripts den folgenden Werten. Wenn kein Script-Zeitlimit angegeben ist, ist der Wert leer und es wird der Standardwert verwendet.
  • Zeitlimit für die Skriptinitialisierung: Definiert, wie lange ein Job auf das Skript warten soll, das auf dem Host aufgerufen wird, bevor der Job eine Aktion ausführt. Wenn das Script 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 des Skripts: Definiert, wie lange eine Richtlinie auf das Skript 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.
  • Zeitlimit für das Aufheben des Einfrierens des Skripts: Definiert, wie lange eine Richtlinie auf das Skript warten soll, das aufgerufen wird, um eine Anwendung nach dem Erstellen eines Snapshots einzufrieren. Wenn das Script 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 Skriptabschluss: Definiert, wie lange eine Richtlinie auf das Skript 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