Tworzenie kopii zapasowych i przywracanie usług Reliable Services i Reliable Actors

Azure Service Fabric to platforma wysokiej dostępności, która replikuje stan między wieloma węzłami, aby zachować tę wysoką dostępność. W związku z tym nawet jeśli jeden węzeł w klastrze ulegnie awarii, usługi będą nadal dostępne. Chociaż ta wbudowana nadmiarowość zapewniana przez platformę może być wystarczająca dla niektórych, w niektórych przypadkach pożądane jest, aby usługa tworzyła kopię zapasową danych (do magazynu zewnętrznego).

Uwaga

Tworzenie kopii zapasowych i przywracanie danych (i testowanie ich działania zgodnie z oczekiwaniami) ma kluczowe znaczenie, aby można było odzyskać dane po scenariuszach utraty danych.

Uwaga

Firma Microsoft zaleca używanie okresowych kopii zapasowych i przywracania do konfigurowania kopii zapasowej danych usług Reliable Stateful i Reliable Actors.

Na przykład usługa może chcieć utworzyć kopię zapasową danych w celu ochrony przed następującymi scenariuszami:

• W przypadku trwałej utraty całego klastra usługi Service Fabric.
• Trwała utrata większości replik partycji usługi
• Błędy administracyjne, w których stan zostanie przypadkowo usunięty lub uszkodzony. Na przykład może się to zdarzyć, jeśli administrator z wystarczającym uprawnieniem błędnie usunie usługę.
• Usterki w usłudze, które powodują uszkodzenie danych. Na przykład może się to zdarzyć, gdy uaktualnienie kodu usługi rozpoczyna zapisywanie uszkodzonych danych w kolekcji Reliable Collection. W takim przypadku zarówno kod, jak i dane mogą być przywracane do wcześniejszego stanu.
• Przetwarzanie danych w trybie offline. Może być wygodne posiadanie przetwarzania danych w trybie offline na potrzeby analizy biznesowej, która odbywa się oddzielnie od usługi, która generuje dane.

Funkcja tworzenia/przywracania kopii zapasowych umożliwia usługom opartym na interfejsie API usług Reliable Services tworzenie i przywracanie kopii zapasowych. Interfejsy API kopii zapasowych udostępniane przez platformę umożliwiają tworzenie kopii zapasowych stanu partycji usługi bez blokowania operacji odczytu lub zapisu. Interfejsy API przywracania umożliwiają przywrócenie stanu partycji usługi z wybranej kopii zapasowej.

Typy kopii zapasowych

Dostępne są dwie opcje tworzenia kopii zapasowej: Pełne i Przyrostowe. Pełna kopia zapasowa to kopia zapasowa zawierająca wszystkie dane wymagane do odtworzenia stanu repliki: punkty kontrolne i wszystkie rekordy dziennika. Ponieważ zawiera ona punkty kontrolne i dziennik, pełną kopię zapasową można przywrócić samodzielnie.

Problem z pełnymi kopiami zapasowymi występuje, gdy punkty kontrolne są duże. Na przykład replika, która ma 16 GB stanu, będzie zawierać punkty kontrolne, które sumują się około 16 GB. Jeśli mamy cel punktu odzyskiwania w ciągu pięciu minut, kopia zapasowa repliki musi być wykonywana co pięć minut. Za każdym razem, gdy kopie zapasowe są kopiami zapasowymi, musi skopiować 16 GB punktów kontrolnych oprócz 50 MB (konfigurowalnych przy użyciu polecenia CheckpointThresholdInMB) wartości dzienników.

Rozwiązaniem tego problemu są przyrostowe kopie zapasowe, w których kopia zapasowa zawiera tylko zmienione rekordy dziennika od czasu utworzenia ostatniej kopii zapasowej.

Ponieważ przyrostowe kopie zapasowe są tylko zmianami od ostatniej kopii zapasowej (nie obejmuje punktów kontrolnych), zwykle są szybsze, ale nie można ich przywrócić samodzielnie. Aby przywrócić przyrostową kopię zapasową, wymagany jest cały łańcuch kopii zapasowych. Łańcuch kopii zapasowych to łańcuch kopii zapasowych rozpoczynający się od pełnej kopii zapasowej, po którym następuje szereg ciągłych przyrostowych kopii zapasowych.

Tworzenie kopii zapasowych usług Reliable Services

