Azure SQL Backup

Azure SQL Backup to mechanizm automatycznych kopii zapasowych wbudowany w usługę bazodanową Azure SQL Database.

Jak działa Azure SQL Backup w usłudze Azure SQL Database

Azure SQL Backup oznacza zarządzany przez platformę mechanizm tworzenia kopii zapasowych baz danych działających w usłudze Azure SQL Database. Kopie są wykonywane automatycznie, bez uruchamiania własnych zadań SQL Server Agent, skryptów systemowych ani ręcznego kopiowania plików bazodanowych. Użytkownik nie zarządza bezpośrednio katalogiem zawierającym pliki kopii. Azure przechowuje backup w infrastrukturze usługi i udostępnia operacje odtwarzania przez portal Azure, interfejs wiersza poleceń, PowerShell oraz API.

Mechanizm obejmuje kopie pełne, różnicowe oraz kopie dziennika transakcji. Ich zadaniem jest umożliwienie odtworzenia bazy do określonego momentu z zakresu dostępnej retencji. Oznacza to, że przywrócenie nie ogranicza się do stanu z chwili wykonania ostatniej kopii pełnej. Usługa może odtworzyć bazę do wybranego czasu, o ile dany punkt znajduje się w okresie przechowywania kopii i nie został przekroczony zakres dostępnego dziennika transakcji.

Odtwarzanie punktualne i zakres retencji

Najczęściej używaną funkcją Azure SQL Backup jest point-in-time restore, czyli odtwarzanie do wskazanego momentu. Operacja tworzy nową bazę danych na podstawie kopii przechowywanych przez usługę. Pozwala to odzyskać dane po przypadkowym usunięciu rekordów, błędnej aktualizacji, nieprawidłowym wdrożeniu aplikacji albo innym zdarzeniu, które zmieniło zawartość bazy. Przywrócona baza nie zastępuje automatycznie źródłowej bazy i przed przełączeniem aplikacji trzeba zweryfikować jej nazwę, uprawnienia, konfigurację połączeń oraz kompletność danych.

Retencja określa, jak długo kopie automatyczne pozostają dostępne dla odtwarzania. Jej długość zależy od konfiguracji usługi i wybranego modelu obsługi bazy. Retencja kopii automatycznych nie jest tym samym co długoterminowe przechowywanie backupów. Jeżeli potrzebne jest zachowanie kopii przez znacznie dłuższy okres, stosuje się funkcję long-term retention, która przechowuje wybrane kopie pełne zgodnie z osobną polityką. Zmiana retencji nie przywraca kopii usuniętych wcześniej i nie zastępuje testów odtwarzania.

Redundancja, geoodtwarzanie i ograniczenia kopii

Podczas konfiguracji Azure SQL Database można określić sposób replikowania danych backupu, między innymi w obrębie jednego obszaru geograficznego albo z wykorzystaniem dodatkowej lokalizacji. Wybór redundancji wpływa na odporność kopii na awarię infrastruktury i na możliwość wykonania geograficznego odtworzenia. Nie należy jednak utożsamiać każdej repliki bazy z niezależną kopią zapasową. Replikacja geograficzna służy przede wszystkim ciągłości działania, natomiast backup służy odzyskaniu danych z wcześniejszego stanu.

Kopia zapasowa nie rozwiązuje wszystkich problemów aplikacji. Jeśli aplikacja zapisuje błędne dane, kopia wykonana po takim zapisie może zachować ten sam błąd. Backup nie odtwarza również automatycznie ustawień całego środowiska, sekretów, konfiguracji aplikacji, mapowań logowania ani zależności między wieloma bazami. Po operacji restore trzeba sprawdzić schemat, dane, indeksy, procedury, uprawnienia oraz połączenie z aplikacją. W środowisku obejmującym kilka baz należy dodatkowo uwzględnić różnice czasowe między ich stanami.

Weryfikacja kopii Azure SQL Database w praktyce

Kontrola Azure SQL Backup powinna obejmować nie tylko informację, że kopie są włączone, lecz także sprawdzenie retencji, redundancji, dostępnych punktów odtwarzania i uprawnień potrzebnych do wykonania restore. Warto ustalić, czy polityka kopii odpowiada wymaganiom dotyczącym maksymalnej akceptowalnej utraty danych oraz czasu przywrócenia usługi. Sama obecność backupu w portalu nie dowodzi, że odtworzenie zakończy się poprawnie w rzeczywistym scenariuszu awarii.

Podczas diagnostyki problemu z Azure SQL Database analizuje się między innymi historię operacji, komunikaty platformy, status bazy, konfigurację retencji i redundancji oraz wynik próbnego odtworzenia. Istotne jest rozróżnienie błędu samego backupu od problemu z autoryzacją, limitem zasobów, siecią, nazwą serwera logicznego lub konfiguracją klienta. Przywrócona baza powinna zostać sprawdzona na danych testowych i porównana z oczekiwanym punktem czasowym, ponieważ poprawne zakończenie operacji technicznej nie gwarantuje poprawności procesu biznesowego.