Crash-Consistent vs Application-Consistent Backup

Bez dwóch zdań – spójność danych w kopii zapasowej to absolutny priorytet. Innymi słowy – czy dane, które znajdują się w backupie są w ogóle dla nas użyteczne, czyli czy będziemy w stanie odzyskać je w razie potrzeby? Ogólnie rzecz biorąc jest kilka różnych opcji tworzenia backupów, które są dla nas użyteczne, o których możemy usłyszeć. Dzisiaj zajmiemy się dwoma rodzajami, czyli właśnie backupem crash-consistent oraz application-consistent. Co oznaczają te nazwy? Kiedy potrzebujemy pierwszego typu, a kiedy drugiego?

Crash-consistent backup

Backup tego typu pozwala na spójne backupy plików na dysku. Jest to spójny backup z punktu widzenia odtworzenia danych w przypadku awarii, działa na zasadzie snapshota wszystkich plików w dokładnie tym samym momencie w czasie. Dzięki temu, jakiekolwiek pliki, które wzajemnie na sobie polegają, są uchwycone w dokładnie tej samej fazie, dzięki czemu są spójne i w razie odtworzenia bazujemy na tej ich wersji, która wystąpiła w momencie wykonania migawki. Samo pojęcie „crash-consistent” odnosi się do tego, że tworzymy backup, który uchwyci nasze dane natychmiast i zapisze je jako punkt do ich odzyskania, z którego jesteśmy w stanie odzyskać je w przypadku awarii.

Można się zastanawiać w jaki sposób oprogramowanie do tworzenia kopii zapasowych jest w stanie wykonać migawkę całego zestawu danych w dokładnie tym samym momencie w czasie. Dzieje się tak dzięki wykorzystaniu narzędzia Microsoftu Volume Shadow Copy, czyli usługi, która jest częścią większości nowoczesnych systemów operacyjnych Windows. Volume Shadow Copy lub po prostu VSS, szybko „zamraża” wszystkie operacje zapisu/odczytu na woluminie, które następnie są kolejkowane i konkretne bloki, które są w użyciu przez ten wolumin, zostają zapisane. Dzieje się to zaledwie w kilka sekund. Dzięki temu VSS wie, które bloki danych były używane w momencie wykonania migawki. Samo oprogramowanie do backupu może później, w wolnej chwili, skopiować wszystkie fizyczne dane z dysku nawet później, po zmianie tych bloków. Ponieważ dzięki migawce oprogramowanie może dostać się do konkretnej wersji bloku z momentu wykonania snapshota i zapisać je jako backup. Nie należy przy tym mylić migawki z backupem!

Backup typu crash-consistent jest znacznie lepszy niż stary niespójny backup, który po prostu tworzy kopię plików na dysku. Jednakże, jeśli pliki ulegną zmianie podczas procesu tworzenia kopii zapasowej, to te pliki, które polegają na sobie wzajemnie (potrzebują konkretnej swojej wersji by je odtworzyć) nie będą ze sobą spójne, ponieważ jeśli jeden plik potrzebuje drugiego by było możliwe jego odzyskanie, a ten drugi plik uległ zmianie – nie będziemy w stanie odtworzyć naszego pliku nr jeden.

Nawet biorąc pod uwagę ogromną przewagę backupu crash-consistent nad wyżej wspomnianym backupem niespójnym, należy mieć świadomość dość sporej jego wady z punktu widzenia upewnienia się, że dane aplikacji, które mogą znajdować się w pamięci lub w trwających w danej chwili operacjach I/O, są spójne. Ma to zastosowanie zwłaszcza w przypadku aplikacji bazodanowych jak np. Microsoft SQL Server czy Microsoft Exchange. Jak zatem upewniamy się, że dane aplikacji są spójne? Korzystamy z backupu typu application-consistent!

Application-consistent backup