Autor usługi ma pełną kontrolę nad tym, kiedy tworzyć kopie zapasowe i gdzie będą przechowywane kopie zapasowe.

Aby uruchomić kopię zapasową, usługa musi wywołać funkcję dziedziczonej składowej BackupAsync.
Kopie zapasowe można tworzyć tylko z replik podstawowych i wymagają udzielenia stanu zapisu.

Jak pokazano poniżej, BackupAsync przyjmuje BackupDescription obiekt, w którym można określić pełną lub przyrostową kopię zapasową, a także funkcję wywołania zwrotnego wywoływaną Func<< BackupInfo, CancellationToken, Task<bool>>> , gdy folder kopii zapasowej został utworzony lokalnie i jest gotowy do przeniesienia do magazynu zewnętrznego.

BackupDescription myBackupDescription = new BackupDescription(BackupOption.Incremental,this.BackupCallbackAsync);

await this.BackupAsync(myBackupDescription);

Żądanie wykonania przyrostowej kopii zapasowej może zakończyć się niepowodzeniem za pomocą polecenia FabricMissingFullBackupException. Ten wyjątek wskazuje, że dzieje się jedna z następujących rzeczy:

• replika nigdy nie utworzyła pełnej kopii zapasowej, ponieważ stała się podstawowa,
• niektóre rekordy dziennika od czasu ostatniej kopii zapasowej zostały obcięte lub
• replika przekroczyła MaxAccumulatedBackupLogSizeInMB limit.

Użytkownicy mogą zwiększyć prawdopodobieństwo możliwości tworzenia przyrostowych kopii zapasowych przez skonfigurowanie MinLogSizeInMB lub TruncationThresholdFactor. Zwiększenie tych wartości zwiększa użycie dysku repliki. Aby uzyskać więcej informacji, zobacz Reliable Services Configuration (Konfiguracja usług Reliable Services)

BackupInfo zawiera informacje dotyczące kopii zapasowej, w tym lokalizację folderu, w którym środowisko uruchomieniowe zapisało kopię zapasową (BackupInfo.Directory). Funkcja wywołania zwrotnego może przenieść BackupInfo.Directory element do magazynu zewnętrznego lub innej lokalizacji. Ta funkcja zwraca również wartość logiczną wskazującą, czy udało mu się pomyślnie przenieść folder kopii zapasowej do lokalizacji docelowej.

Poniższy kod pokazuje, jak BackupCallbackAsync można użyć metody do przekazania kopii zapasowej do usługi Azure Storage:

private async Task<bool> BackupCallbackAsync(BackupInfo backupInfo, CancellationToken cancellationToken)
{
    var backupId = Guid.NewGuid();

    await externalBackupStore.UploadBackupFolderAsync(backupInfo.Directory, backupId, cancellationToken);

    return true;
}

W poprzednim przykładzie ExternalBackupStore jest to przykładowa klasa używana do interfejsu z usługą Azure Blob Storage i UploadBackupFolderAsync jest metodą kompresowania folderu i umieszcza ją w magazynie obiektów blob platformy Azure.

Należy pamiętać, że:

• W danym momencie można wykonać tylko jedną operację tworzenia kopii zapasowej na replikę. Więcej niż jedno BackupAsync wywołanie w danym momencie zostanie zgłoszonych FabricBackupInProgressException , aby ograniczyć wykonywanie kopii zapasowych w locie do jednego.
• Jeśli replika przechodzi w tryb failover podczas wykonywania kopii zapasowej, tworzenie kopii zapasowej mogło nie zostać ukończone. W związku z tym po zakończeniu pracy w trybie failover usługa jest odpowiedzialna za ponowne uruchomienie kopii zapasowej przez wywołanie BackupAsync w razie potrzeby.

Przywracanie usług Reliable Services

Ogólnie rzecz biorąc, przypadki, w których może być konieczne wykonanie operacji przywracania, należą do jednej z następujących kategorii:

• Partycja usługi straciła dane. Na przykład dysk dla dwóch z trzech replik partycji (w tym repliki podstawowej) jest uszkodzony lub czyszczony. Nowy element podstawowy może wymagać przywrócenia danych z kopii zapasowej.
• Cała usługa zostanie utracona. Na przykład administrator usuwa całą usługę, a tym samym usługę i dane muszą zostać przywrócone.
• Usługa replikował uszkodzone dane aplikacji (na przykład z powodu usterki aplikacji). W takim przypadku należy uaktualnić lub przywrócić usługę, aby usunąć przyczynę uszkodzenia, a nieuprawizowane dane muszą zostać przywrócone.

