SQL Server Backup na Proxmox – 10 nocy zerwanych kopii, a restore zielony z danymi sprzed 68 h
SQL Server backup na Proxmoxie potrafi po cichu wejść w konflikt z backupem całej maszyny wirtualnej. Po migracji serwerów z Hyper-V na Proxmoxa nocny backup maszyny w Proxmox Backup Server był dla SQL Servera zwykłą pełną kopią bazy i przez dziesięć nocy zrywał łańcuch kopii różnicowych. Test odtwarzania, który co cztery godziny przywracał bazę na osobnym serwerze, przez cały ten czas kończył się sukcesem – tylko że odtwarzał dane sprzed nawet 68 godzin. Jeśli masz SQL Server na Proxmoxie albo planujesz migrację z Hyper-V czy VMware, w tym tekście znajdziesz mechanizm, sposób sprawdzenia własnej konfiguracji jednym zapytaniem i dwie naprawy.
Artykuł towarzyszy filmowi na moim kanale YouTube i otwiera cykl o NIS2 od strony praktyka. W filmie pokazuję cały mechanizm na maszynie testowej, krok po kroku, a z produkcji – wyłącznie odczyty z systemowej bazy msdb. Tutaj porządkuję pojęcia, liczby i kontrole, do których warto wracać. Wszystkie wartości pochodzą z rzeczywistych pomiarów w utrzymywanej przeze mnie infrastrukturze i z laboratorium, w którym odtworzyłem problem.
Dwa backupy w jednej maszynie, które nic o sobie nie wiedzą
W maju przeniosłem serwery z Hyper-V na Proxmoxa. Maszyna z bazą systemu ERP przeszła 23 maja. W środku SQL Server robi własne kopie: pełną w sobotę o 23:00, różnicową co cztery godziny od północy i kopię dziennika transakcji co 15 minut. Osobny serwer co cztery godziny odtwarza pełną plus najmłodszą różnicową, sześć razy na dobę, i z tego idą raporty, które zarząd czyta rano.
Nadrzędnie, z poziomu hosta, Proxmox Backup Server w nocy kopiuje całą maszynę. To dwie warstwy z dwoma różnymi zadaniami: PBS chroni maszynę – system, konfigurację, aplikacje – a łańcuch kopii SQL Servera chroni dane z dokładnością do minuty. Problem w tym, że oba backupy obejmują tę samą maszynę i nic o sobie nie wiedzą. Spotykają się w jednym miejscu: w usłudze VSS systemu Windows.
Full, Diff, Log i Copy Only w pigułce
Pełna kopia (full) to cała baza zapisana do jednego pliku. Od niej zaczyna się każde odtworzenie. Jest duża i trwa długo, dlatego zwykle robi się ją raz w tygodniu. Kopia różnicowa (differential, DIFF) zawiera wszystko, co zmieniło się od ostatniej pełnej kopii – nie od poprzedniej różnicowej. Do odtworzenia wystarczy więc pełna i jedna, najmłodsza różnicowa.
Pełna kopia, do której odnoszą się wszystkie różnicowe, to plik bazowy kopii różnicowej (differential base). To pojęcie jest kluczem do całej tej historii: każda pełna kopia bez opcji copy only podmienia plik bazowy. Kopia dziennika transakcji (log) zawiera każdą zmianę od poprzedniej kopii dziennika i pozwala odtworzyć bazę do konkretnej minuty, pod warunkiem że baza pracuje w pełnym modelu odzyskiwania.
Copy only to pełna kopia, która nie podmienia pliku bazowego – łańcuch nawet nie zauważa, że powstała. Po nią sięgasz, gdy potrzebujesz pełnej kopii poza harmonogramem, na przykład na serwer testowy. Microsoft opisuje to szczegółowo w dokumentacji kopii typu copy-only.
Tryb snapshot, agent QEMU, VSS i SQL Writer
Proxmox ma trzy tryby backupu maszyny: zatrzymanie, wstrzymanie i snapshot. Domyślny snapshot kopiuje dyski działającej maszyny w tle i utrwala stan z chwili startu zadania. Żeby ten stan był spójny, Proxmox prosi system gościa o chwilowe zamrożenie zapisów – przez agenta QEMU. Windows nie ma go w standardzie: instaluje się go z pakietu sterowników virtio-win, a w Proxmoxie włącza w opcjach maszyny.
Bez agenta kopia też powstanie, ale będzie jak po wyrwaniu wtyczki z prądu: system wstanie, baza przejdzie standardowe odzyskiwanie po awarii. Z agentem zamrożenie obsługuje VSS (Volume Shadow Copy Service), który wysyła komunikat do zarejestrowanych aplikacji: przygotujcie się, robimy kopię. SQL Server odbiera go przez własną usługę – SQL Writer. I tu zaczyna się problem.
Laboratorium: trzy systemy, dwa różne wyniki
Zanim nagrałem film, przygotowałem laboratorium na trzech systemach: Windows Server 2022, Windows 10 i Windows 11 – z tym samym SQL Serverem i tym samym agentem QEMU. Spodziewałem się wszędzie tego samego wyniku. Na Windows Server SQL Server w trakcie backupu maszyny robił pełną, spójną kopię bazy – dokładnie tak jak na produkcji. Na Windows 10 i 11, także po aktualizacjach, zamrażał zapisy, ale kopii nie kończył: w logu „BACKUP failed”, w historii kopii pusto.
Dlaczego tak jest – nie przesądzam, opisuję, co zmierzyłem na tych wersjach systemu i agenta. Wniosek praktyczny: na Windows 10 i 11 kopia maszyny wirtualnej nie zastąpi kopii robionych przez sam SQL Server, bo to one są tam jedyną spójną kopią bazy. Windows Server robi to poprawnie, ale ma haczyk, o którym jest reszta tekstu.
Co SQL Server zapisał w msdb
Na maszynie testowej z Windows Server zrobiłem pełną kopię, kopię różnicową i kopię dziennika, a potem dokładnie to, co PBS robił na produkcji co noc: backup całej maszyny w trybie snapshot. W logu zadania: zamrożenie, odmrożenie, zadanie zakończone sukcesem. Nic nie ostrzega.
SQL Server zapisuje każdy backup w systemowej bazie msdb, w tabeli backupset. Po backupie maszyny pojawił się w niej nowy wiersz: typ D (pełna kopia), is_snapshot = 1, is_copy_only = 0 użytkownik SYSTEM (na polskim Windowsie „ZARZĄDZANIE NT\SYSTEM”), czas – sekunda, czyli tyle, ile trwało zamrożenie zapisów. Zamiast ścieżki do pliku jest identyfikator urządzenia wirtualnego. Dla SQL Servera backup całej maszyny był zwykłą pełną kopią bazy – i podmienił plik bazowy kopii różnicowych, choć pliku tej kopii nie ma w żadnym katalogu kopii.
Błąd 3035 i restore, który odtwarza przeszłość
Następna kopia różnicowa kończy się błędem 3035: „Cannot perform a differential backup (…) because a current database backup does not exist”. SQL Server podpowiada nawet, żeby zrobić pełną kopię – choć przed chwilą sam zapisał w historii pełną kopię ze snapshotu. Na produkcji wyglądało to tak samo: od nocnego backupu maszyny każda kolejna różnicowa kończyła się błędem, aż do ręcznej odbudowy łańcucha albo sobotniej pełnej kopii. Kopia dziennika przechodzi bez problemu.
Najważniejsze jest to, co dzieje się z odtwarzaniem. Skrypt na serwerze analitycznym bierze najnowszą pełną kopię z katalogu i dokłada do niej najmłodszą różnicową z tego samego katalogu. Pełnej kopii ze snapshotu w katalogu nie ma, więc skrypt bierze poprzednią pełną, a najmłodsza różnicowa to ta sprzed snapshotu. Ta para do siebie pasuje, więc odtworzenie kończy się sukcesem – bez jednego błędu. Tylko że odtworzona baza kończy się na stanie sprzed snapshotu. W laboratorium odtworzona kopia miała 16 minut. Na produkcji 7 lipca ten sam mechanizm dał 68 godzin.
Produkcja w liczbach: copy only z 1 na 0 i 68 godzin
To samo zapytanie na produkcji, ograniczone do wpisów ze snapshotu, pokazało całą historię. Od lutego 2024 jedenaście wpisów jeszcze z czasów Hyper-V – wszystkie z is_copy_only = 1, więc łańcucha nie dotykały. Pierwszy backup maszyny po przeniesieniu na Proxmoxa, 24 maja: is_copy_only = 0. Nocny harmonogram PBS dla tej maszyny ruszył pod koniec czerwca, a od 1 lipca – dziesięć nocy z rzędu, zawsze około wpół do trzeciej – każdy backup maszyny zostawiał wpis z zerem.
Noc z 7 lipca dobrze pokazuje skalę rozjazdu: kopia maszyny trwała 54 minuty i 40 sekund, ponad 350 GiB przesłanych na PBS. Dla SQL Servera ta sama kopia trwała 9 sekund, bo liczy się tylko moment zamrożenia – i w tych 9 sekundach zapisał pełny backup bazy. Liczba kopii różnicowych na dobę spadła z sześciu do zera w części dni, a wiek odtwarzanej kopii, normalnie do czterech godzin, rósł do doby, półtorej, prawie dwóch – i 7 lipca doszedł do 68 godzin. Liczba udanych odtworzeń przez cały czas się zgadzała.
Jak doszedłem do przyczyny
Zaczęło się od zgłoszenia analityków: w raportach nie było świeżych danych. Pierwsza hipoteza była najbardziej typowa dla takiego objawu – ktoś zrobił ręcznie pełną kopię bez copy only. Zrobiłem więc to, co robi się przy zerwanym łańcuchu: wyłączyłem zadania kopii, odbudowałem łańcuch od nowej pełnej kopii i włączyłem zadania z powrotem. Kopie różnicowe wracały – do następnej nocy.
Przełom przyszedł przy zestawieniu godzin z logów: każde zerwanie pojawiało się tuż po tym, jak PBS dotknął tej maszyny, a pierwszym podejrzanym stał się SQL Writer. Historia kopii potwierdziła godziny. 10 lipca o 2:38 jest ostatni wpis ze snapshotu – tego dnia wyłączyłem SQL Writera, a o 14:00 kopie różnicowe zaczęły znowu powstawać. Od tamtej pory PBS co noc kopiował maszynę, ale w historii kopii nie przybył już ani jeden wpis ze snapshotu, a wiek odtwarzanej kopii wrócił do kilku minut.
Dane nie były zagrożone ani przez chwilę
Pełna kopia bez copy only podmienia plik bazowy kopii różnicowych, ale nie przerywa łańcucha kopii dziennika transakcji. Kopie dziennika robiły się co 15 minut przez całe dziesięć dni. Z pełnej kopii sprzed snapshotu i wszystkich kopii dziennika można było odtworzyć bazę do ostatniej zmiany albo do dowolnie wybranej minuty.
Popsuła się droga na skróty przez kopie różnicowe – dokładnie ta, z której korzystał test odtwarzania i raporty analityków. To ważne rozróżnienie: problem dotyczył świeżości danych w raportach, a nie odtwarzalności bazy.
Dwie naprawy: wyłączony SQL Writer albo VssOption = 5
Naprawa 1: wyłączony SQL Writer. Szybka i skuteczna – tę wybrałem w lipcu. Po wyłączeniu usługi trzeba zrobić nową pełną kopię z poziomu SQL Servera, żeby plikiem bazowym znowu był plik z katalogu kopii. W logu PBS zamrożenie nadal jest, w backupset nic nowego nie przybywa, kopia różnicowa robi się bez błędu. Cena: SQL Server nie bierze udziału w kopii maszyny, więc baza w tej kopii jest w stanie jak po nagłym wyłączeniu zasilania. Da się z tym żyć, jeśli z kopii PBS odtwarzasz system i konfigurację, a dane – z łańcucha SQL.
Naprawa 2: VssOption = 5. Agent QEMU na Windowsie domyślnie prosi VSS o pełną kopię. Odpowiada za to wartość VssOption w kluczu HKLM\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider: 1 oznacza pełną kopię i tak ustawia ją instalator, 5 – kopię typu copy only. Opcja działa od virtio-win 0.1.262 i jest opisana w dokumentacji Proxmoxa, która sama zaleca piątkę, gdy w maszynie działa inny backup oparty na VSS. Po zmianie backup maszyny zostawia w backupset wiersz ze snapshotu z is_copy_only = 1, kopia różnicowa przechodzi, a baza w kopii maszyny jest spójna.
Kolejność ma znaczenie: najpierw klucz w rejestrze, dopiero potem włączenie SQL Writera. Odwrotnie – i jedna noc wystarczy, żeby znowu powstała niewidzialna pełna kopia. W moim laboratorium (Windows Server 2022, virtio-win 0.1.285) wynik był poprawny przy pierwszym backupie po zmianie, bez restartu usług agenta. Docelowo na produkcji włączam SQL Writera z VssOption = 5: kopia maszyny ma wtedy spójną bazę, łańcuch zostaje nietknięty, a w historii kopii co noc widać dowód, że backup maszyny się wykonał.
Pułapka aktualizacji i jedno zapytanie kontrolne
Każda z tych napraw działa do najbliższej aktualizacji, po której nikt jej nie sprawdzi. Aktualizacja SQL Servera instaluje komponent SQL Writera na nowo – u mnie po naprawie już dwa razy, w tym raz razem z Windows Update. Stan usługi się wtedy nie zmienił, ale dwa razy to żadna gwarancja przy trzecim. Groźniejsza jest druga pułapka: instalator agenta z pakietu virtio-win ustawia VssOption na 1. O aktualizacji SQL Servera dowiesz się z Windows Update, o nowej wersji sterowników VirtIO nie powie Ci nikt.
Dlatego po każdej aktualizacji SQL Servera i agenta QEMU puszczam jedno zapytanie. Zero wierszy przy wyłączonym SQL Writerze albo wiersze z is_copy_only = 1 przy VssOption = 5 to dobra wiadomość. Alarmem jest każdy wiersz ze snapshotu z is_copy_only = 0:
SELECT database_name, backup_start_date, is_copy_only, user_name
FROM msdb.dbo.backupset
WHERE is_snapshot = 1
AND backup_start_date >= DATEADD(DAY, -7, GETDATE())
ORDER BY backup_start_date DESC;
O nowych wersjach sterowników możesz dowiadywać się na trzech poziomach: ad hoc, czyli zwykle wtedy, gdy coś już przestało działać; z kalendarza – raz w miesiącu stały wpis: sprawdzić wersję, przeczytać listę zmian, zdecydować; albo automatem, który obserwuje stronę z wydaniami i sam daje znać. Do drugiego poziomu nie potrzeba żadnego narzędzia, wystarczy kalendarz.
Test odtwarzania, który sprawdza datę
Najważniejsza lekcja z tej historii: sukces odtworzenia nie mówi, z kiedy są dane. Test odtwarzania musi sprawdzać nie tylko, czy restore przeszedł, ale też jak stara jest kopia, którą odtworzył. Przy kopiach różnicowych co cztery godziny wiek powyżej pięciu godzin to alarm – nawet jeśli wszystko świeci na zielono. Wiek odczytasz z tabeli restorehistory na serwerze, na którym odtwarzasz kopie:
SELECT rh.restore_date, bs.backup_start_date,
DATEDIFF(MINUTE, bs.backup_start_date, rh.restore_date) AS wiek_min
FROM msdb.dbo.restorehistory rh
JOIN msdb.dbo.backupset bs ON bs.backup_set_id = rh.backup_set_id
WHERE rh.restore_type = 'I'
AND rh.restore_date >= DATEADD(DAY, -1, GETDATE())
ORDER BY rh.restore_date;
Obie kontrole – po aktualizacji i wiek kopii – działają tylko wtedy, gdy są spisane: co sprawdzić, jakim zapytaniem i jaki wynik jest alarmem. Spisana procedura zadziała także wtedy, gdy wykona ją ktoś inny, i nie odejdzie z firmy razem z pracownikiem.
NIS2: nie narzędzie, tylko odtwarzalność
Dyrektywa NIS2 w art. 21 ust. 2 lit. c wymienia wśród obowiązkowych środków ciągłość działania, w tym zarządzanie kopiami zapasowymi i przywracanie normalnego działania po sytuacji nadzwyczajnej. Nie mówi, jaką techniką ani jakim narzędziem robić kopie – płatnym czy darmowym. Trzeba za to znać mocne i słabe strony tego, czego używasz.
Ta sama dyrektywa w lit. e wymienia postępowanie w przypadku podatności, więc „zamrożenie” sterowników na zawsze, żeby nic nie zepsuć, nie wchodzi w grę. Aktualizować trzeba – i dlatego kontrola po aktualizacji jest stałym krokiem procedury, a nie jednorazową naprawą. Jedynym dowodem odtwarzalności jest odtworzenie, z datą.
Jeśli to nie Ty konfigurujesz: dwa pytania do informatyka
Jeśli prowadzisz firmę i to Ty czytasz rano raporty, nie musisz znać tabel msdb. Wystarczą dwa pytania, na które powinna paść odpowiedź z datą albo liczbą, a nie „mamy backup”.
„Skąd wiesz, że raport, który czytam rano, ma dzisiejsze dane?” Dobra odpowiedź to konkretna kontrola, która alarmuje, gdy dane są starsze, niż powinny.
„Kiedy ostatnio odtworzyłeś naszą bazę z kopii – i z którego dnia były dane po odtworzeniu?” Jeśli pada tylko data odtworzenia, bez daty danych, masz temat na najbliższe spotkanie z IT.
Częste błędy i pułapki
Uznanie zielonego restore za dowód. Odtworzenie pełnej plus najmłodszej różnicowej z katalogu przechodzi bez błędu także wtedy, gdy różnicowa jest sprzed kilku dni. Mierz wiek odtworzonej kopii i ustaw próg alarmu.
Przesunięcie godziny backupu PBS jako „naprawa”. To pierwszy odruch i częsta rada na forach. SQL Writer podmieni plik bazowy o każdej porze – godzina zmienia tylko to, kiedy się o tym dowiesz.
Wyłączenie agenta QEMU albo zamrażania systemu plików. Łańcuch kopii SQL przestanie się zrywać, ale kopia całej maszyny staje się kopią jak po wyrwaniu wtyczki – dla wszystkich aplikacji, nie tylko dla bazy. To zmiana na poziomie całej maszyny, nie naprawa problemu z bazą.
Włączenie SQL Writera przed ustawieniem VssOption. Jeśli nocny backup trafi pomiędzy oba kroki, powstanie kolejna niewidzialna pełna kopia. Najpierw klucz w rejestrze, potem usługa.
Brak kontroli po aktualizacji. Aktualizacja SQL Servera instaluje SQL Writera na nowo, a instalator virtio-win ustawia VssOption na 1. Po każdej z nich: stan usługi, wartość klucza i następnego dnia zapytanie kontrolne.
Zapytanie „od północy” z ostrą nierównością. Kopia startująca dokładnie o 00:00:00 wypada z wyniku warunku backup_start_date > CAST(GETDATE() AS date) i daje fałszywy alarm o brakującej kopii. W warunkach dnia zawsze >=.
Ręczna pełna kopia „na chwilę” bez copy only. Kopia na serwer testowy albo przed aktualizacją systemu, zrobiona zwykłym pełnym backupem, podmienia plik bazowy tak samo jak backup maszyny. Pole „Copy-only backup” w SSMS albo WITH COPY_ONLY w poleceniu.
Uogólnianie wyniku jednego laboratorium. Różnica między Windows Server a Windows 10 i 11 dotyczy wersji, które testowałem. Inna wersja agenta albo systemu może zachować się inaczej – sprawdź na swojej maszynie testowej, zanim zmienisz produkcję.
FAQ — najczęściej zadawane pytania
Czy backup Proxmoxa wystarczy do ochrony bazy SQL Server?
Kopia całej maszyny chroni system, konfigurację i aplikacje, ale nie zastąpi łańcucha kopii SQL Servera, który pozwala odtworzyć bazę do konkretnej minuty. Na Windows 10 i 11 w moim laboratorium baza w kopii maszyny nie była nawet potwierdzona przez SQL Server. Najbezpieczniej traktować oba backupy jako dwie warstwy i pilnować, żeby się nie wykluczały.
Dlaczego po backupie Proxmoxa kopia różnicowa kończy się błędem 3035?
Bo backup maszyny przez agenta QEMU, VSS i SQL Writera zapisał w SQL Serverze pełną kopię bez copy only, która podmieniła plik bazowy kopii różnicowych. Komunikat mówi o braku aktualnej pełnej kopii, choć w historii kopii widać wpis ze snapshotu. Sprawdź tabelę msdb.dbo.backupset: wiersz z is_snapshot = 1 i is_copy_only = 0 to ten winowajca.
Co to jest VssOption i gdzie go ustawić?
To wartość w rejestrze Windows, w kluczu HKLM\SYSTEM\CurrentControlSet\Services\QEMU Guest Agent VSS Provider, która decyduje, o jaki typ kopii agent QEMU prosi VSS. Wartość 1 oznacza pełną kopię i ustawia ją instalator, wartość 5 – kopię typu copy only. Opcja działa od virtio-win 0.1.262.
Czy po zmianie VssOption trzeba restartować agenta QEMU?
W moim laboratorium (Windows Server 2022, virtio-win 0.1.285) nie: pierwszy backup maszyny po zmianie zostawił już wpis z is_copy_only = 1. Przy innej wersji agenta sprawdź wynik pierwszego backupu po zmianie, zanim uznasz konfigurację za działającą.
Jak sprawdzić, czy backup maszyny psuje łańcuch kopii SQL?
Uruchom w SSMS zapytanie o wpisy ze snapshotu w msdb.dbo.backupset z ostatnich 7 dni. Brak wierszy oznacza, że backup maszyny nie uczestniczy w łańcuchu. Wiersze z is_copy_only = 1 są w porządku, a każdy wiersz z is_copy_only = 0 oznacza, że plik bazowy kopii różnicowych został podmieniony.
Czy wyłączenie SQL Writera jest bezpieczne?
Dla łańcucha kopii SQL tak – przestaje być zrywany. Ceną jest to, że baza w kopii całej maszyny jest w stanie jak po nagłym wyłączeniu zasilania i po odtworzeniu przejdzie standardowe odzyskiwanie. Spójną kopię bazy w kopii maszyny i nietknięty łańcuch daje dopiero VssOption = 5 przy włączonym SQL Writerze.
Czy przesunięcie godziny backupu PBS rozwiązuje problem?
Nie. Pełna kopia bez copy only podmienia plik bazowy niezależnie od godziny. Zmiana pory backupu przesuwa tylko moment, w którym zaczną się błędy kopii różnicowych.
Czy dane były zagrożone, skoro łańcuch kopii był zerwany?
Nie. Pełna kopia bez copy only nie przerywa łańcucha kopii dziennika transakcji, a kopie dziennika powstawały co 15 minut przez cały czas. Z pełnej kopii sprzed snapshotu i kopii dziennika dało się odtworzyć bazę do dowolnej minuty. Zepsuła się tylko droga na skróty przez kopie różnicowe.
Co NIS2 mówi o kopiach zapasowych?
Art. 21 ust. 2 lit. c dyrektywy NIS2 wymienia ciągłość działania, w tym zarządzanie kopiami zapasowymi i przywracanie działania po sytuacji nadzwyczajnej. Dyrektywa nie wskazuje techniki ani narzędzia. Liczy się to, czy potrafisz odtworzyć dane i wykazać to odtworzeniem – z datą.
Co dalej — film i kolejne odcinki
Cały mechanizm – backup maszyny w laboratorium, wpis w msdb, błąd 3035, restore ze starymi danymi i obie naprawy – zobaczysz w odcinku na kanale: SQL Server Backup na Proxmox – 10 nocy zerwanych kopii, a restore zielony z danymi sprzed 68 h. Zapytania do msdb z wartościami z odcinka, procedurę VssOption = 5 z kontrolą po aktualizacjach, laboratorium krok po kroku i checklistę „5 pytań o kopie zapasowe” dla właściciela firmy znajdziesz w materiałach do odcinka na Patronite, już od 4 zł miesięcznie.
W następnym odcinku zajmę się routerem: lista ostrzeżeń CERT Polska, ponad 120 tysięcy niebezpiecznych domen, zablokowana w całej sieci przez nowy RouterOS, i porównanie z darmowym Pi-hole. Niebawem wrócę też do baz: jak sprawić, żeby serwer sam dał znać, że kopia padła o czwartej rano. Jeśli takie tematy – serwery, kopie zapasowe i bezpieczeństwo infrastruktury od strony praktyka – są Ci bliskie, subskrybuj kanał Praktycznie o informatyce.