Почему иногда происходит сбой разностного резервного копирования SQL Server? - PullRequest
0 голосов
/ 15 октября 2019

У меня проблема, которая возникает иногда, когда мое задание дифференциального резервного копирования SQL Server завершается неудачно с сообщением об ошибке, похожим на

Msg 3035, Sev 16, State 1, Line 1 : Cannot perform a differential backup for database "MyDatabaseName", because a current database backup does not exist. Perform a full database backup by reissuing BACKUP DATABASE, omitting the WITH DIFFERENTIAL option. [SQLSTATE 42000]
Msg 3013, Sev 16, State 1, Line 1 : BACKUP DATABASE is terminating abnormally. [SQLSTATE 42000]

В настоящее время я использую решение SQL Server Mantenance от Ola Hallengrenскрипт для резервного копирования, проверки целостности и обслуживания индекса. Я запланировал задание резервного копирования следующим образом:

  • Полное резервное копирование системных баз данных каждый день @ 01:30
  • Полное резервное копирование всех пользовательских баз данных каждую неделю в понедельник, среду иПятница @ 2:30
  • Дифференциальное резервное копирование всех пользовательских баз данных каждую неделю в воскресенье, вторник, четверг и субботу @ 02:30
  • Резервное копирование журнала транзакций или всех пользовательских баз данных каждые 30 минут

Я также установил время очистки на 168 часов ... что составляет 7 дней.

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

Стоит отметить, что это случается только иногда. Иногда разностное резервное копирование работает без проблем, а в других случаях происходит сбой.

Этот сервер является виртуальной машиной, и мы используем VMWare vSphere / vCenter 6.5. Я поговорил с администратором своего сервера и спросил, как работает его резервная копия, и он сказал мне, что мы используем Quest AppAssure, в котором используется технология моментальных снимков VMWare, и что он выполняет резервное копирование дисков каждые x минут, поэтому возможно, чтовремя его резервного копирования меняется и в конечном итоге совпадает с моим.

Мы оглянулись назад на время, когда его резервные копии работали в выходные дни, и они произошли за несколько минут до того, как началась моя. Мне интересно, если это вызывает мои проблемы с резервным копированием? Если да, есть ли способ предотвратить это, или нам просто нужно планировать резервные копии в разное время, которые не перекрываются?

Спасибо

Ответы [ 2 ]

0 голосов
/ 17 октября 2019

Сегодня мы провели еще один звонок с Quest и выяснили решение этой проблемы.

Может показаться, что при настройке резервного копирования с помощью Quest Rapid Recovery у вас есть возможность делать резервные копии на уровне компьютера или на уровне томарезервный. Когда он настроен на резервное копирование на уровне томов, вы можете выбрать для него резервное копирование на уровне блоков, не поддерживающее SQL Server, или резервное копирование на основе SQL Server, которое в конечном итоге использует службу теневого копирования томов. и эти резервные копии отображаются как полные (только для копирования) резервные копии в истории резервного копирования SQL ... даже если вы не можете восстановить их из SQL Server.

Быстрое восстановление может выполнять резервное копирование только по расписанию, плюс имеетвозможность обрезать журналы после завершения резервного копирования, чтобы избежать заполнения файлов журналов, но не может выполнять резервное копирование журналов транзакций, поэтому вы теряете возможность выполнять более детальное восстановление вплоть до второго, как с помощью собственного восстановления SQL Timeline ... Вот почему мы решили использовать собственные резервные копии SQL Server.

Таким образом, чтобы решить эту проблему, необходимо выполнить резервное копирование на уровне компьютера, которое не имеет осведомленности о SQL Server / интеграции. Или вы можете выполнить резервное копирование на уровне тома, но отключите расширение Writer SQL Server и параметры журналов усечения, чтобы удалить интеграцию.

Мы выполнили несколько тестов, и с того момента / времени, когда этоизменение было сделано, мы видим только резервные копии SQL Server и больше не выполняем быстрое восстановление в истории резервного копирования SQL Server.

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

  • Возможность восстановления на уровне машины (быстрое восстановление)
  • Сохранение резервных копий SQL Server (быстрое)Восстановление)
  • Гибкий момент восстановления (SQL Server)
0 голосов
/ 16 октября 2019

Просто хотел опубликовать обновление для этой проблемы

Мы запланировали звонок с Quest вчера, и они заверили меня, что их резервное копирование только делает моментальные снимки томов и не повлияет на мои резервные копии SQL. Они сказали, что причина появления этих ошибок, скорее всего, связана с быстрым восстановлением (я думаю, AppAssure был переименован в быстрое восстановление) и моими заданиями резервного копирования SQL, которые пытаются одновременно использовать службу теневого копирования томов, и поэтому нам просто нужношататься заданий резервного копирования. В итоге я обнаружил, что это не совсем так, потому что резервные копии быстрого восстановления были настроены на усечение моих журналов SQL. Я также сказал парню из отдела быстрого восстановления, что, когда я запросил таблицу наборов резервных копий msdb, я увидел список заданий резервного копирования, которые совпадали со временем резервного копирования быстрого восстановления. Тем не менее он заверил меня, что это не окажет никакого влияния на мои резервные копии.

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

Мне кажется, что быстрое восстановление определенно влияет на мои резервные копии SQL.

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

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

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

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

Затем я решил использовать функцию восстановления временной шкалы и выбрать момент времени во время моих тестов, когда резервное копирование быстрого восстановления не было частьюперечислите резервные копии и сделайте резервную копию. Как и ожидалось, это было успешно. После этого я попытался выполнить восстановление в другой момент времени, когда была указана резервная копия быстрого быстрого восстановления (только для копирования), и проверка не удалась для файла полного резервного копирования (только для копирования) из быстрого восстановления, поскольку он не существует на сервере SQL.

Есть рекомендации, как это исправить? Смысл резервного копирования Rapid Recovery должен состоять в резервном копировании машины, на случай, если мы когда-нибудь потеряем сервер и должны будем восстановить весь сервер, а также забрать резервные копии моего сервера sql, чтобы сохранить их на хранение, так как я толькоРезервное копирование на сервере на 7 дней.

...