1. Кто отвечает за то, чтобы бэкап делался? Простой вопрос, но на него не всегда есть простой ответ. Инфраструктура рапортует, что честно бэкапит все, что ей сказали. Владельцы приложений уверены, что инфраструктура бэкапит все, что должно бэкапиться.
   Есть только одна проблема: из процесса передачи системы в промышленную эксплуатацию иногда выпадает создание заданий на резервное копирование. И из процесса изменений — тоже выпадает. Потому, что как бы очевидно и должно само.
   В итоге все, как мы любим — проблема спряталась на стыке зон ответственности. Система есть, а бэкапа нет. А в случае отсутствия интеграции с управлением изменениями, спрятаться проблема может гораздо глубже — мы будем бэкапить только часть необходимой информации.
2. Как определить оптимальную частоту и глубину хранения бэкапов? Чаще всего для простоты создается несколько (3-4) типовых шаблонов, а дальше все идет по ним без детального BIA и анализа жизненного цикла данных. А ведь здесь кроется довольно большое пространство для оптимизации как используемых хранилищ, так и пропускной способности сети, для которой массовые бэкапы являются серьезным испытанием. Что-то можно делать не так часто, что-то хранить не так долго, где-то достаточно инкрементального копирования, и т.д. Это — прямая экономия. Да-да, те самые деньги, которых вам в этом году дали так мало.
3. Репликация ≠ резервное копирование. Повышение отказоустойчивости — да, но не резервное копирование. Потому, что репликация :
   • не защищает от логического разрушения данных (да, можно использовать отложенную репликацию, но надо успеть вовремя поймать проблему)
   • не защищает от атаки внутреннего или внешнего злоумышленника
   • не позволит нам восстановить срез данных за прошлый период
   • не обеспечивает соответствия требованиям регуляторов

За кадром осталась еще тема тестирования бэкапов, но это отдельная большая боль. Будем есть слона по частям.