Czym różnią się kopie zapasowe SQL od zwykłych nocnych kopii zapasowych IT IT?

Nasz dział IT tworzy kopie zapasowe całego serwera co noc (instancja SQL Server jest instalowana na tym serwerze), która powinna tworzyć kopię zapasową tego serwera, a także całej sieci, na wypadek, gdyby coś poszło nie tak ...

Więc mój menedżer zapytał, co jest znaczące dla moich pełnych, różnicowych i logicznych kopii zapasowych w porównaniu z tym, co tworzy kopię zapasową działu IT? Uważa, że ​​aby zaoszczędzić więcej miejsca na naszym serwerze, a nie przechowywać tych plików przez kilka tygodni i usuwać je, IT je zapewni!

Wiem, że to nie w porządku, ponieważ mogę przywracać kopie zapasowe dziennika do ostatnich 30 minut, IT przywraca je następnego dnia, ale czy to jedyna różnica?

Ponieważ zapisuję / wysyłam pliki kopii zapasowej bazy danych na ten sam serwer, IT je przywróci, ale jeśli nie mam tych zadań tworzenia kopii zapasowych w moim planie konserwacji, IT może po prostu przywrócić instancję SQL bez żadnej z naszych tabel, transakcji ... itd. Czy mam rację?
Wszelkie porady będą mile widziane.

Kopie zapasowe bazy danych dają możliwość przywracania w określonym momencie (pod warunkiem posiadania FULLmodelu odzyskiwania). Nawet jeśli pracownicy działu IT wykonują kopie zapasowe co kilka minut, co jest bardzo mało prawdopodobne, nadal będziesz mieć lukę.

Kopie zapasowe serwera nie zastępują kopii zapasowych baz danych, lecz uzupełniają je poprzez „archiwizowanie” kopii zapasowych baz danych w perspektywie długoterminowej (tj. Więcej niż tylko dzisiaj).

Ostatecznie Ty i kierownictwo musicie zdecydować o RPO (cel punktu odzyskiwania - ile musisz być w stanie odzyskać w razie awarii). Dzięki codziennym kopiom zapasowym serwera i bez kopii zapasowych bazy danych możesz stracić cały dzień pracy w najgorszym przypadku.

Edycja : @Sting ma prawidłowy punkt w tym, że kopie w tle (mechanizm najprawdopodobniej wykorzystywany do tworzenia kopii zapasowych serwera) nie są w stanie pobrać dokładnie wszystkich kopii plików bazy danych (w tym plików dziennika), co może prowadzić do niespójności, gdy przywracasz kopię zapasową. Na przykład, jeśli kopia w tle czyta dziennik transakcji kilka milisekund przed odczytaniem pliku bazy danych, plik bazy danych może zawierać niezatwierdzoną transakcję, ale ponieważ transakcja została zatwierdzona milisekundę później, dziennik nie będzie zawierał żadnych zapisów.

Istnieje prawdopodobieństwo, że przywracanie plików mdf i ldf z kopii w tle będzie niespójne transakcyjnie. Oznacza to, że te przywracania cieni nie są zgodne z właściwościami ACID bazy danych.

https://msdn.microsoft.com/en-us/library/aa480356.aspx

Możliwe, że przywrócenie prawdopodobnie zadziała, ale będziesz się zastanawiać, co tak naprawdę otrzymujesz. (Nie wspominając o tym, że miałbyś za zadanie przetestować, czy kopie zapasowe / kopie w tle działają poprawnie na każdym serwerze). Ponadto nie ma możliwości przywrócenia dzienników transakcji do momentu, w którym można użyć SQL Server T -SQL RESTORE LOG / STOPAT.

Dopóki kopie zapasowe / przywracanie systemu Windows Server nie będą zgodne z testem ACID serwera SQL, nasza branża nie może sobie pozwolić na podejmowanie żadnych szans.

Powiedziawszy to wszystko, byłem na niektórych z najdziwniejszych spotkań. Jeśli przekażesz problemy IT, a one nadal wydają się nie przejmować lub chętnie zaryzykują, usunie to z twoich barków ogromne obciążenie. Cokolwiek się wydarzy, udokumentuj protokół spotkania, na podstawie którego wszyscy się zdecydują, i dlaczego wszyscy to postanowili, i wyślij go uczestnikom spotkania.

Wszystko zależy od tego, jakiego produktu używa Twój dział IT do tworzenia kopii zapasowych na poziomie serwera.

