Я занимаюсь изменением практики резервного копирования SQL Server в моей компании. Мы используем для еженедельного создания полных резервных копий и ежедневных дифференциальных резервных копий в ночное время. Проблема в том, что по мере роста этих полных резервных копий будет невозможно передавать гигабайты данных по FTP еженедельно.
В качестве альтернативы я думал о сохранении одной полной резервной копии и ежечасном выполнении резервного копирования журналов + ftp. Возникли некоторые опасения, например:
Любые мнения приветствуются!
Прежде всего, спросите себя, какова цель наличия неопределенного отставания от всех транзакций, когда-либо отправленных в базу данных. Действительно ли важно, что вы можете восстановить базу данных, как это было 7 месяцев и 8 дней назад?
Наиболее распространенной причиной резервного копирования базы данных является аварийное восстановление. Если ваша база данных выйдет из строя по какой-либо причине, вы не сможете восстановить ее из резервной копии, сделанной год назад. Вы восстановите базу данных до самой последней доступной резервной копии.
Если вы согласны, почему бы не использовать запасной план, в котором вы принимаете:
Допустим, вы делаете полную резервную копию в воскресенье в 00:05, а во все остальные дни - дифференциальную резервную копию одновременно.
Если кто-то случайно уронит всю таблицу в четверг около полудня, вам нужно будет восстановить только: полную резервную копию с воскресенья, дифференциальную резервную копию с четверга (в 00:05) и 11 часов резервного копирования журналов.
С этой моделью вам понадобится всего 1 (одна!) Неделя невыполненной работы, чтобы восстановиться после аварии.
Каждое воскресенье, когда создается полная резервная копия, вы можете просто удалить все резервные копии с предыдущей недели.
Это, конечно, применимо только в сценарии, в котором целью резервного копирования является аварийное восстановление.