Назад | Перейти на главную страницу

Резервное копирование журналов транзакций на ленту?

Я собираюсь перевести свою базу данных в модель полного восстановления и начать делать резервные копии журнала транзакций. Я делаю полную ночную резервную копию на другой сервер, а вечером этот файл и многие другие копируются на ленту.

У меня такой вопрос. Я буду делать ежечасные (или больше, если необходимо) резервные копии t-log и также хранить их на другом сервере. Однако, если мои полные резервные копии проходят проверку DBCC и целостности, нужно ли мне записывать журналы T-Log на ленту?

Если кто-то хочет восстановить момент времени до вчерашнего дня в 14:00, мне потребуется предыдущая полная резервная копия и журналы транзакций. Однако, если я знаю, что мои полные резервные копии хороши, кроме этого случая, есть ли смысл в хранении резервных копий журнала транзакций предыдущего дня?

Старые журналы могут быть полезны в определенных сценариях, например, если вы обнаружите, что вчера произошла некорректная операция обновления, и вам нужно восстановить данные, вы можете использовать восстановление на определенный момент времени старых полных и старых журналов, чтобы восстановить их до того момента, когда произошла ошибка. произошло обновление данных и скопируйте удаленные данные. В основном все, что требует изображения базы данных до последнего полного.

Предполагая, что у вас 100% уверенность в СМИ, т.е. последняя полная резервная копия на 100% будет доступна и будет восстановлена, более старые резервные копии журналов, чем самая последняя полная, не нужны. Решение о том, хранить их дольше или выбросить, будет определяться не требованиями восстановления, а требованиями политики сохранения истории и личным уровнем паранойи администратора баз данных.

Следует отметить, что резервные копии журналов старше последнего полного бесполезны без предварительного полного.

Лично я предпочитаю делать резервные копии данных и журналов транзакций на диск, а затем реплицировать их на другой набор дисков (в моем случае за пределами площадки). Это позволяет вам быть очень гибкими в процессе резервного копирования и восстановления.

Хранение старых журналов транзакций полезно для восстановления базы данных на определенный момент времени. В зависимости от вашего бизнеса может быть полезно восстановить базу данных до конкретной транзакции, сделанной несколько дней назад (полезно для технической поддержки или откатов разработки).

Я использовал netbackup в прошлом, чтобы делать резервные копии журнала транзакций прямо на ленту, но обнаружил, что неудобно возиться с лентами для восстановления резервной копии (ленты обрабатываются другой командой в магазине, который находится довольно далеко. из серверной). Ленты тоже ненадежны, особенно когда они ДЕЙСТВИТЕЛЬНО нужны.

Еще одна проблема с резервным копированием на ленту заключается в том, что в случае серьезного сбоя возникает серьезная нехватка ленточных накопителей, позволяющих восстановить резервные копии. Будет целый ряд других служб и систем, которые будут в списке, и ваши резервные копии могут быть не на первом месте!

Если кто-то хочет восстановить момент времени до вчерашнего дня в 14:00, мне потребуется предыдущая полная резервная копия и журналы транзакций. Однако, если я знаю, что мои полные резервные копии хороши, кроме этого случая, есть ли смысл в хранении резервных копий журнала транзакций предыдущего дня?

Вы правы, единственная цель журнала транзакций olkder - восстановить старую резервную копию по какой-либо причине. Время, в течение которого вы храните предыдущую резервную копию, полностью зависит от того, насколько вы уверены в следующей резервной копии. Лично я предполагаю, что следующая резервная копия не удастся и будет доступна по крайней мере последняя резервная копия. Я также не избавляюсь от них до тех пор, пока мне не понадобится (например, с 15% зарезервированного пространства у меня все еще есть 400 ГБ, так что я мог бы также сохранить резервную копию или 2 там).

Не забывайте золотое правило Гейзенберга - ваши данные не существуют до тех пор, пока они не будут постоянно находиться в двух местах.