Зберігання (часткових) резервних копій невеликим під час використання FILESTREAM SQL Server

У мене база даних з майже 1 ТБ FILESTREAMданих, які мені не потребують резервного копіювання (якщо дані були видалені, вони будуть відтворені автоматично через пару годин, тому це просто не важливо). Більшість даних змінюються кожні пару днів, тому диференційне резервне копіювання не допоможе зменшити розмір.

У мене були резервні копії, як мені потрібно, встановивши режим відновлення Full, створивши окремий FILEGROUPдля FILESTREAM, потім зробивши резервні копії лише "первинного" FILEGROUP. Проблема, яку це спричинило, полягала в тому, що файл журналу (який також створюється резервна копія) тепер зайво великий, оскільки включає FILESTREAMдані.

SIMPLEРежим відновлення забирає мою можливість робити резервні копії конкретних FILEGROUPs, тому я також не думаю, що це буде також варіантом.

Мої думки полягають у тому, щоб просто перемістити FILESTREAMдані в окрему базу даних, але тепер я втрачаю референтну цілісність і, безумовно, успадковую також безліч інших питань.

Чи є спосіб створити часткові резервні копії у Simpleрежимі відновлення (не встановлюючи FILESTREAMтаблицю лише для читання)? Якщо ні, чи є інші розумні рішення моєї проблеми?

Проблема, яка була викликана цим, полягала в тому, що файл журналу (який також створюється резервна копія) тепер непотрібно великий, оскільки він містить дані FILESTREAM.

Я не впевнений, якщо ви маєте на увазі, що сам файл журналу занадто великий або резервні копії файлів журналу стають занадто великими.

Якщо це колишній, то як часто ви здійснювали резервне копіювання журналу? Залежно від дизайну програми, ви, можливо, зможете зменшити розмір, створюючи резервну копію частіше (і кожні 5 хвилин не надто часто). Однак якщо ви це вже робили, і це все-таки було на повітряній кулі, то вам, мабуть, не пощастило. Чому знову великий файл журналу?

Якщо це останнє - це звучало так, ніби ви раді продовжувати просту модель відновлення, і немає часу в процесі відновлення, якщо це дозволить зробити менші резервні копії; в такому випадку залишайтеся в повному режимі та відмовтесь від резервного копіювання журналу.

Рішення для бази даних, встановленої в режимі відновлення, SIMPLE - це використання даних FILESTREAM у групі файлів, доступних лише для читання (що не є вашим ідеальним варіантом), а потім резервне копіювання лише груп файлів для читання / запису з РІЗНИМИ таким чином:

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

Він отримає будь-які дані, що змінилися в будь-яких групах файлів для читання / запису. Це найпростіше, з цього вікна, що ви можете зберігати часткові резервні копії керованими, не отримуючи даних FILESTREAM. Однак потрібно вимагати, щоб процес завантаження вищезазначених даних потребував модифікації групи файлів для читання / запису, завантаження будь-яких додаткових даних та встановлення для читання лише знову. Звичайно, не ідеально.

Я відчуваю себе брудно, надаючи це як варіант, але якщо ви вирішите розділити дані FILESTREAM в свою власну базу даних, ви можете підтримувати RI між таблицями в окремих dbs за допомогою тригерів :

Тригери -> Зауваження -> Обмеження:
тригер створюється лише в поточній базі даних; однак тригер може посилатися на об'єкти поза поточною базою даних.

Очікуйте, що проблеми з роботою та частина вашої шкіри голови стануть без волосся, після того, як ви розчаруєте витягнуті пучки голови, але теоретично ви могли це зробити. Я не рекомендую такий підхід на будь-якому рівні, натомість я настійно пропоную вам збільшити частоту резервного копіювання та / або перейти на модель відновлення в масовому режимі та побачити, скільки місця економить, але це можливе рішення. Дійсно, вам знадобиться зважити перевагу відокремлення цих даних та роботи з франкенштейнівським дизайном баз даних, але це варіант.

... Я мушу зараз піти прийняти душ ...

Я знаю, що на це питання вже відповіли, але є ще одне рішення, яке може допомогти іншим. Нещодавно я дізнався з блогу Brent Ozar, що є можливість негайно відмовитись від резервного копіювання журналу:

BACKUP LOG MyDb TO DISK='NUL:'

Таким чином, ви можете залишити свою базу даних у Fullрежимі відновлення та зробити резервне копіювання файлових груп. Коли ваш журнал транзакцій стає занадто великим, тоді просто випустіть команду журналу резервного копіювання, і ви закінчите.