Opis okresowej konfiguracji kopii zapasowej w usłudze Azure Service Fabric
Konfigurowanie okresowej kopii zapasowej usług reliable stateful services lub Reliable Actors składa się z następujących kroków:
Tworzenie zasad tworzenia kopii zapasowych: w tym kroku są tworzone co najmniej jedno zasady tworzenia kopii zapasowych w zależności od wymagań.
Włączanie tworzenia kopii zapasowej: w tym kroku skojarzysz zasady tworzenia kopii zapasowych utworzone w kroku 1 z wymaganymi jednostkami, aplikacją, usługą lub partycją.
Tworzenie zasad kopii zapasowych
Zasady tworzenia kopii zapasowych składają się z następujących konfiguracji:
- Automatyczne przywracanie po utracie danych: określa, czy wyzwalać przywracanie automatycznie przy użyciu najnowszej dostępnej kopii zapasowej, jeśli partycja doświadcza zdarzenia utraty danych.
Uwaga
Zaleca się, aby nie ustawiać automatycznego przywracania w klastrach produkcyjnych
Maksymalna liczba przyrostowych kopii zapasowych: definiuje maksymalną liczbę przyrostowych kopii zapasowych do wykonania między dwoma pełnymi kopiami zapasowymi. Maksymalna liczba przyrostowych kopii zapasowych określa górny limit. Pełną kopię zapasową można wykonać, zanim określona liczba przyrostowych kopii zapasowych zostanie ukończona w jednym z następujących warunków
Replika nigdy nie utworzyła pełnej kopii zapasowej, ponieważ stała się podstawowa.
Niektóre rekordy dziennika od czasu ostatniego utworzenia kopii zapasowej zostały obcięte.
Replika przekroczyła limit MaxAccumulatedBackupLogSizeInMB.
Harmonogram tworzenia kopii zapasowych: czas lub częstotliwość wykonywania okresowych kopii zapasowych. Można zaplanować tworzenie kopii zapasowych cyklicznie w określonym interwale lub o stałej godzinie codziennie/co tydzień.
Harmonogram tworzenia kopii zapasowych oparty na częstotliwości: ten typ harmonogramu powinien być używany, jeśli konieczne jest wykonanie kopii zapasowej danych w ustalonych odstępach czasu. Żądany interwał czasu między dwoma kolejnymi kopiami zapasowymi jest definiowany przy użyciu formatu ISO8601. Harmonogram tworzenia kopii zapasowych oparty na częstotliwości obsługuje rozdzielczość interwału do minuty.
{ "ScheduleKind": "FrequencyBased", "Interval": "PT10M" }
Harmonogram tworzenia kopii zapasowych oparty na czasie: ten typ harmonogramu powinien być używany, jeśli konieczne jest wykonanie kopii zapasowej danych o określonych porach dnia lub tygodnia. Typ częstotliwości harmonogramu może być dzienny lub tygodniowy.
Dzienny harmonogram tworzenia kopii zapasowych oparty na czasie: ten typ harmonogramu powinien być używany, jeśli konieczne jest wykonanie kopii zapasowej danych o określonych porach dnia. Aby to określić, ustaw wartość
ScheduleFrequencyType
na Codziennie; i ustawRunTimes
na listę żądanych godzin w ciągu dnia w formacie ISO8601, przy czym data określona wraz z godziną zostanie zignorowana. Na przykład0001-01-01T18:00:00
reprezentuje godzinę 18:00 każdego dnia, ignorując część daty 0001-01-01. Poniższy przykład ilustruje konfigurację wyzwalania codziennej kopii zapasowej o godzinie 9:00 i 18:00 codziennie.{ "ScheduleKind": "TimeBased", "ScheduleFrequencyType": "Daily", "RunTimes": [ "0001-01-01T09:00:00Z", "0001-01-01T18:00:00Z" ] }
Tygodniowy harmonogram tworzenia kopii zapasowych oparty na czasie: ten typ harmonogramu powinien być używany, jeśli konieczne jest wykonanie kopii zapasowej danych o określonych porach dnia. Aby to określić, ustaw wartość
ScheduleFrequencyType
na Co tydzień; ustaw wartośćRunDays
na listę dni w tygodniu, gdy należy wyzwolić kopię zapasową i ustaw wartośćRunTimes
na listę żądanych czasów dnia w formacie ISO8601, data określona wraz z godziną zostanie zignorowana. Lista dni tygodnia, kiedy wyzwalać okresową kopię zapasową. Poniższy przykład ilustruje konfigurację wyzwalania codziennej kopii zapasowej o godzinie 9:00 i 18:00 w poniedziałek do piątku.{ "ScheduleKind": "TimeBased", "ScheduleFrequencyType": "Weekly", "RunDays": [ "Monday", "Tuesday", "Wednesday", "Thursday", "Friday" ], "RunTimes": [ "0001-01-01T09:00:00Z", "0001-01-01T18:00:00Z" ] }
Magazyn kopii zapasowych: określa lokalizację przesyłania kopii zapasowych. Magazyn może być składowiskiem obiektów blob Azure lub udostępnianiem plików.
Magazyn obiektów blob platformy Azure z tożsamością zarządzaną: ten typ magazynu należy wybrać, gdy konieczne jest przechowywanie wygenerowanych kopii zapasowych na platformie Azure. Zarówno autonomiczne , jak i oparte na chmurze klastry mogą używać tego typu magazynu. Opis dla tego typu magazynu wymaga BlobServiceUri oraz nazwy kontenera, do którego kopie zapasowe muszą zostać przesłane. Jeśli kontener o określonej nazwie nie jest dostępny, zostanie utworzony podczas przekazywania kopii zapasowej. Zastąp
account-name
nazwą konta magazynowego.{ "StorageKind": "ManagedIdentityAzureBlobStore", "FriendlyName": "AzureMI_storagesample", "BlobServiceUri": "https://<account-name>.blob.core.windows.net", "ContainerName": "backup-container", "ManagedIdentityType": "VMSS", "ManagedIdentityClientId": "<Client-Id of User-Assigned MI>" }
[UWAGA] Użyj opcjonalnego parametru
ManagedIdentityClientId
z identyfikatorem klienta tożsamości zarządzanej przypisanej przez użytkownika, jeśli do Twojego zasobu przypisano wiele takich tożsamości lub zarówno SAMI, jak i UAMI zostały przypisane, a potrzebujemy użyć UAMI jako domyślnej. W przeciwnym razie nie ma potrzeby używania tego parametru.Wykonaj kroki przypisywania tożsamości zarządzanej w zasobie platformy Azure:
Włącz tożsamość zarządzaną przypisaną przez system lub użytkownika w zestawie skalowania maszyn wirtualnych. Konfiguruj tożsamości zarządzane w zestawie skalowania maszyn wirtualnych
Przypisz rolę tożsamości zarządzanej VMSS do konta magazynu, używając funkcji przypisywania ról w portalu Azure - Kontrola dostępu oparta na rolach platformy Azure (Azure RBAC)
- Rola współautora danych obiektu blob usługi Storage co najmniej
Aby uzyskać więcej informacji na temat tożsamości zarządzanej
Magazyn obiektów blob platformy Azure z funkcją ConnectionString: ten typ magazynu należy wybrać, gdy konieczne jest przechowywanie wygenerowanych kopii zapasowych na platformie Azure. Zarówno autonomiczne , jak i oparte na chmurze klastry mogą używać tego typu magazynu. Opis tego typu magazynu wymaga ciągu połączenia i nazwy kontenera, do którego należy wysłać kopie zapasowe. Jeśli kontener o określonej nazwie jest niedostępny, zostanie utworzony podczas przekazywania kopii zapasowej.
{ "StorageKind": "AzureBlobStore", "FriendlyName": "Azure_storagesample", "ConnectionString": "<Put your Azure blob store connection string here>", "ContainerName": "backup-container" }
Uwaga
Usługa przywracania kopii zapasowych nie działa z połączeniem usługi Azure Storage w wersji 1 nie jest zalecana w środowisku produkcyjnym, ponieważ bezpośredni dostęp do zasobu bez uwierzytelniania użytkownika
Udział plików: ten typ magazynu należy wybrać dla klastrów autonomicznych , gdy konieczne jest przechowywanie kopii zapasowych danych w środowisku lokalnym. Opis tego typu magazynu wymaga ścieżki udziału plików, w której należy przekazać kopie zapasowe. Dostęp do udziału plików można skonfigurować przy użyciu jednej z następujących opcji
Zintegrowane uwierzytelnianie systemu Windows, w którym dostęp do udziału plików jest udostępniany wszystkim komputerom należącym do klastra usługi Service Fabric. W takim przypadku ustaw następujące pola, aby skonfigurować magazyn kopii zapasowych oparty na udziale plików.
{ "StorageKind": "FileShare", "FriendlyName": "Sample_FileShare", "Path": "\\\\StorageServer\\BackupStore" }
Ochrona zasobu udostępniania plików przy użyciu nazwy użytkownika i hasła, gdzie dostęp do zasobu plików jest udostępniany określonym użytkownikom. Specyfikacja magazynu udziału plików zapewnia również możliwość określenia pomocniczej nazwy użytkownika i pomocniczego hasła w celu zapewnienia poświadczeń rezerwowych w przypadku niepowodzenia uwierzytelniania przy użyciu podstawowej nazwy użytkownika i hasła podstawowego. W takim przypadku ustaw następujące pola, aby skonfigurować magazyn kopii zapasowych oparty na udziale plików.
{ "StorageKind": "FileShare", "FriendlyName": "Sample_FileShare", "Path": "\\\\StorageServer\\BackupStore", "PrimaryUserName": "backupaccount", "PrimaryPassword": "<Password for backupaccount>", "SecondaryUserName": "backupaccount2", "SecondaryPassword": "<Password for backupaccount2>" }
Uwaga
Upewnij się, że niezawodność magazynu spełnia lub przekracza wymagania dotyczące niezawodności danych kopii zapasowej.
-
Zasady przechowywania: określa zasady przechowywania kopii zapasowych w skonfigurowanym magazynie. Obsługiwane są tylko podstawowe zasady przechowywania.
Podstawowe zasady przechowywania: te zasady przechowywania umożliwiają zapewnienie optymalnego wykorzystania magazynu przez usunięcie plików kopii zapasowych, które nie są już wymagane.
RetentionDuration
Można określić przedział czasu, dla którego kopie zapasowe muszą być przechowywane w pamięci masowej.MinimumNumberOfBackups
jest opcjonalnym parametrem, który można określić, aby upewnić się, że określona liczba kopii zapasowych jest zawsze zachowywana niezależnie odRetentionDuration
. Poniższy przykład ilustruje konfigurację przechowywania kopii zapasowych przez 10 dni i nie zezwala na użycie liczby kopii zapasowych poniżej 20.{ "RetentionPolicyType": "Basic", "RetentionDuration": "P10D", "MinimumNumberOfBackups": 20 }
Włączanie okresowej kopii zapasowej
Po zdefiniowaniu zasad tworzenia kopii zapasowych w celu spełnienia wymagań dotyczących kopii zapasowej danych zasady tworzenia kopii zapasowych powinny być odpowiednio skojarzone z aplikacją lub usługą albo partycją.
Uwaga
Przed włączeniem kopii zapasowej upewnij się, że nie ma żadnych uaktualnień aplikacji
Hierarchiczne propagowanie zasad kopii zapasowych
W usłudze Service Fabric relacja między aplikacją, usługą i partycjami jest hierarchiczna, jak wyjaśniono w artykule Model aplikacji. Zasady tworzenia kopii zapasowych mogą być skojarzone z aplikacją, usługą lub partycjąw hierarchii. Zasady tworzenia kopii zapasowych propagują hierarchicznie do następnego poziomu. Zakładając, że istnieje tylko jedna zasada tworzenia kopii zapasowych i jest ona skojarzona z aplikacją , wszystkie partycje stanowe należące do wszystkich niezawodnych usług stanowych i niezawodnych aktorówaplikacji tworzy się kopie zapasowe przy użyciu tej zasady tworzenia kopii zapasowych. Lub jeśli zasady tworzenia kopii zapasowych są skojarzone z usługą Reliable stateful, wszystkie jej partycje są tworzone przy użyciu zasad tworzenia kopii zapasowych.
Nadpisywanie polityki kopii zapasowych
Może istnieć scenariusz, w którym tworzenie kopii zapasowych danych z tym samym harmonogramem tworzenia kopii zapasowych jest wymagane dla wszystkich usług aplikacji, z wyjątkiem określonych usług, w których konieczne jest utworzenie kopii zapasowej danych przy użyciu harmonogramu wyższej częstotliwości lub utworzenie kopii zapasowej na innym koncie magazynu lub udziałie plików. Aby rozwiązać takie scenariusze, usługa przywracania kopii zapasowych udostępnia funkcję zastąpienia propagowanych zasad w zakresie usług i partycji. Gdy zasady tworzenia kopii zapasowych są skojarzone z usługą lub partycją, zastępuje propagowane zasady kopii zapasowej, jeśli istnieją.
Przykład
W tym przykładzie użyto konfiguracji z dwiema aplikacjami, MyApp_A i MyApp_B. Aplikacja MyApp_A zawiera dwie niezawodne usługi stanowe, SvcA1 i SvcA3, oraz jedną niezawodną usługę aktorską, ActorA2. SvcA1 zawiera trzy partycje, podczas gdy aktorA2 i SvcA3 zawierają dwie partycje. Aplikacja MyApp_B zawiera trzy niezawodne usługi stanowe, SvcB1, SvcB2 i SvcB3. _SvcB1 i SvcB2 zawierają dwie partycje, a SvcB3 zawiera trzy partycje.
Załóżmy, że wymagania dotyczące tworzenia kopii zapasowych danych tych aplikacji są następujące
MyApp_A
Utwórz codzienną kopię zapasową danych dla wszystkich partycji wszystkich usług Reliable Stateful i Reliable Actors należących do aplikacji. Przekazywanie danych kopii zapasowej do lokalizacji BackupStore1.
Jedna z usług, SvcA3, wymaga tworzenia kopii zapasowej danych co godzinę.
Rozmiar danych w SvcA1_P2 partycji jest większy niż oczekiwano , a dane kopii zapasowej powinny być przechowywane w innej lokalizacji magazynu BackupStore2.
MyApp_B
Utwórz kopię zapasową danych w każdą niedzielę o godzinie 8:00 dla wszystkich partycji usługi SvcB1 . Przekazywanie danych kopii zapasowej do lokalizacji BackupStore1.
Utwórz kopię zapasową danych codziennie o godzinie 8:00 dla SvcB2_P1 partycji. Przekazywanie danych kopii zapasowej do lokalizacji BackupStore1.
Aby spełnić te wymagania dotyczące tworzenia kopii zapasowych danych, zasady tworzenia kopii zapasowych BP_1 do BP_5 są tworzone, a tworzenie kopii zapasowych jest włączone w następujący sposób.
MyApp_A
Utwórz zasady tworzenia kopii zapasowych, BP_1 z harmonogramem tworzenia kopii zapasowych opartym na częstotliwości, gdzie częstotliwość jest ustawiona na 24 godziny. i magazyn kopii zapasowych skonfigurowany do używania lokalizacji BackupStore1. Włącz tę zasadę dla aplikacji MyApp_A przy użyciu API Włączania Kopii Zapasowej. Ta akcja umożliwia tworzenie kopii zapasowych danych przy użyciu zasad tworzenia kopii zapasowych BP_1 dla wszystkich partycji usług Reliable Stateful Services i Reliable Actors należących do MyApp_A aplikacji.
Utwórz zasady tworzenia kopii zapasowych, BP_2 z harmonogramem tworzenia kopii zapasowych opartym na częstotliwości, gdzie częstotliwość jest ustawiona na 1 godz. i magazyn kopii zapasowych skonfigurowany do używania lokalizacji BackupStore1. Włącz tę politykę dla usługi SvcA3 przy użyciu interfejsu API Enable Service Backup. Ta akcja zastępuje propagowane zasady BP_1 przez jawnie włączone zasady tworzenia kopii zapasowych BP_2 dla wszystkich partycji usługi SvcA3 prowadzących do tworzenia kopii zapasowych danych przy użyciu zasad tworzenia kopii zapasowych BP_2 dla tych partycji.
Utwórz zasady tworzenia kopii zapasowych, BP_3 z harmonogramem tworzenia kopii zapasowych opartym na częstotliwości, gdzie częstotliwość jest ustawiona na 24 godziny. i magazyn kopii zapasowych skonfigurowany do używania lokalizacji BackupStore2. Włącz tę politykę dla partycji SvcA1_P2 przy użyciu interfejsu API do włączania kopii zapasowej partycji. Ta akcja zastępuje propagowaną politykę BP_1 poprzez jawnie włączoną politykę tworzenia kopii zapasowych BP_3 dla partycji SvcA1_P2.
MyApp_B
Utwórz politykę tworzenia kopii zapasowych, BP_4, z harmonogramem tworzenia kopii zapasowych opartym na czasie, w którym typ częstotliwości harmonogramu jest ustawiony na tygodniowy, dni uruchamiania to niedziela, a czas uruchamiania to 8:00. Magazyn kopii zapasowych skonfigurowany do użycia lokalizacji BackupStore1. Włącz tę zasadę dla usługi SvcB1 przy użyciu interfejsu API Włączania Kopii Zapasowej. Ta akcja umożliwia tworzenie kopii zapasowej danych przy użyciu zasad tworzenia kopii zapasowych BP_4 dla wszystkich partycji usługi SvcB1.
Utwórz politykę tworzenia kopii zapasowych, BP_5, z harmonogramem opartym na czasie, w którym częstotliwość harmonogramu jest ustawiona na codzienną, a godzina uruchamiania jest ustawiona na 8:00. Magazyn kopii zapasowych skonfigurowany do używania lokalizacji BackupStore1. Włącz tę zasadę dla partycji SvcB2_P1 przy użyciu API Enable Partition Backup. Ta akcja umożliwia tworzenie kopii zapasowej danych przy użyciu polityki kopii zapasowej BP_5 dla partycji SvcB2_P1.
Na poniższym diagramie przedstawiono jawnie włączone zasady tworzenia kopii zapasowych i propagowane zasady tworzenia kopii zapasowych.
Wyłączanie kopii zapasowej
Zasady tworzenia kopii zapasowych można wyłączyć, gdy nie ma potrzeby tworzenia kopii zapasowych danych. Zasady tworzenia kopii zapasowych włączone w aplikacji można wyłączyć tylko w tej samej aplikacji przy użyciu interfejsu API Disable Application Backup. Zasady tworzenia kopii zapasowych włączone w usłudze można wyłączyć w tej samej usłudze przy użyciu interfejsu API Disable Service Backup, a zasady tworzenia kopii zapasowych włączone na partycji można wyłączyć w tej samej partycji przy użyciu interfejsu API Disable Partition Backup.
Wyłączenie zasad tworzenia kopii zapasowych dla aplikacji powoduje zatrzymanie wszystkich okresowych kopii zapasowych danych w wyniku propagacji zasad kopii zapasowej do partycji usługi Reliable Stateful lub partycji Reliable Actor.
Wyłączenie zasad tworzenia kopii zapasowych dla usługi powoduje zatrzymanie wszystkich okresowych kopii zapasowych danych w wyniku propagacji tych zasad kopii zapasowych do partycji usługi.
Wyłączenie zasad tworzenia kopii zapasowych dla partycji powoduje zatrzymanie wszystkich okresowych kopii zapasowych danych wykonywanych na podstawie tych zasad.
Podczas wyłączania kopii zapasowej dla jednostki (aplikacji/usługi/partycji),
CleanBackup
można ustawić na wartość true, aby usunąć wszystkie kopie zapasowe w skonfigurowanym magazynie.{ "CleanBackup": true }
Uwaga
Przed wyłączeniem kopii zapasowej upewnij się, że nie ma żadnych uaktualnień aplikacji
Wstrzymywanie i wznawianie tworzenia kopii zapasowe
Niektóre sytuacje mogą wymagać tymczasowego zawieszenia okresowej kopii zapasowej danych. W takich przypadkach, w zależności od wymagań, interfejs API wstrzymywania kopii zapasowej może być używany w aplikacji, usłudze lub partycji. Okresowe zawieszenie kopii zapasowej jest przechodnie przez poddrzewo hierarchii aplikacji od momentu jej zastosowania.
Po zastosowaniu zawieszenia w aplikacji przy użyciu interfejsu API wstrzymania tworzenia kopii zapasowej aplikacji wszystkie usługi i partycje w ramach tej aplikacji są zawieszone na potrzeby okresowej kopii zapasowej danych.
Po zastosowaniu zawieszenia w usłudze przy użyciu interfejsu API wstrzymania kopii zapasowej usługi wszystkie partycje w ramach tej usługi są zawieszone na potrzeby okresowej kopii zapasowej danych.
Gdy zawieszenie jest stosowane na partycji przy użyciu interfejsu Suspend Partition Backup API, wówczas partycje w ramach tej usługi są zawieszane na potrzeby okresowych kopii zapasowych danych.
Po zakończeniu konieczności zawieszenia można przywrócić okresową kopię zapasową danych, używając odpowiedniego interfejsu API wznawiania kopii zapasowej. Okresowa kopia zapasowa musi zostać wznowiona w tej samej aplikacji, usłudze lub partycji , w której została zawieszona.
Jeśli zawieszenie zostało zastosowane w aplikacji, należy wznowić korzystanie z interfejsu API wznawiania tworzenia kopii zapasowej aplikacji.
Jeśli zawieszenie zostało zastosowane w Usłudze, należy je wznowić używając API wznawiania kopii zapasowej usługi.
Jeśli zawieszenie zostało zastosowane w partycji, należy je wznowić przy użyciu API wznawiania kopii zapasowej partycji.
Różnica między wstrzymaniem i wyłączeniem kopii zapasowych
Należy użyć opcji wyłączenia kopii zapasowej, gdy kopie zapasowe nie są już wymagane dla określonej aplikacji, usługi lub partycji. Można wywołać wyłączenie żądania utworzenia kopii zapasowej wraz z parametrem czystych kopii zapasowych, co oznaczałoby, że wszystkie istniejące kopie zapasowe są usuwane. Jednak wstrzymanie ma być używane w scenariuszach, w których chcesz tymczasowo wyłączyć kopie zapasowe, takie jak gdy dysk lokalny staje się pełny lub przekazywanie kopii zapasowej kończy się niepowodzeniem z powodu znanego problemu z siecią itp.
Mimo że funkcję wyłączenia można zastosować tylko na poziomie, który został wcześniej jawnie włączony do tworzenia kopii zapasowej, zawieszenie można stosować na dowolnym poziomie, który jest obecnie włączony do tworzenia kopii zapasowej, bezpośrednio lub poprzez dziedziczenie lub hierarchię. Na przykład, jeśli kopia zapasowa jest włączona na poziomie aplikacji, można deaktywować ją tylko na poziomie aplikacji. Jednak zawieszenie można zastosować na poziomie aplikacji, jakiejkolwiek usługi lub partycji w ramach tej aplikacji.
Automatyczne przywracanie po utracie danych
Partycja usługi może utracić dane z powodu nieoczekiwanych awarii. Na przykład dysk dla dwóch z trzech replik partycji (w tym repliki podstawowej) został uszkodzony lub wymazany.
Gdy usługa Service Fabric wykryje, że partycja znajduje się w utracie OnDataLossAsync
danych, wywołuje metodę interfejsu na partycji i oczekuje, że partycja podejmie wymaganą akcję, aby wyjść z utraty danych. W tej sytuacji, jeśli skuteczna polityka kopii zapasowych na partycji ma flagę AutoRestoreOnDataLoss
ustawioną na true
, przywracanie zostanie uruchomione automatycznie z użyciem najnowszej dostępnej kopii zapasowej tej partycji.
Uwaga
Zaleca się, aby nie ustawiać automatycznego przywracania w klastrach produkcyjnych
Pobieranie konfiguracji kopii zapasowej
Oddzielne interfejsy API są udostępniane w celu uzyskania informacji o konfiguracji kopii zapasowej w zakresie aplikacji, usługi i partycji . Uzyskaj informacje o konfiguracji kopii zapasowej aplikacji, uzyskaj informacje o konfiguracji kopii zapasowej usługi, i uzyskaj informacje o konfiguracji kopii zapasowej partycji to odpowiednio te interfejsy API. Głównie te interfejsy API zwracają odpowiednie zasady tworzenia kopii zapasowych, zakres, w którym są stosowane zasady tworzenia kopii zapasowych i szczegóły zawieszenia kopii zapasowych. Poniżej przedstawiono krótki opis zwracanych wyników tych interfejsów API.
Informacje o konfiguracji kopii zapasowej aplikacji: zawierają szczegółowe informacje o zasadach tworzenia kopii zapasowych stosowanych w aplikacji oraz wszystkich zastąpionych zasadach w usługach i partycjach należących do aplikacji. Zawiera również informacje o zawieszeniu aplikacji i jej usług oraz partycji.
Informacje o konfiguracji kopii zapasowej usługi: zawiera szczegółowe informacje dotyczące skutecznych zasad tworzenia kopii zapasowych w usłudze, zakresu, na który te zasady zostały zastosowane, oraz wszystkich zastąpionych zasad w jego partycjach. Zawiera również informacje o wstrzymaniu usługi i jej podziałach.
Informacje o konfiguracji kopii zapasowej partycji: zawiera szczegółowe informacje o obowiązujących zasadach tworzenia kopii zapasowych na partycji i zakresie, w którym zastosowano te zasady. Zawiera również informacje o zawieszeniu partycji.
Wyświetlanie listy dostępnych kopii zapasowych
Dostępne kopie zapasowe można wyświetlić przy użyciu interfejsu API pobierania listy kopii zapasowych. Wynik wywołania interfejsu API obejmuje elementy informacji o kopii zapasowej powiązane ze wszystkimi kopiami zapasowymi dostępnymi w magazynie kopii zapasowych, które są skonfigurowane w odpowiednich zasadach kopii zapasowych. Różne warianty tego interfejsu API są udostępniane do wyświetlania listy dostępnych kopii zapasowych należących do aplikacji, usługi lub partycji. Te interfejsy API obsługują pobieranie najnowszej dostępnej kopii zapasowej wszystkich odpowiednich partycji lub filtrowanie kopii zapasowych na podstawie daty rozpoczęcia i daty zakończenia.
Te interfejsy API obsługują również stronicowanie wyników, gdy parametr MaxResults jest ustawiony na niezerowo dodatnią liczbę całkowitą, a następnie interfejs API zwraca maksymalne elementy informacji kopii zapasowej MaxResults . W przypadku, gdy jest dostępnych więcej elementów informacji kopii zapasowej niż wartość MaxResults , zwracany jest token kontynuacji. Prawidłowy parametr tokenu kontynuacji może służyć do uzyskania następnego zestawu wyników. Gdy prawidłowa wartość tokenu kontynuacji jest przekazywana do następnego wywołania interfejsu API, interfejs API zwraca następny zestaw wyników. W odpowiedzi nie jest uwzględniany żaden token kontynuacji, gdy zostaną zwrócone wszystkie dostępne wyniki.
Poniżej przedstawiono krótkie informacje o obsługiwanych wariantach.
Pobieranie listy kopii zapasowych aplikacji: zwraca listę kopii zapasowych dostępnych dla każdej partycji należącej do danej aplikacji usługi Service Fabric.
Uzyskaj listę kopii zapasowych usługi: zwraca listę kopii zapasowych dostępnych dla każdej partycji należącej do danej usługi Service Fabric.
Pobieranie listy kopii zapasowych partycji: zwraca listę kopii zapasowych dostępnych dla określonej partycji.