Alternatywy dla Network Backup

W naszym środowisku mamy kilka serwerów należących do grupy Always On Availability Group, a niektóre są samodzielne.

Zwykle tworzymy kopie zapasowe w udziale sieciowym, ale ostatnio zauważyliśmy, że wraz z powiększaniem się baz danych czas ten wydłuża się, co spowalnia całą sieć.

Skrypt Ola Hallengren jest używany do kompresji, a także do dzielenia plików kopii zapasowych. Wykonuję tylko codzienne „pełne” kopie zapasowe. Kopie zapasowe są przesyłane do dysku sieciowego EMC isilon drive.

Nigdy nie czuję się dobrze z EMC DD Boost. Jedyną alternatywą jest wykonanie lokalnej kopii zapasowej, a następnie skopiowanie do tego samego udziału sieciowego.

Czy istnieje skuteczny sposób inny niż powyższy?

Podana przez ciebie alternatywa wydaje się najlepszym wyborem.

Co możesz zrobić, to dwuetapowy proces:

• Wykonuj kopie zapasowe natywnego serwera SQL z kompresją, korzystając z lokalnego rozwiązania do tworzenia kopii zapasowych Oli.
• Użyj Robocopy, aby wykonać transfer do udziału sieciowego. Jest to oddzielone i może działać jako zaplanowane zadanie systemu Windows.

W ten sposób kopie zapasowe są lokalne i będą szybkie. Będziesz potrzebował więcej miejsca na dysku i oczywiście nadmiarowości (co, jeśli dysk zapasowy ulegnie awarii - nie chcesz stracić wszystkich kopii zapasowych).

Alternatywnie, zgodnie z zaleceniem Maxa Vernona, wykonaj Robocopy jako krok w zadaniu tworzenia kopii zapasowej, aby upewnić się, że robocopy wystąpi tylko wtedy, gdy tworzenie kopii zapasowej zakończy się powodzeniem, i jak najszybciej po zakończeniu tworzenia kopii zapasowej. Kopia zapasowa narażona jest na takie samo ryzyko jak dane, o ile pozostaje lokalna.

Ponadto regularnie testuj przywrócone dane, ponieważ jeśli nie możesz przywrócić kopii zapasowej - w jakim celu!

Zapoznaj się także z moją odpowiedzią na temat dostrajania dużych baz danych SQL Backup

Istnieją sposoby dostrojenia kopii zapasowych przez bałagan za pomocą różnych pokręteł, takich jak MAXTRANSFERSIZE lub BUFFERCOUNT , lub przez usunięcie pliku (co zauważyłeś, że już robisz).

Problem polega na tym, że dotknięcie tych pokręteł może nadal powodować przekroczenie limitów sieci i / lub pamięci masowej oraz nie mieć rzeczywistego wpływu na czas tworzenia kopii zapasowej.

Pierwszym zadaniem powinno być przeprowadzenie analizy porównawczej miejsca do przechowywania kopii zapasowej przy użyciu Crystal Disk Mark lub DiskSpd . To da ci pojęcie o tym, jak szybko możesz oczekiwać, że zapisy będą najlepsze.

Następną rzeczą, którą musisz przetestować, są odczyty z dysków, z których tworzysz kopię zapasową. Jeśli uruchomisz kopię zapasową do NUL , możesz określić, ile czasu zajmuje tylko odczytanie kopii zapasowej, bez konieczności zapisywania jej na dysku.

Mając na uwadze obie te liczby, możesz zacząć zadzierać z innymi pokrętłami, aby zobaczyć, które z nich przybliżą Cię do nich bez względu na to, czy cel tworzenia kopii zapasowych jest lokalny czy sieciowy.

Kilka potencjalnych rozwiązań:

1. Przejście z pełnej tylko tygodniowej pełnej kopii zapasowej i nocnej różnicy może być łatwym rozwiązaniem.

2. Istnieje wiele parametrów związanych z wydajnością, które możesz dostosować w skryptach Oli, możesz je dostosować, aby uzyskać żądaną wydajność:

   • BlockSize
     Określ fizyczny rozmiar bloku w bajtach.

     Opcja BlockSize w DatabaseBackup korzysta z BLOCKSIZEopcji polecenia SQL Server BACKUP.

   • BufferCount
     Określ liczbę buforów we / wy, które będą używane podczas operacji tworzenia kopii zapasowej.

     Opcja BufferCount w DatabaseBackup korzysta z BUFFERCOUNTopcji BACKUPpolecenia SQL Server .

   • MaxTransferSize Określ największą w bajtach jednostkę transferu, która ma być używana między programem SQL Server a nośnikiem kopii zapasowej.

     Opcja MaxTransferSize w DatabaseBackup korzysta z MAXTRANSFERSIZEopcji BACKUPpolecenia SQL Server .

Istnieje wiele możliwych opcji, ale ponieważ bazy danych stają się większe, a pełne tworzenie kopii zapasowych trwa dłużej, prawdopodobnie będziesz musiał uwzględnić różnicowe kopie zapasowe , jeśli jeszcze tego nie zrobiłeś:

Tworzenie różnicowych kopii zapasowych może być bardzo szybkie w porównaniu do tworzenia pełnej kopii zapasowej. Różnicowa kopia zapasowa rejestruje tylko dane, które uległy zmianie od czasu utworzenia pełnej kopii zapasowej po różnicowej kopii zapasowej. Ułatwia to częste tworzenie kopii zapasowych danych, co zmniejsza ryzyko utraty danych.

Rozumiem, że skrypty Oli można ustawić tak, aby decydowały między pełną lub różnicową kopią zapasową na podstawie ilości zmian w bazie danych za pomocą parametru ModificationLevel .

Korzystamy z EMC DD Boost i jesteście mile widziani na ten temat, ale odkryliśmy, że dzięki stosowanym przez klienta metodom duplikacji, pełne kopie zapasowe nawet baz danych o wielu TB mogą być bardzo szybkie, do tego stopnia, że ​​nie musimy się martwić różnicowymi kopiami zapasowymi programu SQL Server. W efekcie za pomocą EMC DD Ci się robi różnicowych kopii zapasowych, tylko nie w SQL Server. Korzystanie z wielu plików docelowych znacznie poprawia prędkość, nawet w DDBoost.