SQL-Ex blog

Сначала дадим определения двух терминов:

• Recovery Point Objective (целевая точка восстановления - RPO) - измеряется во времени, это сколько данных вы могли бы потерять при восстановлении резервной копии. Например, если ваш последний бэкап был закончен в 1 час утра, а сейчас 10 часов, вы могли потерять данные за 9 часов, если сервер упал прямо сейчас. Это и есть 9 часов RPO.


• Recovery Time Objective (целевое время восстановления - RTO) - также измеряется во времени, это сколько времени заняло бы выполнение восстановления. Например, если сервер упал прямо сейчас, и в общей сложности вам потребовался 1 час, чтобы решить сделать восстановление, начать процесс восстановления, завершить восстановление, а затем разрешить пользователям вернуться к приложениям, то это и есть 1 час RTO.

Бизнесу очень трудно сойтись на том, каковы для них допустимые RPO и RTO, потому что они хотят потерять как можно меньше данных, и они хотят быть недоступными в течение как можно более короткого времени. Тут на помощь приходит sp_BlitzBackups. Он, очевидно, не сможет сообщить ваши цели. Но он оценит состояние ваших дел сейчас.

Когда вы выполняете sp_BlitzBackups, он анализирует последние 7 дней ваших резервных копий. Вот, что он возвращает:



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

• RPOWorstCaseMinutes - самый длинный промежуток времени между двумя успешными резервными копиями. Скажем, вы регулярно делаете бэкапы журнала каждые 15 минут, но с 9:10 до 9:40 источник резервной копии находился в офлайне, и бэкап не мог быть выполнен. У вас имелись успешные бэкапы журнала в 9:00 и 9:45. Худшим случаем RPO для вас будет, если сервер упадет в 9:44, как раз непосредственно перед запуском резервирования в 9:45, поэтому худшим случаем RPO будет 44 минуты.


• RTOWorstCaseMinutes - наибольшая продолжительность времени, которая требуется для восстановления и возврата в режим онлайн. Скажем, вы делаете полный бэкап каждую ночь, и резервные копии журнала каждые 15 минут. Худший сценарий RTO в этом случае будет, если сервер упал сразу перед ночным полным бэкапом, поскольку вам придется восстановить полную резервную копию предыдущего дня, плюс резервные копии журнала за весь день. Для того, чтобы вычислить это число, мы берем общее время, затраченное на все эти резервные копии. Технически это неточно, поскольку восстановление может занимать больше времени, чем резервирование, особенно из-за отсутствия мгновенной инициализации файла в журнале транзакций. Но это хотя бы дает вам грубую начальную точку.


• Supporting info - когда люди видят эти числа "худших случаев", их следующим вопросом является "Боже мой, когда это мы могли потерять данные за 44 минуты?" Следующие столбцы дают вам информацию о дате/времени, когда это произошло, и задействованных резервных копиях, плюс дополнительные информационные запросы, с помощью которых вы можете проверить историю, хранящуюся в MSDB, например:
  
  
  

Хотите настроить производительность и для своих резервных копий?

Продолжим прокрутку вправо результирующего набора и обнаружим:

• FullMBpsAvg, Min, Max - вы получаете пропускную способность в мегабайтах в секунду.


• FullSizeMBAvg, Min, Max - величина ваших резервных копий до сжатия.


• FullCompressedSizeMBAvg, Min, Max - величина ваших резервных копий после сжатия.


• Подобные столбцы для Diffs, Logs - они полезны, если вам нужно оценить скорость изменения.

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

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