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 miała punkty kontrolne, które wynoszą w przybliżeniu 16 GB. Jeśli mamy cel punktu odzyskiwania danych na poziomie pięciu minut, kopia zapasowa repliki musi być wykonywana co pięć minut. Za każdym razem, gdy jest tworzona kopia zapasowa, musi skopiować 16 GB punktów kontrolnych oraz dodatkowo 50 MB dzienników (można skonfigurować za pomocą CheckpointThresholdInMB).

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 obiekt BackupDescription, w którym można określić pełną lub przyrostową kopię zapasową, oraz funkcję zwrotną Func<< BackupInfo, CancellationToken, Task<bool>>>, która jest wywoływana, gdy folder kopii zapasowej zostanie utworzony lokalnie i będzie 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 z powodu FabricMissingFullBackupException. Ten wyjątek wskazuje, że dzieje się jedna z następujących rzeczy:

• replika nigdy nie utworzyła pełnej kopii zapasowej, od kiedy stała się główną
• 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 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że być w toku tylko jedna operacja tworzenia kopii zapasowej na replikę. Więcej niż jedno wywołanie BackupAsync jednocześnie spowoduje FabricBackupInProgressException, aby ograniczyć wykonywanie jednoczesnych kopii zapasowych do jednej.
• Jeśli replika ulegnie awarii podczas tworzenia kopii zapasowej, proces ten może nie zostać ukończony. 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 niezawodnych usług

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) został uszkodzony lub wymazany. Nowa jednostka główna 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ć usługę lub przywrócić ją do poprzedniej wersji, a nieuszkodzone dane muszą zostać przywrócone, aby usunąć przyczynę uszkodzenia.

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

Zarządzanie utratą danych w usługach niezawodnych (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:

• Nadpisz metodę OnDataLossAsync wirtualnej 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 API RestoreAsync na podanym RestoreContext.
• 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ć wyjątek ArgumentException, jeśli BackupFolderPath ma uszkodzony łańcuch 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

RestorePolicy jest domyślnie ustawione na Bezpieczne. Oznacza to, że interfejs API RestoreAsync zakończy się niepowodzeniem z ArgumentException, jeśli wykryje, że folder kopii zapasowej zawiera stan, który jest starszy lub równy stanowi zawartemu w tej replikie. 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, gdy OnDataLossAsync jest wywoływane na partycji w klastrze produkcyjnym, ostatnia kopia zapasowa znaleziona w magazynie zewnętrznym będzie tą wybraną 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 sprzed uszkodzenia przez wadliwy kod.

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 powinieneś przywrócić dane tylko w ostateczności, aby odzyskać możliwie 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 .NET, takie jak Directory.Move, wyrzucają wyjątek PathTooLongException. Jednym z rozwiązań jest bezpośrednie wywołanie interfejsu API Kernel32, takich jak CopyFile.

Tworzenie kopii zapasowej i przywracanie Reliable Actors

Platforma Reliable Actors Framework jest oparta na usługach Reliable Services. ActorService, który hostuje aktorów, jest niezawodną stanową 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 komponentów Reliable Actors (z wyjątkiem zachowań specyficznych dla dostawcy stanu). Ponieważ kopie zapasowe będą wykonywane dla poszczególnych partycji, stany wszystkich aktorów w danej partycji zostaną zarchiwizowane (podobnie przywracanie będzie odbywać się dla poszczególnych partycji). Do wykonania kopii zapasowej/przywracania, właściciel usługi powinien utworzyć niestandardową klasę usługi aktora dziedziczącą z klasy ActorService, a następnie wykonać kopię zapasową/przywracanie podobnie jak w przypadku 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 ją 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 z odpowiednimi ustawieniami w jego konstruktorze, a następnie przekazując go 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, odkąd stała się repliką główną.
• Niektóre rekordy dziennika zostały obcięte od czasu utworzenia ostatniej kopii zapasowej.

Po włączeniu przyrostowej kopii zapasowej KvsActorStateProvider nie używa bufora cyklicznego do zarządzania rekordami dzienników i okresowo je obcina. 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 główna musi stworzyć inną replikę, wysyłając wszystkie swoje 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.

Kopia zapasowa

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. Niezawodny Menedżer Stanu przyjmuje przybliżone (lekkie) punkty kontrolne w określonych momentach, aby zmniejszyć presję na dziennik transakcji 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 aż do najnowszego są uwzględniane w kopii zapasowej, a Reliable State Manager zachowuje rejestrowanie w trybie write-ahead, Reliable State Manager gwarantuje, że wszystkie transakcje, które zostały zatwierdzone (CommitAsync zostały zwrócone pomyślnie), są 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.

Przywróć

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, najpierw przejdą do roli podstawowej, lecz nie otrzymują statusu odczytu ani zapisu. Oznacza to, że dla implementerów StatefulService RunAsync nie zostanie wywołane, dopóki OnDataLossAsync nie zakończy się pomyślnie. Następnie OnDataLossAsync zostanie wywołana na nowym głównym. Dopóki usługa nie ukończy pozytywnie tego interfejsu API (zwracając wartość true lub false) i nie zakończy odpowiedniej ponownej konfiguracji, interfejs API będzie nadal wywoływany jeden po drugim.

RestoreAsync najpierw usuwa cały istniejący stan na 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” otrzymują polecenie przywrócenia 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 szybkiego startu 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 tworzenie i przywracanie kopii zapasowych w usłudze Azure Service Fabric