Chociaż istnieje wiele możliwych podejść, oferujemy kilka przykładów użycia RestoreAsync do odzyskiwania po powyższych scenariuszach.

Partycjonowanie utraty danych w usługach Reliable Services

W takim przypadku środowisko uruchomieniowe automatycznie wykryje utratę danych i wywoła OnDataLossAsync interfejs API.

Aby odzyskać dane, autor usługi musi wykonać następujące czynności:

• Zastąpi metodę OnDataLossAsyncwirtualnej klasy bazowej .
• Znajdź najnowszą kopię zapasową w lokalizacji zewnętrznej zawierającej kopie zapasowe usługi.
• Pobierz najnowszą kopię zapasową (i usuń kompresję kopii zapasowej do folderu kopii zapasowej, jeśli została skompresowana).
• Metoda OnDataLossAsync udostępnia metodę RestoreContext. Wywołaj interfejs RestoreAsync API w podanym RestoreContextpliku .
• Zwraca wartość true, jeśli przywracanie powiodło się.

Poniżej przedstawiono przykładową implementację OnDataLossAsync metody :

protected override async Task<bool> OnDataLossAsync(RestoreContext restoreCtx, CancellationToken cancellationToken)
{
    var backupFolder = await this.externalBackupStore.DownloadLastBackupAsync(cancellationToken);

    var restoreDescription = new RestoreDescription(backupFolder);

    await restoreCtx.RestoreAsync(restoreDescription);

    return true;
}

RestoreDescription przekazana do wywołania RestoreContext.RestoreAsync zawiera element członkowski o nazwie BackupFolderPath. Podczas przywracania pojedynczej pełnej kopii zapasowej należy ustawić tę BackupFolderPath opcję na ścieżkę lokalną folderu zawierającego pełną kopię zapasową. Podczas przywracania pełnej kopii zapasowej i wielu przyrostowych kopii zapasowych należy ustawić ścieżkę lokalną folderu, BackupFolderPath który nie tylko zawiera pełną kopię zapasową, ale także wszystkie przyrostowe kopie zapasowe. RestoreAsync wywołanie może zgłosić, FabricMissingFullBackupException jeśli podana BackupFolderPath wartość nie zawiera pełnej kopii zapasowej. Może również zgłaszać uszkodzenie ArgumentException BackupFolderPath łańcucha przyrostowych kopii zapasowych. Jeśli na przykład zawiera pełną kopię zapasową, pierwsza przyrostowa i trzecia przyrostowa kopia zapasowa, ale nie druga przyrostowa kopia zapasowa.

Uwaga

Ustawienie RestorePolicy jest domyślnie ustawione na Wartość Bezpieczne. Oznacza to, że RestoreAsync interfejs API zakończy się niepowodzeniem z argumentemException, jeśli wykryje, że folder kopii zapasowej zawiera stan starszy lub równy stanowi zawartemu w tej repliki. RestorePolicy.Force można pominąć tę kontrolę bezpieczeństwa. Jest to określone jako część .RestoreDescription

Usunięto lub utracono usługę

Jeśli usługa zostanie usunięta, musisz najpierw ponownie utworzyć usługę przed przywróceniem danych. Należy utworzyć usługę z tą samą konfiguracją, na przykład schemat partycjonowania, aby można było bezproblemowo przywrócić dane. Po uruchomieniu usługi interfejs API do przywrócenia danych (OnDataLossAsync powyżej) musi być wywoływany na każdej partycji tej usługi. Jednym ze sposobów osiągnięcia tego celu jest użycie klasy FabricClient.TestManagementClient.StartPartitionDataLossAsync na każdej partycji.

Od tego momentu implementacja jest taka sama jak w powyższym scenariuszu. Każda partycja musi przywrócić najnowszą odpowiednią kopię zapasową z magazynu zewnętrznego. Jednym z zastrzeżeń jest to, że identyfikator partycji mógł się teraz zmienić, ponieważ środowisko uruchomieniowe tworzy identyfikatory partycji dynamicznie. W związku z tym usługa musi przechowywać odpowiednie informacje o partycji i nazwę usługi, aby zidentyfikować poprawną najnowszą kopię zapasową do przywrócenia z każdej partycji.

