Как резервные копии SQL отличаются от обычных регулярных ночных резервных копий?

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

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

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

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

8 голосов | спросил Mary 22 FebruaryEurope/MoscowbMon, 22 Feb 2016 21:50:21 +0300000000pmMon, 22 Feb 2016 21:50:21 +030016 2016, 21:50:21

4 ответа


8

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

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

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

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

ответил Daniel Hutmacher 22 FebruaryEurope/MoscowbMon, 22 Feb 2016 22:02:27 +0300000000pmMon, 22 Feb 2016 22:02:27 +030016 2016, 22:02:27
7

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

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

Скорее всего, восстановление будет работать, но вы останетесь недоумевающим, что вы на самом деле получаете. (Не говоря уже о том, что вам будет поручено тестировать, чтобы серверные резервные копии /теневые копии работали правильно на каждом сервере). Кроме того, нет возможности восстановить журналы транзакций в определенный момент времени, как вы можете использовать SQL Server T -SQL RESTORE LOG /STOPAT.

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

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

ответил Sting 22 FebruaryEurope/MoscowbMon, 22 Feb 2016 22:07:55 +0300000000pmMon, 22 Feb 2016 22:07:55 +030016 2016, 22:07:55
3

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

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

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

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

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

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

ответил Shawn Melton 23 FebruaryEurope/MoscowbTue, 23 Feb 2016 05:10:14 +0300000000amTue, 23 Feb 2016 05:10:14 +030016 2016, 05:10:14
0

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

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

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

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

ответил James Jenkins 22 FebruaryEurope/MoscowbMon, 22 Feb 2016 22:25:55 +0300000000pmMon, 22 Feb 2016 22:25:55 +030016 2016, 22:25:55

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132