Paul Randal zadał kilka naprawdę fajnych pytań na temat najlepszych praktyk dotyczących baz danych SQL SharePoint. Dzisiaj, pomagając klientowi w utrzymaniu instalacji SharePoint, zadał mi pytanie dotyczące najlepszego modelu odzyskiwania SQL dla bazy danych SharePoint.
Moją praktyką (nie jestem administratorem DB :)))) jest używanie Prostego modelu odzyskiwania. Jeśli kopie zapasowe baz danych SharePoint są regularnie wykonywane, a Ty masz także narzędzie do tworzenia kopii zapasowych narzędzi innych firm na poziomie elementu, naprawdę nie musisz przechowywać całych dzienników.
Czy coś mi umyka? Czy to właściwe podejście? Czy kiedykolwiek korzystałeś z dziennika SharePoint DB do odzyskiwania danych?
sql-server
sharepoint
Toni Frankola
źródło
źródło
Utworzenie kopii zapasowej samej bazy danych NIE spowoduje uzyskania wszystkich informacji o punkcie udostępniania. Pewnie, że dostanie wszystko do bazy danych, ale wszystkie dostosowania oraz wygląd i styl zostaną utracone. Jako administrator może to nie mieć znaczenia, ale zapewniam, że użytkownicy będą niezadowoleni.
Opcje obejmują uzyskanie agenta kopii zapasowej, który może odczytać bazę danych sharepoint dla twojego oprogramowania do tworzenia kopii zapasowych, lub wykonanie kilku skryptowych kopii zapasowych, które przechwytują informacje o konfiguracji i umieszczają je, a także kopię zapasową bazy danych SQL w bezpiecznym miejscu.
http://technet.microsoft.com/en-us/library/cc288330.aspx Zawiera pewne informacje.
TESTuj swoje kopie zapasowe. Przywróć je. Zobacz, jakie zmiany, co działa, a co nie. Nasze pierwsze przywrócenie nie było tak dobre, jak mogłoby być. Na szczęście dla nas była to tylko część procesu tworzenia serwera testowego, który byłby duplikatem naszego serwera produkcyjnego, zamiast próby odzyskania utraconych lub zniszczonych danych.
Zredagowano pod kątem istotności Po ponownym przeczytaniu tego zdałem sobie sprawę, że byłem rozkojarzony i przegapiłem punkt odpowiedzi mojej odpowiedzi. Jeśli wykonujesz pełne kopie zapasowe z rejestrowaniem transakcji, możesz cofnąć się do znacznie drobniejszych punktów w czasie. To wymaga więcej umiejętności jako DBA, ale nie jest to takie trudne. Jeśli nie masz mnóstwo aktualizacji, a utrata pracy przez cały dzień nie jest końcem świata, prawdopodobnie nic ci nie jest. Inne opcje obejmują częstsze uruchamianie prostej kopii zapasowej. Powiedz Północ, 10 rano, 2 po południu, 18 po południu lub cokolwiek innego, co działa w cyklu pracy organizacji. Spowoduje to zjedzenie większej ilości dysku, ale zmniejszy ryzyko utraty danych. Podobnie jak w przypadku wszystkich kopii zapasowych, jest to równowaga między tym, co użytkownicy będą tolerować, a tym, co mogą zapewnić administratorzy.
źródło
Sharepoint musi być traktowany jak baza danych SQL, ponieważ JEST bazą danych SQL, więc zachowaj wszystkie standardowe środki ostrożności podczas konfiguracji sklepu. Jeśli chodzi o kopie zapasowe, powinieneś nie tylko regularnie tworzyć kopie zapasowe baz danych, ale musisz także wykonać kopię zapasową 12-gałęzi, która przechowuje wszystkie informacje SP.
Sprawdź ten wątek, aby uzyskać więcej informacji: http://social.technet.microsoft.com/Forums/en-US/sharepointgeneral/thread/102c5c71-38a3-4360-b5cb-9b8b7c07bfea
źródło
Istnieje kilka baz danych, które są ustawione na tryb prosty od razu po wyjęciu z pudełka. Baza danych wyszukiwania, na przykład. Dane wyszukiwania są przechowywane w dwóch lokalizacjach: bazie danych i pliku indeksu w systemie plików serwera. Obie muszą obsługiwać zapytania wyszukiwania, a obie kopie zapasowe tworzyły jednocześnie kopie zapasowe, aby każda przywrócona wersja działała. Ponieważ szanse na to są bardzo, bardzo niskie, większość osób zdecyduje się po prostu ponownie przeszukać zawartość i ponownie wygenerować indeks wyszukiwania.
W takim przypadku tryb prosty działałby dobrze.
źródło