Utrzymywanie (częściowych) kopii zapasowych małych podczas korzystania z SQL Server FILESTREAM

Mam bazę danych zawierającą prawie 1 TB FILESTREAMdanych, których nie muszę tworzyć kopii zapasowej (jeśli dane zostaną usunięte, zostaną automatycznie odtworzone za kilka godzin, więc nie jest to ważne). Większość danych zmienia się co kilka dni, więc różnicowe kopie zapasowe nie pomogłyby w zmniejszeniu rozmiaru.

Kopie zapasowe działały tak, jak potrzebowałem, ustawiając tryb odzyskiwania na Full, tworząc osobne FILEGROUPdla FILESTREAM, a następnie wykonując kopie zapasowe tylko „głównej” FILEGROUP. Problem ten spowodował, że plik dziennika (który również jest tworzony), jest teraz niepotrzebnie duży, ponieważ zawiera FILESTREAMdane.

SIMPLETryb odzyskiwania pozbawia mnie możliwości wykonywania kopii zapasowych określonych FILEGROUPs, więc nie sądzę, że będzie to również opcja.

Moje myśli to po prostu przeniesienie FILESTREAMdanych do osobnej bazy danych, ale teraz tracę spójność referencyjną i na pewno dziedziczę wiele innych problemów.

Czy jest jakiś sposób na tworzenie częściowych kopii zapasowych w Simpletrybie odzyskiwania (bez ustawiania w FILESTREAMtabeli tylko do odczytu)? Jeśli nie, czy są jakieś inne rozsądne rozwiązania mojego problemu?

Problem ten spowodował, że plik dziennika (który również jest tworzony kopii zapasowej) jest teraz niepotrzebnie duży, ponieważ zawiera dane FILESTREAM.

Nie jestem pewien, czy masz na myśli, że sam plik dziennika jest zbyt duży lub czy kopie zapasowe pliku dziennika stają się zbyt duże.

Jeśli to ten pierwszy, to jak często tworzyłeś kopię zapasową? W zależności od projektu aplikacji możesz zmniejszyć rozmiar, wykonując kopie zapasowe częściej (a co 5 minut nie jest zbyt często). Jeśli jednak już to robiłeś, a balon wciąż się balonuwał, prawdopodobnie nie masz szczęścia. Dlaczego duży plik dziennika ponownie stanowi problem?

Jeśli to drugie - brzmiało to tak, jakbyś był zadowolony z kontynuowania prostego modelu odzyskiwania i nie ma sensu przywracać, jeśli pozwoli ci to na tworzenie mniejszych kopii zapasowych; w takim przypadku pozostań w trybie pełnym i odrzuć kopie zapasowe dziennika.

Rozwiązaniem dla bazy danych ustawionej na tryb odzyskiwania SIMPLE jest posiadanie danych FILESTREAM w grupie plików tylko do odczytu (co nie jest idealną opcją), a następnie tworzenie kopii zapasowych tylko grup plików do odczytu / zapisu przy użyciu DIFFERENTIAL w następujący sposób:

BACKUP DATABASE [name] READ_WRITE_FILEGROUPS TO DISK = '' WITH DIFFERENTIAL, COMPRESSION;

Otrzyma wszelkie dane, które zmieniły się w dowolnych aplikacjach do odczytu / zapisu. Jest to najłatwiejszy, od razu po wyjęciu z pudełka, że ​​możesz utrzymywać częściowe kopie zapasowe w zarządzaniu bez uzyskiwania danych FILESTREAM. Wymagałoby to jednak, aby proces ładowania wyżej wymienionych danych musiał zmodyfikować grupa plików do odczytu / zapisu, załadować dodatkowe dane, a następnie ustawić ponownie tylko do odczytu. Z pewnością nie idealny.

Czuję się brudny, podając to jako opcję, ale jeśli zdecydujesz się segregować dane FILESTREAM do własnej bazy danych, możesz zachować RI między tabelami w oddzielnych plikach db za pomocą wyzwalaczy :

Wyzwalacze -> Uwagi -> Ograniczenia:
Wyzwalacz jest tworzony tylko w bieżącej bazie danych; wyzwalacz może jednak odwoływać się do obiektów poza bieżącą bazą danych.

Spodziewaj się problemów z wydajnością i części skóry głowy, która stanie się pozbawiona włosów po frustracji wyciągając kępki futra głowy, ale teoretycznie możesz to zrobić. Nie polecam tego podejścia na żadnym poziomie, zamiast tego zdecydowanie zalecam zwiększenie częstotliwości tworzenia kopii zapasowych tlog i / lub przejście do modelu odzyskiwania z logowaniem zbiorczym i sprawdzenie, ile miejsca oszczędza, ALE to możliwe rozwiązanie. Naprawdę trzeba rozważyć korzyści wynikające z oddzielenia tych danych i radzenia sobie z projektem bazy danych Frankensteina, ale jest to opcja.

... muszę teraz wziąć prysznic ...

Wiem, że na to pytanie już udzielono odpowiedzi, ale istnieje inne rozwiązanie, które może pomóc innym. Niedawno dowiedziałem się z bloga Brenta Ozara, że istnieje możliwość natychmiastowego odrzucenia kopii zapasowych dziennika:

BACKUP LOG MyDb TO DISK='NUL:'

Możesz więc pozostawić bazę danych w Fulltrybie odzyskiwania i wykonywać kopie zapasowe aplikacjami. Gdy dziennik transakcji staje się zbyt duży, po prostu wydaj polecenie tworzenia kopii zapasowej dziennika i gotowe.