Uwaga

Nie zaleca się używania FabricClient.ServiceManager.InvokeDataLossAsync na każdej partycji w celu przywrócenia całej usługi, ponieważ może to spowodować uszkodzenie stanu klastra.

Replikacja uszkodzonych danych aplikacji

Jeśli nowo wdrożone uaktualnienie aplikacji zawiera usterkę, może to spowodować uszkodzenie danych. Na przykład uaktualnienie aplikacji może zacząć aktualizować każdy rekord numeru telefonu w słowniku Reliable Dictionary z nieprawidłowym kodem obszaru. W takim przypadku nieprawidłowe numery telefonów zostaną zreplikowane, ponieważ usługa Service Fabric nie zna charakteru przechowywanych danych.

Pierwszą czynnością, którą należy wykonać po wykryciu takiej rażącej usterki, która powoduje uszkodzenie danych, jest zablokowanie usługi na poziomie aplikacji i, jeśli to możliwe, uaktualnienie do wersji kodu aplikacji, która nie ma usterki. Jednak nawet po naprawieniu kodu usługi dane mogą nadal być uszkodzone i w związku z tym dane mogą być konieczne do przywrócenia. W takich przypadkach może nie wystarczyć do przywrócenia najnowszej kopii zapasowej, ponieważ najnowsze kopie zapasowe również mogą być uszkodzone. W związku z tym należy znaleźć ostatnią kopię zapasową utworzoną przed uszkodzeniem danych.

Jeśli nie masz pewności, które kopie zapasowe są uszkodzone, możesz wdrożyć nowy klaster usługi Service Fabric i przywrócić kopie zapasowe partycji, których dotyczy problem, podobnie jak w powyższym scenariuszu "Usunięto lub utracono usługę". Dla każdej partycji rozpocznij przywracanie kopii zapasowych z najnowszej do najmniejszej. Po znalezieniu kopii zapasowej, która nie ma uszkodzenia, przenieś/usuń wszystkie kopie zapasowe tej partycji, które były nowsze (niż ta kopia zapasowa). Powtórz ten proces dla każdej partycji. Teraz po OnDataLossAsync wywołaniu partycji w klastrze produkcyjnym ostatnia kopia zapasowa znaleziona w magazynie zewnętrznym będzie wybrana przez powyższy proces.

Teraz kroki opisane w sekcji "Usunięta lub utracona usługa" mogą służyć do przywrócenia stanu usługi do stanu przed uszkodzeniem stanu przez kod błędu.

Należy pamiętać, że:

• Podczas przywracania istnieje prawdopodobieństwo, że przywracana kopia zapasowa jest starsza niż stan partycji przed utratą danych. W związku z tym należy przywrócić tylko w ostateczności, aby odzyskać jak najwięcej danych.
• Ciąg reprezentujący ścieżkę folderu kopii zapasowej i ścieżki plików w folderze kopii zapasowej może być większy niż 255 znaków, w zależności od długości ścieżki FabricDataRoot i nazwy typu aplikacji. Może to spowodować, że niektóre metody platformy .NET, takie jak Directory.Move, zgłaszają PathTooLongException wyjątek. Jednym z obejść jest bezpośrednie wywołanie interfejsów API jądra32, takich jak CopyFile.

Tworzenie kopii zapasowej i przywracanie elementów Reliable Actors

Platforma Reliable Actors Framework jest oparta na usługach Reliable Services. ActorService, która hostuje aktorów, jest stanową niezawodną usługą. W związku z tym wszystkie funkcje tworzenia kopii zapasowych i przywracania dostępne w usługach Reliable Services są również dostępne dla elementów Reliable Actors (z wyjątkiem zachowań specyficznych dla dostawcy stanu). Ponieważ kopie zapasowe będą wykonywane na podstawie poszczególnych partycji, stany wszystkich aktorów w tej partycji zostaną utworzone w kopii zapasowej (i przywrócenie będzie podobne i będzie wykonywane na podstawie poszczególnych partycji). Aby wykonać tworzenie kopii zapasowych/przywracanie, właściciel usługi powinien utworzyć niestandardową klasę usługi aktora pochodzącą z klasy ActorService, a następnie wykonać kopię zapasową/przywrócić podobną do usługi Reliable Services, jak opisano powyżej w poprzednich sekcjach.

