Инкрементное резервное копирование базы данных MSSQL / клон
Я пытаюсь сэкономить время на повторяющейся задаче, которую меня постоянно просят сделать.
У нас есть внутреннее приложение, которое мы назовем "App".
Это приложение имеет базу данных под названием "AppLive"
У нас есть "Test" экземпляр того же приложения, которое использует базу данных "AppTesting". Это так, чтобы мы могли выполнять тесты и т. Д., Не влияя на наши действующие данные.
Когда пользователи хотят начать играть с тестовым экземпляром приложения, меня просят "импортировать живые данные в тестовую базу данных". Им нужен самый последний набор оперативных данных из нашей базы данных AppLive, импортированных в базу данных AppTesting.
Мой текущий процесс таков:
Возьмите самую последнюю ночную полную резервную копию живой базы данных. Удалить тестовую базу данных "Восстановить" файл резервной копии AppLive в новую базу данных под названием AppTesting (то же имя, что и удаленная база данных).
Это дает нам самые последние ночные данные в тестовой базе данных.
Проблема в том, что база данных становится огромной. Это около 11 ГБ - и файлы резервных копий удаленно хранятся на диске NAS.
Поэтому мне нужно подождать 45 минут, чтобы перенести файл резервной копии базы данных на сервер SQL, а затем начать импорт. Который снова принимает абсолютный возраст.
Мое идеальное решение этого было бы:
Продолжайте делать мои ночные полные резервные копии базы данных AppLive (для наших обычных требований к резервному копированию) и для меня добавочного резервного копирования, сделанного в дополнение к этому - так, чтобы, когда мне нужно будет импортировать живые данные в нашу тестовую базу данных, мне не нужно играть с огромным файлом 11GB. В идеале я хотел бы иметь возможность сказать студии управления MSSQL "пожалуйста, обновите базу данных AppTest всеми новыми данными из AppLive" - хотя я не хочу, чтобы это было запланировано, тестовые данные должны оставаться статичными, пока нас не попросят обновить это с новыми данными.
Я надеюсь, что это достаточно ясно и что кто-то может указать мне правильное направление.
1 ответ
У вас есть несколько вариантов.
1) Напишите сценарий powershell или что-то для автоматизации восстановления. Это превращает его в огонь и забудь. Затем вы можете объединить это с запланированным запуском инструмента (скажем, по воскресеньям) в третью базу данных. Это будет означать, что вам нужно посидеть с потребителем тестовой базы данных, чтобы выяснить, какова его терпимость к устаревшим данным (т.е. насколько свежей должна быть база данных). Затем, когда приходит запрос на обновление данных, вы отбрасываете текущую тестовую базу данных, переименовываете восстановленную в копию (возможно, вы захотите переименовать и физические файлы), и все готово.
2) Журнал доставки
3) Зеркальное отображение базы данных.
Варианты 2 и 3 кажутся излишними для того, что вы пытаетесь достичь.