Tworzenie kopii zapasowej i przywracanie
W dużych lub małych organizacjach mogą wystąpić awarie i zdarzenia. Dlatego należy zawsze mieć plan przywrócenia systemów w razie zakłócenia ich działania. W programie SQL Server, jeśli chcesz przywrócić bazę danych do punktu w czasie, możesz to zrobić tylko wtedy, gdy działasz w modelu odzyskiwania pełnego. W przypadku modelu odzyskiwania z niepełnym dziennikiem bardziej prawdopodobna będzie konieczność odzyskania bazy danych do końca kopii zapasowej dziennika transakcji.
Jedną z korzyści związanych z usługą Azure SQL jest to, że platforma Azure może zająć się tym wszystkim za Ciebie. Ponieważ usługa Azure SQL zarządza kopiami zapasowymi i działa w modelu odzyskiwania pełnego, można przywrócić bazę danych do dowolnego punktu w czasie. Można nawet przywrócić usuniętą bazę danych w ramach skonfigurowanych zasad przechowywania. Dodatkowo firma Microsoft automatycznie szyfruje kopie zapasowe, jeśli technologia TDE jest włączona na serwerze logicznym lub w wystąpieniu.
Domyślnie pełna kopia zapasowa bazy danych jest wykonywana raz w tygodniu. Kopie zapasowe dzienników są wykonywane co 5–10 minut, a różnicowe kopie zapasowe co 12–24 godziny. Pliki kopii zapasowej domyślnie są przechowywane w usłudze Azure Storage z dostępem do odczytu z magazynu geograficznie nadmiarowego (RA-GRS). Można jednak wybrać opcję tworzenia kopii zapasowych w magazynie strefowo nadmiarowym (ZRS) lub magazynie lokalnie nadmiarowym (LRS). Zespół inżynierów usługi Azure SQL na bieżąco automatycznie testuje przywracanie zautomatyzowanych kopii zapasowych baz danych znajdujących się na serwerach logicznych i w elastycznych pulach baz danych. W przypadku migracji do usługi Azure SQL Managed Instance jest wykonywana automatyczna początkowa kopia zapasowa z sumą kontrolną baz danych przywróconych za pomocą natywnego polecenia RESTORE lub usługi Azure Database Migration Service. Ponadto w usłudze Azure SQL Managed Instance można opcjonalnie wykonać natywną kopię zapasową copy-only i zapisać ją w usłudze Azure Blob Storage.
Opracowywanie strategii tworzenia kopii zapasowych dla usług Azure SQL Managed Instance i Azure SQL Database
Usługa Azure SQL zajmuje się dużym obciążeniem, ale nadal ważne jest zrozumienie sposobu przechowywania i przetwarzania kopii zapasowych oraz możliwości przechowywania i przywracania. Ostatecznie nadal odpowiadasz za ogólną strategię przywracania do punktu w czasie, długoterminowego przechowywania i przywracania geograficznego.
Przywracanie do punktu w czasie (PITR)
W usługach Azure SQL Database i Azure SQL Managed Instance można przeprowadzić przywracanie samoobsługowe. Możesz wybrać konkretny punkt w czasie, do którego chcesz przywrócić i uruchomić proces przy użyciu witryny Azure Portal, programu PowerShell/interfejsu wiersza polecenia platformy Azure lub interfejsów API REST. Przywracanie do punktu w czasie (PITR) spowoduje utworzenie nowej bazy danych (o innej nazwie) na tym samym serwerze logicznym. Jeśli chcesz zastąpić oryginalną bazę danych bazą danych PITR, musisz zmienić nazwę zarówno oryginalnej, jak i nowej bazy danych, aby wrócić do stanu działania. Nie trzeba aktualizować parametrów połączenia.
Przechowywanie na potrzeby przywracania do punktu w czasie trwa od 1 do 35 dni. Domyślnie okres przechowywania (dla wszystkich warstw usług i opcji wdrażania) wynosi siedem dni. W przypadku większości opcji wdrażania i warstw usług można skonfigurować zasady tak, aby wynosił on od 1 do 35 dni w zależności od wymagań scenariusza. Na przykład może być potrzebny tylko jeden dzień dla testowej bazy danych, ale możesz wybrać maksymalnie 35 dni dla bazy danych o znaczeniu krytycznym.
Przechowywanie długoterminowe (LTR)
Jeśli 35 dni nie wystarcza do spełnienia wymagań organizacji lub dotyczących zgodności, możesz wybrać przechowywanie długoterminowe (LTR). Ta opcja umożliwia automatyczne tworzenie pełnych kopii zapasowych bazy danych przechowywanych w magazynie RA-GRS, ZRS lub LRS przez maksymalnie 10 lat. W przypadku usługi Azure SQL Database, przechowywanie długoterminowe jest ogólnie dostępne. W przypadku usługi Azure SQL Managed Instance przechowywanie długoterminowe jest dostępne w ograniczonej publicznej wersji zapoznawczej.
Przywracanie geograficzne
W razie wystąpienia katastrofalnego zdarzenia organizacja musi mieć możliwość odzyskiwania. Kopie zapasowe są automatycznie przechowywane w magazynie geograficznie nadmiarowym z dostępem do odczytu (chyba że zdecydujesz się na magazyn strefowo nadmiarowy lub magazyn lokalnie nadmiarowy), co oznacza, że kopie zapasowe będą przechowywane w regionie sparowanym. Zatem jeśli cały region ulegnie awarii, a Twoje bazy danych lub wystąpienia zarządzane znajdują się w tym regionie, masz zapewnioną ochronę. Przywracanie geograficzne można wykonać w dowolnym innym regionie z najnowszej kopii zapasowej zreplikowanej geograficznie. Ta kopia zapasowa może być nieco opóźniona względem podstawowej, ponieważ potrzebuje czasu na zreplikowanie obiektu blob platformy Azure do innego regionu. Przywracanie geograficzne można łatwo przeprowadzić przy użyciu witryny Azure Portal, programu PowerShell/interfejsu wiersza polecenia platformy Azure lub interfejsów API REST.