W odróżnieniu od wcześniej opisanego typu backupu, model application-consistent ma możliwość uzyskania informacji, które znajdują się zarówno w pamięci, jak i w trwających właśnie operacjach I/O. Dzieje się tak dzięki użyciu tzw. VSS writers. Omówiliśmy już w jaki sposób Volume Shadow Copy działa na poziomie woluminów. VSS writers to elementy aplikacyjne dla usługi Volume Shadow Copy, które dbają o spójność danych w aplikacji podczas tworzenia kopii.

Microsoft’owe VSS writers oraz writery firm trzecich pozwalają VSS’owi na kontrolę nad specyficznymi danymi aplikacyjnymi, nie tylko nad plikiem czy dyskiem, a także pozwalają tym aplikacjom na backup z zachowaniem spójności. Np. Microsoft SQL Server może mieć w pamięci bardzo dużo danych, tak samo jak wiele operacji I/O może mieć miejsce w danej chwili. Normalny backup plików na dysku typu crash-consistent, który byłby spójny na poziomie plików, przegapiłby dane właśnie w pamięci czy w trwających operacjach I/O. Jednakże w przypadku backupu application-consistent, VSS writer dla serwera Microsoft SQL pozwoli na zapisanie informacji z pamięci i z operacji I/O na dysku w poprawnej kolejności aby backup tego dysku wraz z danymi aplikacji zawierał spójne informacje transakcyjne. Backupy typu application-consistent są również nazywane „application aware”, czyli w wolnym tłumaczeniu świadomymi aplikacji, których kopie wykonują, świadomymi ich specyfiki i wymogów transakcyjnych jako części całego procesu backupu.

Kolejną krytyczną różnicą między backupem crash-consistent oraz application-consistent jest ilość pracy, którą trzeba wykonać już po przeprowadzeniu odzyskania danych. W przypadku backupu crash-consistent, jako, że dane mogą nie być spójne, trzeba przejść całą procedurę doprowadzenia aplikacji właśnie do formy zgodnej z chwilą wykonania backupu. Ten proces dotyczy zarówno MS Exchange jak i MS SQL. Zaś w przypadku trybu application-consistent dane już są spójne, gdyż zadbały o to VSS writery. W przypadku potrzeby odtworzenia systemu po awarii lub przeprowadzenia skutecznego disaster recovery, zdecydowanie lepiej jest mieć backup typu application-consistent niż crash-consistent, zwłaszcza w przypadku serwerów bazodanowych.

Status VSS writerów w Windowsie można sprawdzić używając komendy vssadmin list writers. Na poniższych screenach pokazujemy, że wyszczególnione są zarówno VSS SqlServerWriter oraz Microsoft Exhange Writer. Komenda vssadmin jest świetnym narzędziem dla VSS, dzięki któremu można przeprowadzić diagnostykę problemu.

Microsoft Exchange Writer:

Komendy dostępne z poziomu vssadmin:

Krótkie podsumowanie różnic pomiędzy backupem crash-consistent a application-consistent:

Wnioski

Brak zrozumienia różnicy pomiędzy typami backupów, które dzisiaj omówiliśmy, może prowadzić do nieoczekiwanych rezultatów procesu wykonywania naszych kopii zapasowych, a nawet może skutkować uszkodzeniem naszych danych i niemożliwością ich odzyskania. Różnice w radzeniu sobie z danymi aplikacji takich jak MS SQL Server czy MS Exchange przez backupy typu crash-consistent oraz application-consistent są znaczące. Backupy crash-consistent nie są świadome danych obecnych w pamięci aplikacji ani tych, które znajdują się w operacjach I/O. Z kolei backup application-consistent potrafi sobie poradzić z tymi „chwilowymi” danymi dzięki wykorzystaniu VSS writers jako elementów usługi VSS w Windowsie by poprawnie zapisać wszystkie dane aplikacji, włącznie z tymi z pamięci oraz w trwających operacjach I/O, na dysk, pozwalając tym samym, by zostały one zbackupowane w poprawny sposób, z zachowaniem spójności.

Gdybyście szukali rozwiązania, które zrobi backup typu application-consistent to polecamy NAKIVO z QNAP