Na przykład w środowisku wirtualnym VMWare wykona migawki serwera. Jeśli zaangażowany jest SQL Server, VMWare ma opcję, którą włącza większość administratorów (lub może to być domyślnie nie wiem), która zamraża IO dla baz danych podczas migawki. Teraz, choć powinno to zająć tylko kilka sekund, możesz mieć problemy z aplikacją i nie jest to tak naprawdę zaufana metoda przywracania bazy danych.

Jeśli używasz produktu innej firmy do wykonywania kopii zapasowych na poziomie serwera, istnieje prawdopodobieństwo, że po prostu wykonujesz kopie zapasowe na poziomie plików z twoich baz danych. W tym również musi mieć możliwość wykonywania kopii zapasowych plików, które są zablokowane, ponieważ SQL Server ma wszystkie załączone pliki mdf i ldf zablokowane z perspektywy Windows. Na przykład BackupExec firmy Symantec wykorzystuje opcję Advanced Open File Option, aby wykonać tę czynność, dzięki czemu może w zasadzie zrobić zdjęcie tego zablokowanego pliku. Właśnie tak, jak dźwięki sprawią, że większość DBA zbankrutuje, jeśli trzeba przywrócić bazę danych za pomocą takiej kopii zapasowej, pomyśl o spójności bazy danych, gdy wykonuje tę kopię zapasową. Nie ma gwarancji, że jeśli kopia zapasowa zostanie uruchomiona, gdy trwa proces ładowania danych, to jaką część ładunku danych otrzymała ta kopia zapasowa?

Natywne kopie zapasowe SQL Server są godne zaufania, pod warunkiem, że są sprawdzone jako dobre kopie zapasowe. Wiesz dokładnie, w jakim były stanie, gdy uruchomiłeś kopię zapasową dla PEŁNEJ, czy masz to zaplanowane wokół ładowania danych i tym podobne. Kopia zapasowa dziennika dla FULL modelu odzyskiwania gwarantuje, że możesz przywrócić tę bazę danych w drugiej kolejności.

Jeśli Twój menedżer nie chce używać kopii zapasowej na poziomie serwera, dokładnie zbadam produkt, którego używają. Dowiedziałbym się, czy istnieje jakiś „dodatek” do programu SQL Server lub agent tworzenia kopii zapasowych, który można kupić, aby umożliwić wykonywanie kopii zapasowych VDI baz danych.

Należy również rozważyć i omówić ze swoim menedżerem to, jakie zaangażowanie musisz mieć przy weryfikacji i rozwiązywaniu problemów, jeśli nie uda się wykonać kopii zapasowych SQL Server. Używałem mocno Netbackup w poprzednich zadaniach i klient kilka lat temu chciał, żebym przetestował użycie agenta SQL Server Netbackup dla swojego środowiska. Obejmowało to inne DBA, które musiały również zapewniać wsparcie. Powiedziałem im z góry, że rozwiązywanie problemów z błędami tworzenia kopii zapasowych SQL Server wymaga dobrej znajomości Netbackup. Serwery główne Netbackup są generalnie uruchamiane na serwerach Unix, więc teraz musisz znać trochę Uniksa .... może być zabawą, ale bardziej uciążliwym, jeśli jesteś już zajęty. Tylko coś do rozważenia i może być dobrym punktem do dyskusji z menedżerem i dowiedzieć się, kto jest odpowiedzialny za rozwiązywanie problemów.

W twoim pytaniu jest tylko mniej niż milion zmiennych. Będziesz musiał porozmawiać z działem IT o tym, jakie kopie zapasowe wykonują. Najprawdopodobniej mają lub mogą mieć do minuty dostępne kopie zapasowe. Czas ładowania ich zależy od większej liczby zmiennych.

W idealnym scenariuszu dział IT utrzymuje kopie zapasowe na jednym lub kilku różnych serwerach w różnych lokalizacjach. Prawdopodobnie przechowujesz kopię zapasową na tym samym serwerze, na którym żyją bazy danych. Więc jeśli serwer umrze lub Twój budynek spali się, Twój dział IT prawdopodobnie może przywrócić twoje pliki, ale kopie zapasowe, które wykonałeś, znikną z serwerem.

ALE możesz przywrócić kopię zapasową z prędkością, kiedy tylko chcesz, pod warunkiem, że serwer nadal żyje.

Jak powiedzieli inni, zależy to od twoich potrzeb, twojej tolerancji na ryzyko i tego, jak ważna jest kontrola czasu powrotu do zdrowia. Jeśli chcesz odzyskać z czegoś głupiego, co zrobiłeś, kopie zapasowe będą szybsze i lepsze. Jeśli chcesz odzyskać system po awarii, na którą nie masz wpływu, tworzenie kopii zapasowych IT (powinno być) lepszym wyborem.