class MyCustomActorService : ActorService
{
    public MyCustomActorService(StatefulServiceContext context, ActorTypeInformation actorTypeInfo)
          : base(context, actorTypeInfo)
    {
    }
    
    //
    // Method overrides and other code.
    //
}

Podczas tworzenia niestandardowej klasy usługi aktora należy je również zarejestrować podczas rejestrowania aktora.

ActorRuntime.RegisterActorAsync<MyActor>(
    (context, typeInfo) => new MyCustomActorService(context, typeInfo)).GetAwaiter().GetResult();

Domyślnym dostawcą stanu dla elementów Reliable Actors jest KvsActorStateProvider. Przyrostowa kopia zapasowa nie jest domyślnie włączona dla programu KvsActorStateProvider. Możesz włączyć przyrostową kopię zapasową, tworząc KvsActorStateProvider odpowiednie ustawienie w konstruktorze, a następnie przekazując je do konstruktora ActorService, jak pokazano w poniższym fragmencie kodu:

class MyCustomActorService : ActorService
{
    public MyCustomActorService(StatefulServiceContext context, ActorTypeInformation actorTypeInfo)
          : base(context, actorTypeInfo, null, null, new KvsActorStateProvider(true)) // Enable incremental backup
    {
    }
    
    //
    // Method overrides and other code.
    //
}

Po włączeniu przyrostowej kopii zapasowej wykonywanie przyrostowej kopii zapasowej może zakończyć się niepowodzeniem z użyciem klasy FabricMissingFullBackupException z jednego z następujących powodów i należy wykonać pełną kopię zapasową przed wykonaniem przyrostowych kopii zapasowych:

• Replika nigdy nie utworzyła pełnej kopii zapasowej, ponieważ stała się podstawowa.
• Niektóre rekordy dziennika zostały obcięte od czasu utworzenia ostatniej kopii zapasowej.

Po włączeniu KvsActorStateProvider przyrostowej kopii zapasowej nie używa buforu cyklicznego do zarządzania rekordami dzienników i okresowo obcina je. Jeśli użytkownik nie wykonuje kopii zapasowej przez okres 45 minut, system automatycznie obcina rekordy dziennika. Ten interwał można skonfigurować, określając logTruncationIntervalInMinutes w KvsActorStateProvider konstruktorze (podobnie jak w przypadku włączania przyrostowej kopii zapasowej). Rekordy dziennika mogą również zostać obcięte, jeśli replika podstawowa musi skompilować inną replikę, wysyłając wszystkie jego dane.

Podczas przywracania z łańcucha kopii zapasowych, podobnie jak w przypadku usług Reliable Services, ścieżka BackupFolderPath powinna zawierać podkatalogi z jednym podkatalogem zawierającym pełną kopię zapasową i inne podkatalogi zawierające przyrostowe kopie zapasowe. Jeśli walidacja łańcucha kopii zapasowych zakończy się niepowodzeniem, interfejs API przywracania zgłosi wyjątek FabricException z odpowiednim komunikatem o błędzie.

Uwaga

KvsActorStateProvider obecnie ignoruje opcję RestorePolicy.Safe. Obsługa tej funkcji jest planowana w nadchodzącej wersji.

Testowanie tworzenia kopii zapasowej i przywracania

Ważne jest, aby upewnić się, że kopie zapasowe krytycznych danych są tworzone i można je przywrócić. Można to zrobić, wywołując Start-ServiceFabricPartitionDataLoss polecenie cmdlet w programie PowerShell, które może wywołać utratę danych w określonej partycji, aby sprawdzić, czy funkcja tworzenia kopii zapasowej i przywracania danych dla usługi działa zgodnie z oczekiwaniami. Istnieje również możliwość programowego wywoływania utraty danych i przywracania z tego zdarzenia.

Uwaga

Przykładową implementację funkcji tworzenia i przywracania kopii zapasowych można znaleźć w aplikacji do dokumentacji internetowej w usłudze GitHub. Aby uzyskać więcej informacji, zapoznaj się z usługą Inventory.Service .

Pod maską: więcej szczegółów dotyczących tworzenia kopii zapasowych i przywracania

