Чем резервные копии SQL отличаются от обычных ночных резервных копий ИТ-серверов?

Наш ИТ-отдел каждую ночь выполняет резервное копирование всего сервера (на этом сервере установлен экземпляр SQL Server), который должен выполнять резервное копирование этого сервера, а также всей сети на случай, если что-то пойдет не так ...

Итак, мой менеджер спросил, что является значительным из моих полных, разностных и журнальных SQL-резервных копий по сравнению с тем, что резервирует ИТ-отдел? Чтобы сэкономить больше места на нашем сервере, а не хранить эти файлы в течение нескольких недель и удалять их, она считает, что ИТ просто предоставит их!

Я знаю, что это неправильно, поскольку я могу восстановить до последних 30 минут с помощью резервных копий журналов, ИТ-отдел восстанавливает его на следующий день, но единственное ли это отличие?

Поскольку я сохраняю / отправляю файлы резервных копий своей базы данных на тот же сервер, ИТ-отдел восстанавливает их, но если у меня нет этих заданий резервного копирования в моем плане обслуживания, тогда ИТ-отдел может просто восстановить экземпляр SQL без каких-либо наших таблиц, транзакций ... и т.д. Я правильно понял?
Любой совет будет очень признателен.

Резервные копии базы данных дают вам возможность восстановления на определенный момент времени (при условии, что у вас есть FULLмодель восстановления). Даже если ваши ИТ-специалисты делают резервные копии каждые несколько минут, что крайне маловероятно, у вас все равно будет пробел.

Резервные копии сервера не заменяют резервные копии базы данных, они дополняют их путем «архивирования» файлов резервных копий базы данных в течение длительного времени (т. Е. Больше, чем сегодня).

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

Редактировать : @Sting имеет правильную точку в том, что теневые копии (механизм, наиболее вероятно используемый для создания резервных копий сервера), вряд ли будут делать точно одновременную копию всех ваших файлов базы данных (включая файлы журналов), что может привести к несоответствиям, когда вы восстанавливаете резервную копию. Например, если теневая копия считывает журнал транзакций за несколько миллисекунд до считывания файла базы данных, файл базы данных может содержать незафиксированную транзакцию, но, поскольку транзакция была зафиксирована через миллисекунду, журнал не будет иметь никакой записи о ней.

Существует вероятность того, что восстановление файлов mdf и ldf из теневой копии будет несовместимо с точки зрения транзакций. Это означает, что эти теневые восстановления не соответствуют свойствам ACID базы данных.

https://msdn.microsoft.com/en-us/library/aa480356.aspx

Скорее всего, восстановление будет работать, но вам будет интересно, что вы на самом деле получаете. (Не говоря уже о том, что вам нужно будет протестировать, чтобы убедиться, что резервные копии / теневые копии сервера работают должным образом на каждом сервере) Кроме того, нет способа восстановить журналы транзакций в определенный момент времени, как вы можете использовать SQL Server T -SQL ВОССТАНОВИТЬ ЛОГ / СТОПАТ.

Пока резервное копирование / восстановление Windows Server не будет соответствовать тесту ACID SQL Server, наша отрасль не может позволить себе рисковать.

Сказав все это, я был на самых странных встречах. Если вы сообщаете о проблемах ИТ-специалистам, и они все еще не заботятся о них, или они готовы пойти на риск, это снимает с ваших плеч огромное бремя. Что бы ни случилось, задокументируйте протоколы собраний, чтобы все решили, и почему все решили, и разошлите их участникам собрания.

Все зависит от того, какой продукт использует ваш ИТ-отдел для резервного копирования на уровне сервера.

Например, в виртуальной среде VMWare сделает снимки сервера. Если задействован SQL Server, в VMWare есть опция, которую большинство администраторов включает (или это может быть по умолчанию, я не знаю), которая замораживает ввод-вывод для баз данных во время снимка. Теперь, хотя это может занять всего несколько секунд, у вас есть потенциал, чтобы вызвать проблемы в вашем приложении, и он не является надежным методом для восстановления базы данных.

Если вы используете сторонний продукт для резервного копирования на уровне сервера, скорее всего, это просто резервное копирование на уровне файлов ваших баз данных. В этом случае он также должен иметь возможность делать резервные копии заблокированных файлов, поскольку в SQL Server все вложенные файлы mdf и ldf заблокированы с точки зрения Windows. Например, Symantec BackupExec использует Advanced Open File Option, чтобы сделать снимок этого заблокированного файла. Именно то, как это звучит, заставит большинство администраторов баз данных сжаться, если им придется восстанавливать базу данных с такой резервной копией, подумайте о согласованности базы данных, когда она берет эту резервную копию. Нет никакой гарантии, если резервное копирование будет запущено во время процесса загрузки данных, какую часть загрузки данных получило это резервное копирование?

Собственные резервные копии SQL Server заслуживают доверия в том отношении, что они считаются хорошими резервными копиями. Вы точно знаете, в каком состоянии они находились, когда вы запустили резервное копирование для ПОЛНОЙ, запланировано ли это для загрузки данных и тому подобное. Резервное копирование журнала для модели полного восстановления гарантирует, что вы можете восстановить эту базу данных в секунду.

Если ваш менеджер полностью настроен на использование резервного копирования на уровне сервера, я бы тщательно изучил продукт, который они используют. Я хотел бы выяснить, есть ли какой-либо дополнительный компонент или агент резервного копирования SQL Server, который можно приобрести для создания резервных копий баз данных VDI.

Кроме того, следует обсудить и обсудить с вашим менеджером, какое участие вам потребуется при проверке и устранении неполадок в случае сбоя резервного копирования SQL Server. Я интенсивно использовал Netbackup на предыдущих работах, и несколько лет назад клиент хотел, чтобы я прошел тестирование использования агента SQL Server Netbackup для их среды. Это включало других администраторов баз данных, которые также должны были оказывать поддержку. Я сказал им заранее, что для устранения ошибок резервного копирования для SQL Server необходимо знать немного о Netbackup. Главные серверы Netbackup обычно работают на серверах Unix, так что теперь вы должны знать, что некоторые Unix .... могут быть забавными, но более болезненными, если вы уже заняты. Просто кое-что для рассмотрения и может быть хорошим предметом обсуждения с вашим менеджером, и выяснить, кто несет ответственность за устранение неисправностей.

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

В идеальном случае ваш ИТ-отдел хранит резервные копии на одном или нескольких разных серверах в разных местах. Вы, вероятно, храните свою резервную копию на том же сервере, на котором живут ваши базы данных. Поэтому, если сервер умирает или ваше здание сгорает, ваш ИТ-отдел, возможно, сможет восстановить ваши файлы, но резервные копии, которые вы сделали, будут удалены с сервера.

НО вы можете восстановить вашу резервную копию, на вашей скорости, в любое время, если ваш сервер еще жив.

Как уже говорили другие, это зависит от ваших потребностей, вашей терпимости к риску и того, насколько важен контроль времени восстановления. Если вы хотите восстановиться после чего-то глупого, ваши резервные копии будут быстрее и лучше. Если вы хотите восстановиться после аварии вне вашего контроля, лучше подойдет резервная копия ИТ.