31 марта — Международный день резервного копирования

А вы сделали бэкап? А проверили, что его можно использовать?

World_Backup_Day_logo-02

31 марта — Международный день резервного копирования (англ. World Backup Day) призван привлечь общественное внимание к вопросам обеспечения сохранения информации, а также распространить информацию о необходимости защиты от потери данных.

backup

Резервное копирование — это создание копии данных на носителе (жёстком диске, флеш-карте, CD-диске и других носителях), предназначенном для восстановления данных в случае их повреждения или потери на основном носителе.

День бэкапа был установлен по инициативе пользователей сайта социальных новостей Реддит и неслучайно был назначен на 31 марта. В компьютерной среде известны случаи потери информации именно 1 апреля (вот такие «шуточки») — существует даже целая группа первоапрельских вирусов, которые активизируются именно в этот день. Результат их нещадного действия — сбой в работе системы или потеря информации.

Ниже памятка для администраторов  MS SQL Server

О бэкапах  — модель восстановления:

  1. Simple
    1. Не растет лог (меньше усилий на контроль)
    2. Нельзя сделать бэкап лога (инкрементного изменения данных)
    3. Подходит для тестовых сред
    4. Меньше требований квалификации
  2. Full
    1. Можно быстрее восстановить данные и меньше потерять данных
    2. Следить за ростом лога
    3. Для продуктива
    4. Обязательно надо попрактиковать 

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

  1. Полный бэкап – ВСЕГДА!
  2. Дифференциальный (накопительный) – если есть, но не обязательно
  3. Бэкапы логов в хронологической последовательности (если режим FULL )
    1. без полного бэкапа не будут подыматься

Вопрос:.

Безусловно согласен с тем что нужно планировать восстановление при сбое во всех компонентах системы, а не только дисков. Соответственно бэкап базы и логи нужно как можно быстрее восстановить на другом сервере. Но как это сделать быстро, если диск для резервных копий базы и логов скуля находится на этом же неисправном сервере? И возможно что он тоже сгорел…Тогда какую задачу решает диск для бэкапов на том же сервере? Возможно, более правильным делать бэкапы базы и логов на какое-то сетевое хранилище (а потом оттуда уже отправлять в облако)? Наверно скорость записи бэкапов логов каждые 15 мин. на сетевой диск будет не такой высокой, по сравнению с записью на диск на том же сервере, но это вроде бы не влияет на текущую производительность, по крайней мере в моем опыте каких-то дополнительных ожиданий на sql server из-за этого не было.
Ответ:  Сначала бэкап складывается на локальный диск сервера СУБД, затем он копируется куда-то на резервный сервер, и плюс ещё куда-то наружу. Все три копии живут одновременно, более старые копии удаляются по некоему вашему расписанию вида «ежедневные бэкапы храним столько-то, еженедельные — столько-то, ежемесячные столько-то». Бэкап сразу в сеть делать не надо, это может быть неприемлемо долго, сначала делается бэкап на локальный диск (можно механический, при объёмах бэкапов в сотни гигабайт — можно рассматривать для складирования первичных например недорогие SSD десктопного класса, к примеру Crucial MX500 или Samsung 860 Evo, тогда и изготовление и восстановление бэкапа не будут замедляться из-за недостаточно быстрого бэкапного диска), а затем уже этот готовый бэкап копируется куда вам заблагорассудится.

См. также http://www.gilev.ru/copy1c/

См. также http://www.gilev.ru/restoreib/

См. также http://www.gilev.ru/aboutlsn/