Poniżej przedstawiono więcej szczegółów dotyczących tworzenia kopii zapasowych i przywracania.

Wykonywanie kopii zapasowej

Menedżer niezawodnego stanu umożliwia tworzenie spójnych kopii zapasowych bez blokowania operacji odczytu i zapisu. W tym celu korzysta z punktu kontrolnego i mechanizmu trwałości dziennika. Menedżer reliable state manager przyjmuje rozmyte (lekkie) punkty kontrolne w niektórych punktach, aby zmniejszyć presję z dziennika transakcyjnego i poprawić czas odzyskiwania. Po BackupAsync wywołaniu program Reliable State Manager instruuje wszystkie obiekty Reliable, aby skopiowały najnowsze pliki punktu kontrolnego do lokalnego folderu kopii zapasowej. Następnie program Reliable State Manager kopiuje wszystkie rekordy dziennika, począwszy od wskaźnika początkowego do najnowszego rekordu dziennika w folderze kopii zapasowej. Ponieważ wszystkie rekordy dziennika do najnowszego rekordu dziennika są uwzględniane w kopii zapasowej, a program Reliable State Manager zachowuje rejestrowanie z wyprzedzeniem, menedżer reliable state manager gwarantuje, że wszystkie zatwierdzone transakcje (CommitAsync zostały zwrócone pomyślnie) zostaną uwzględnione w kopii zapasowej.

Każda transakcja zatwierdzana po BackupAsync wywołaniu może lub nie może znajdować się w kopii zapasowej. Po wypełnieniu lokalnego folderu kopii zapasowej przez platformę (tj. tworzenie lokalnej kopii zapasowej jest wykonywane przez środowisko uruchomieniowe), wywołanie wywołania zwrotnego kopii zapasowej usługi. To wywołanie zwrotne jest odpowiedzialne za przeniesienie folderu kopii zapasowej do lokalizacji zewnętrznej, takiej jak Usługa Azure Storage.

Przywracanie

Menedżer niezawodnego stanu zapewnia możliwość przywracania z kopii zapasowej przy użyciu interfejsu RestoreAsync API.
Metoda RestoreAsync on RestoreContext może być wywoływana tylko wewnątrz OnDataLossAsync metody . Wartość logiczna zwrócona przez OnDataLossAsync program wskazuje, czy usługa przywróciła stan z zewnętrznego źródła. Jeśli zwraca OnDataLossAsync wartość true, usługa Service Fabric ponownie skompiluje wszystkie inne repliki z tego podstawowego elementu. Usługa Service Fabric zapewnia, że repliki, które otrzymają OnDataLossAsync wywołanie pierwszego przejścia do roli podstawowej, ale nie mają przyznanego stanu odczytu ani stanu zapisu. Oznacza to, RunAsync że w przypadku implementacji StatefulService nie będzie wywoływana do momentu OnDataLossAsync pomyślnego zakończenia. OnDataLossAsync Następnie zostanie wywołana na nowym podstawowym. Dopóki usługa nie ukończy tego interfejsu API (zwracając wartość true lub false) i zakończy odpowiednią ponowną konfigurację, interfejs API będzie nadal wywoływany pojedynczo.

RestoreAsync najpierw pomiń cały istniejący stan w repliki podstawowej, na którą został wywołany. Następnie narzędzie Reliable State Manager tworzy wszystkie obiekty Reliable, które istnieją w folderze kopii zapasowej. Następnie obiekty Reliable są poinstruowane o przywróceniu z punktów kontrolnych w folderze kopii zapasowej. Na koniec menedżer niezawodnego stanu odzyskuje swój własny stan z rekordów dziennika w folderze kopii zapasowej i wykonuje odzyskiwanie. W ramach procesu odzyskiwania operacje rozpoczynające się od "punktu początkowego", które mają zatwierdzone rekordy dziennika w folderze kopii zapasowej, są odtwarzane do obiektów Reliable. Ten krok gwarantuje, że odzyskany stan jest spójny.

Następne kroki

• Niezawodne kolekcje
• Przewodnik Szybki start dotyczący usług Reliable Services
• Powiadomienia dotyczące usług Reliable Services
• Konfiguracja usług Reliable Services
• Dokumentacja dla deweloperów dotycząca kolekcji Reliable Collections
• Okresowe wykonywanie kopii zapasowej i przywracanie w usłudze Azure Service Fabric