GoldenLine
Zaloguj się
Paweł K.

Paweł K. inż.sys. spec ds
wdrożeń

Temat: MSSQL Full Backup

Witam,

Chciałbym zapytać o możliwości / techniki / podpowiedzi odnośnie robienia backupów.

Mam kilka baz danych przekraczających 1TB i spory problem z pełnym backupem.
Często zdarza się, że ww backup trwa zbyt długo - rząd wielkości 2MB/s (niestety wygląda to tak, że backup w kolejce do zasobów jest na szarym końcu) co przy dużych bazach trwa wieki i jest nie do zaakceptowania.
Wyłączenie wszystkiego nie wchodzi w grę.
Jak narazie mam już zajęty cały tydzień schedulerem i backupami poszczególnych baz - różne dni nie przytykają mi serwera na który są robione backupy.
Problem rodzi się gdy jeden z backupów trwa zbyt długo i następny już sie zaczyna wykonywać - wtedy zaczyna dochodzić do sytuacji kiedy to nie sam "sql" jest zbyt wolny ale server na którym backup ma być zapisany lub druga baza z tego samego serwera ma mieć robioną kopię.

z technicznego pnt.
sieć lan gigabit,
servery na raidach 5,
bardzo (bardzo bardzo zajęte z reguły - kolejki na dyskach często przekraczają granicę zdrowego rozsądku nie wspominająco wytycznych MS-a), ale to jest po częsci odrębny temat,
nie wszystkie serwery niestety posiadają osobne dyski na tempbd,
bazy są na lokalnych dyskach serwera,
backupy są na lokalnych dyskach serwera (tylko i wyłącznie na backup),
dyski min 10k - różne wielkośći
kontrolery prawie wszystkie hp p410 - bez dodatkowej pamieci,
Większość baz danych w simple recovery mode (niestety...ale full i backup logow też miał czasem przygody ze zbyt długim czasem realizacji),
prawie wszystkie db są na "jednym pliku",

I tu moja gorąca prośba i pytanie do ekspertów (zakładając, że korzystam tylko w produktów MS) jak można usprawnić proces tworzenia backupów.
Na co zwrócić uwagę i w miarę możliwości próbować poprawić wydajność dysków.
W idealnym Świecie dążyłbym do modelu full backup + logi + raz na tydzień pełny.

z góry dziękuję za pomoc.
paweł
Link do wypowiedziLink
Paweł Parzych

Paweł Parzych Starszy Programista
Delphi/MSSQL

Temat: MSSQL Full Backup

Osobiście sugerowałbym raczej zastanowić się nad obcinką części niepotrzebnych danych aby zmniejszyć rozmiar bazy roboczej (jeśli oczywiście dane, które są tam przechowywane na to pozwolą) - zwiększy to zapewne wydajność całego systemu i problem z backupami się rozwiąże zapewne.

Pozdrawiam
Paweł Parzych
Link do wypowiedziLink
Marcin Mackiewicz

Marcin Mackiewicz Programista JAVA, RS
Adware Polska

Temat: MSSQL Full Backup

Skromnie podrzucam pomysł z wdrożeniem replikacji. Dane będą powielane na oddzielnym serwerze na bieżąco i wtedy kopie nocne można by robić na okrągło z serwera slave. Niestety w MSSQL się nie specjalizuję ale zakładam, że mechanizm replikacji posiada. Przy replikacji pojawiają się oczywiście inne zagadnienia i problemy ale rozwiązanie powinno pomóc utrzymać bazę na ruchu w momencie tworzenia kopii i nie obciąży serwera master.
Link do wypowiedziLink
Paweł B.

Paweł B. architekt baz danych
/ SQL Developer /BI
Developer

Temat: MSSQL Full Backup

Koniecznie zajmij się kolejkami dysków.
Masz kilka serwerów SQL i kilka baz z których każda przekracza 1TB czy to łączny rozmiar?
Polityka backupu: Kopie codzienne, ile kopii wstecz potrzebujesz? Jak często robisz restore?
Sprawdź, czy rozmiary baz odpowiadają rozmiarom danych w nich przechowywanych.

Rozważ:
Włączenie kompresji backupu,
Partycjonowanie danych lub inny sposób zmniejszenia rozmiaru danych do backupu jak to napisał już Paweł P.
Jeśli na jednym serwerze masz kilka baz do backupu wykonuj je w jednym jobie - unikniesz konfliktów.
Backup tylko na dysk lokalny i JEDNO robocopy cyklicznie zbierające je na udział sieciowy.
Link do wypowiedziLink
Paweł K.

Paweł K. inż.sys. spec ds
wdrożeń

Temat: MSSQL Full Backup

Witam,

Na razie nie jestem w stanie zrobić "miroringu". Brka możliwości technicznych :) - czytaj brak serwerów.

Probematyczna lokalizacja ma 2 serwery sql-a (nie wspominałem wcześniej 64gb ram i 96gb).
Na obu łącznie ponad 6TB baz danych z czego 3 przekraczają 1 TB (mniej więcej po połowie na każdy).

Co do kompresji - już jest włączona dla każdego backupu (jest jakaś możliwość "manipulacji" gdzie ta kompresja się odbywa? tzn backup -kompresja-wysyłka danych lub backup-wysyłka-kompresja?).

