Мой опыт более старые версии MSSQL, так что там могут быть вещи в SQL2008, которые помогут вам лучше.
Мы находимся на жестком диске на некоторых наших старых серверах. Это машины в нашем интернет-провайдере, и время их восстановления с ленты не очень хорошее - 24 часа не редкость :(Поэтому нам нужно сохранить приличную историю резервного копирования в сети.
Мы берем полную резервную копию в воскресенье, дифференциальное резервное копирование каждую ночь и резервные копии TLog каждые 10 минут.
Мы заставляем резервные копии Tlog каждую минуту во время дефрагментации таблиц и индексов и обновления статистики - это потому, что это самые интенсивные задачи TLog, которые мы запускаем, и они ранее ответственно определяли размер постоянного файла Tlog; так как это изменение позволило запустить постоянный размер TLog примерно на 60% меньше, чем раньше.
Стоит посмотреть размер резервных копий Diff, хотя - если окажется, что к резервной копии среды резервная копия DIFF приближается к размеру полной резервной копии, вы можете также запустить полную резервную копию два раза в неделю и иметь меньший размер резервные копии на следующий день или два.
При удалении файлов резервной копии Full или Diff (для восстановления дискового пространства) убедитесь, что вы удалили ранее резервные копии TLog. Но рассмотрите свой путь восстановления - хотите ли вы восстановить полное резервное копирование в прошлый воскресенье и все Tlog с тех пор, или вы счастливы, что для восстановления момента в момент восстановления вы можете вернуться только до резервного копирования DIFF прошлой ночью? (т. е. вернуться дальше, вы можете восстановить только резервную копию FULL/DIFF, а не точку отсчета). Если позже вы сможете удалить все предыдущие резервные копии Tlog, как только вы сделали резервную копию DIFF.
(Очевидно, что независимо от этого вам необходимо получить резервные копии на ленту и т. Д., А на ваш сервер-копию вам просто не нужно зависеть от восстановления ленты, чтобы сделать восстановление, но вы теряете гранулярность восстановления со временем)
Мы можем восстановить последний полный (или последний полный плюс DIFF понедельника) в «временную базу данных», чтобы проверить что-то, а затем отбросить эту БД, но если мы действительно ДЕЙСТВИТЕЛЬНО должны были восстановить к «последнему понедельнику 15 минут-минус 10 утра», мы будем жить с необходимостью получать резервные копии с ленты или с сервера-копии.
Все наши резервные файлы находятся в каталоге NTFS с комплектом Compress. (Возможно, вы можете создавать сжатые резервные копии прямо из SQL2008 ??, на серверах, у которых есть головоломки, работает SQL2000). Я читал, что это неодобрительно, но никогда не видел хороших рассуждений, почему, и у нас никогда не было проблем с этим - прикоснитесь к дереву!
Моим советом было бы сделать резервную копию локально, а затем переместить файлы. Если вы выполняете резервное копирование напрямую на удаленный общий ресурс и имеете проблемы с сетевым подключением, у вас нет резервной копии, а общий доступ может быть достаточно медленным, чтобы начать вызывать таймауты в SQL – Kristen