Те, кому пришлось восстанавливать данные с неисправного тома RAID, часто спрашивают, какой тип массива выбрать в дальнейшем? Однако это не совсем корректный вопрос. Тип массива, вопреки распространенному мнению, не так уж и важен. В целом, дальнейшие действия вращаются больше вокруг вашей стратегии резервного копирования данных и тактики, которая будет использована в вашем плане хранения данных.
В хранении данных стратегия резервного копирования включает в себя следующее:
Какие данные должны быть скопированы, а какие нет.
Как часто происходит резервное копирование.
Требуется ли управление версиями.
Как быстро понадобятся данные в случае поломки.
Тактика включает в себя то, как реализуется выбранная бэкап-стратегия. Например, будет ли это онлайн-бэкап или просто внешний жесткий диск? Некорректная стратегия резервного копирования, так же, как и неподходящая тактика, может «укусить» вас, если не будет выбрана осмысленно.
Стратегия резервного копирования
Выбор стратегии резервного копирования зависит от данных – их важности, объема, частоты изменения и других характеристик. Так, например, стратегия хранения семейного фотоархива фундаментально отличается от стратегии хранения постоянно изменяющихся файлов, таких как сборки приложений.
Здравый смысл может говорить нам, что бэкап нужен для всего. Но бывают случаи, когда отсутствие резервной копии вполне себе верное решение. Например, мы не копируем некоторые тома RAID, хранящие тестовый набор файлов и папок. Эти данные малоценны и могут быть воссозданы в случае необходимости.
После создания резервной копии уровень RAID совершенно не важен, потому что RAID – это не бэкап! Вместо этого главной заботой становится управление версиями, потому что RAID сразу же автоматически передает любое изменение данных, включая ошибки, на все диски в массиве. Без множества хранящихся версий ключевых данных ваш бэкап может быть поврежден и бесполезен.
Аварийная остановка
Любой системе, которая использует автоматическое копирование данных, будь то RAID или пофайловое копирование, нужен механизм аварийной остановки. Системы с этим механизмом прекращают работу или переключаются в неактивное состояние, когда происходит сбой, предотвращая дальнейшее распространение ошибок на другие системы/устройства.
Механический сбой в одном из дисков RAID, например, является случаем аварийной остановки. Как только диск перестает вращаться, он больше не может делать что-то другое. RAID-контроллер отметит, что диск оффлайн, и начнет использовать восстановление четности.
С другой стороны, сбой в памяти кэша контроллера не подразумевает аварийную остановку. Кэш предоставляет неверные данные, но контроллер не знает, что что-то не так. Неправильные данные распространяются повсюду, портя все избыточные копии. То же самое относится и к ошибке человека, поскольку система хранения данных не понимает намерений пользователя, вместо этого слепо следуя командам.
Даже если ваша система организована так, что данные копируются по расписанию на другой компьютер, который может даже находиться в другой стране, это по-прежнему RAID1 с некоторой задержкой между копиями, а не резервное копирование. Примером может послужить случай, когда не те данные сохранились в бэкапе, переписав нужные данные.
Глубина версии
Глубина версии, также известная как время хранения, – это количество времени, в течение которого хранится копия данных. Глубина версии должна быть больше, чем время между случаями реального использования данных. Например, если самое «свежее» использование файла было в 2021 году, копия, оставшаяся с того времени, должна быть в бэкапе. Если пользователю нужен доступ к этому файлу в 2022 году, а он не открывается, то с этим не будет проблем – останется резервная копия.
Распространенный сценарий ошибки заключается в том, что кнопка «Сохранить» используется для основного файла (например, шаблон документа), когда «Сохранить как» должна была использоваться для создания новой версии. Если пользователь не заметил проблему сразу же, тогда ошибка, возможно, обнаружится, когда понадобится исходный файл. Итак, повторим: глубина версии/время хранения должны быть достаточно долгими, чтобы предоставить исходную версию файла.
Очистка
Жизнь такова, что, чем дольше вы не делаете (или не проверяете) что-то, тем меньше шансов, что вы сможете сделать это в следующий раз. Системы с высоким временем безотказной работы тому пример. По мере увеличения времени безотказной работы вероятность успешного перезапуска уменьшается.
То же самое верно и для систем хранения данных. Чем дольше вы активно не работаете с данными, например, не открываете файлы и не проверяете правильность данных, тем меньше шансов, что они все еще на месте. Более того, чтобы избежать резервного копирования данных, которые уже повреждены, вы должны периодически проверять, что в бэкапе есть копия, которая все еще доступна для чтения и полезна.
Тактика
Выбор тактики обусловлен определенными требованиями для хранения данных. Обычно для домашних пользователей существуют простые решения, например, внешний жесткий диск, куда периодически копируются данные. Самая распространенная проблема в этом случае – человеческая забывчивость. Разумной альтернативой здесь могут стать онлайн-хранилища, такие как Backblaze или CrashPlan (очень удобно, но на данный момент в России не работают). Они полностью автоматизированы и часто идут со встроенным управлением версиями.
Если у вас есть подходящий план резервного копирования, вы можете безопасно использовать RAID. Если вы столкнулись со сбоем в RAID, важно выяснить, почему это произошло. Чаще всего изменение уровня RAID или переключение контроллеров не предотвращает повторение первоначальной проблемы. Самые распространенные причины сбоя в RAID – ошибка оператора (пользователя), ошибки при замене диска или ошибки при работе с программой управления RAID массивом. Уровень RAID в этих случаях имеет минимальное влияние.
Статья написана Еленой Пахомовой, одним из создателей программы для восстановления данных Volga [ссылка удалена мод.]