Na dzień dzisiejszy niestety nie mogę sobie pozwolić na codzienne backupy.
Raz w tygodniu pełen i w zasadzie tylko jeden jest mi potrzebny (docelowo będą to minumum dwa na wypadek corrupcji + logi- większość danych jestem w stanie zebrać jeszcze raz - ot nie będą dostępne od razu - akceptuje taki scenariusz). Docelowo mam zamiar wdrożyć Full model, raz w tygodniu pełen + logi transakcyjne raz/dwa razy dziennie.
Na szczęscie nie miałem jeszcze konieczności restore'a od długiego czasu ... tutaj obawa jest, że statystyka się o mnie upomni wcześniej czy później :)
Dane odpowiadają ilości tych na dysku (raz się tylko tak zdarzyło).
Z odcinką spróbuje coś zrobić - tutaj jest spore pole do popisu - sporo tabel tymczasowych - niestety zdaża się, że są one długo wykorzystywane (pare dni) więc łatwo nie będzie.

Co do samego backupu. Zobacze jak pójdzie z zrzutem na lokalny dysk i dopiero potem na osobny serwer.
Czy, aż tak duża różnica jest orzy lokalnych dyskach w porównaniu z sieciową lokalizacją (ta sama podiseć 1gbps)

Dziękuję za udział w dyskusji.

paweł
Link do wypowiedziLink
Marcin S.

Marcin S. Professional SQL
Server Administrator

Temat: MSSQL Full Backup

Transfer podczas backupu 2MB/s na lokalny dysk to stanowczo za mało. Analizę problemu rozpocząłbym od weryfikacji konfiguracji dysków serwera. RAID 5 nie nadaje się do stosowania w serwerach bazodanowych, ponieważ zwiększa czasy zapisów, zarówno do bazy jak i podczas tworzenia backupów. Lepiej korzystać z RAID 1, bądź 0+1. Jak sformatowane są partycje? Najmniejszą jednostką, którą SQL SERVER alokuje w plikach danych na dysku jest zakres o rozmiarze 64 KB czyli 8 stron po 8 kilobajtów - taki powinien być rozmiar klastra na partycji NTFS. Zwrócić należy również uwagę na rozmiar rozrostu plików baz danych. Domyślnie w SQL Server pliki danych rozrastają się o 1 MB, a loga o 10%, co powoduje dużą fragmentację fizyczną plików na dysku. Zalecane ustawienie rozrostu plików dla dużych baz to 512 MB, bądź 1GB. Microsoft zaleca również, żeby pliki danych, log oraz tempdb trzymać na oddzielnych partycjach, bądź dyskach np. MDF i NDF na partycji E:, LDFy na partycji F:, pliki bazy tempdb G:.
Kompresja dodatkowo wydłuża czas robienia się backupu, więc jeżeli nie zależy Ci na miejscu, to możesz z niej zrezygnować. Nie można manipulować w żaden sposób procesem kompresji. Ale jest włączony, albo nie.
Jeżeli bazy masz w Simple Recovery Model, to nie zrobisz im backupu LOGA, ponieważ po zakomitowaniu transakcji log czyści się samoistnie.
Standardowy harmonogram backupów możesz ustawić następująco
* raz na tydzień FULL,
* raz na dzień DIFFERENTIAL,
* LOG co 2 godziny w godzinach pracy użytkowników systemu np. pomiędzy 7:00 a 17:00.

Może ustawić harmonogram w taki sposób, że każdego dnia będzie Ci się robił jeden Full backup, ale zawsze innej bazy. Powinno to rozwiązać problem z zazębianiem się okienek.

Zweryfikuj powyższe ustawienia u Ciebie na serwerach i spróbuj ustawić je zgodnie z dobrymi praktykami SQL Server.Ten post został edytowany przez Autora dnia 10.07.15 o godzinie 23:35
Link do wypowiedziLink
Daniel W.

Daniel W. Architekt ;)

Temat: MSSQL Full Backup

Twoje środowisko dąży do katastrofy.
Twój problem z backup to wynik przede wszystkim słabego podsystemu dyskowego.
A może nam powiesz jakie dyski masz i ile ich jest.
Jeśli nie poprawisz I/O to możesz zapomnieć o replikacji backup itp. rzeczach.
Mam nadzieje, tylko że któregoś ranka nie obudzisz się i zobaczysz, że jest już po tzw. jabłkach - czego ci osobiście nie życzę.
Tak jak piszą koledzy - popraw I/O
Link do wypowiedziLink
Paweł K.

Paweł K. inż.sys. spec ds
wdrożeń

Temat: MSSQL Full Backup

Witam,

Przyrost mam juz ustawiony nawet więcej niż sugeruje Marcin - średnio jest to 5GB na dane i 0.5GB na loga.

Dyski - 10 i 15 k oraz 1tb lub 2tb - mowie tylko o dyskach związanych z db.
Tempdb jest na raid 1 osobna partycja.

Data jest na raid 5 - tu moje pytanie czy zmiana na raid 1 znacznie podniesie wydajnosc dyskow w korelacji z sql-em?

Warto zauważyć, że stosunek zapis / odczyt mam ~ 1 zapis - 10 odczytów więc chyba raid5 tu się bardziej sprawdza.

pozdrawiam,
pawelTen post został edytowany przez Autora dnia 14.07.15 o godzinie 12:29
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

[postgres] backup i restore




Wyślij zaproszenie do
Anuluj