7. Необдуманное использование механизмов обеспечения безопасности при архивации
Для большинства организаций информационная безопасность стоит на первом месте, однако иногда, как показывает практика, это выходит боком. Мне приходилось быть свидетелем ситуаций, в которых восстановление данных из резервной копии оказывалось невозможным, потому что никто не знал пароля к ней. Другой случай — в организации использовали шифрование резервных копий на аппаратном уровне, а потом установили новый накопитель на магнитной ленте, который не поддерживал старый механизм шифрования (а значит, старые архивные копии стало невозможно прочитать).
Защита резервных копий, без сомнения, важна, но стоит учитывать, как принятые меры безопасности могут сказаться на дальнейшем использовании этих копий. Когда возникает необходимость восстановить систему после фатального сбоя, меньше всего хочется тратить время на преодоление некорректно поставленной защиты.
8. Архивация одних только файлов данных
Один мой знакомый как-то раз заявил, что не стоит осуществлять резервное копирование всей серверной системы с приложениями и достаточно ограничиться лишь архивацией файлов данных. С его точки зрения, это значительно ускоряет процесс архивации и требует меньше свободного пространства для хранения резервных копий. В каком-то смысле это действительно серьезное преимущество, но в целом я считаю такой подход в корне неправильным.
Когда сервер требует восстановления после серьезного сбоя, переустановить операционную систему и все приложения, а потом скопировать сохраненные данные можно, но это занимает слишком много времени. Гораздо быстрее восстановить систему из резервной копии целиком. К тому же, полностью восстановить предыдущие настройки сервера вручную бывает порой очень затруднительно. Резервное копирование всей системы гарантирует полное восстановление предыдущей конфигурации в случае сбоя.
9. Хранение архивных копий исключительно на резервном сервере
Архивация с использованием резервного сервера имеет целый ряд преимуществ по сравнению с традиционным резервным копированием на магнитные планки. Тем не менее, ограничиваться только этим механизмом не стоит — ведь резервный сервер так же уязвим, как основной, и в случае пожара, наводнения или любого другого стихийного бедствия будет уничтожен вместе с рабочими серверами. Поэтому важно на регулярной основе записывать резервные копии на пленку и хранить на удаленном складе для обеспечения дополнительной безопасности.
10. Слишком быстрая перезапись пленок
В одной из организаций, где мне доводилось работать, было принято записывать новые резервные копии поверх старых двухнедельной давности. В целом подход был неплох, но двухнедельный интервал оказался слишком маленьким. Как-то раз у нас рухнул сервер Exchange из-за повреждений информационного хранилища. Когда мы попытались восстановить его из резервной копии, оказалось, что повреждения присутствуют и в ней. Проблема, как выясняется, возникла еще давно и со временем все прогрессировала. Повреждения сохранились во всех наших резервных копиях за последние две недели, так что восстановить сервер мы не смогли. Это прекрасный аргумент не только в пользу периодической проверки архивных копий на работоспособность, но и в пользу того, чтобы сделать больше интервал между перезаписью магнитной пленки или сохранять хотя бы некоторые из них для долгосрочного архивирования.
