как исправить стратегию гниения / резервного копирования

Question

Я планирую сделать резервную копию моего личного файла на NAS (который будет использовать файловую систему btrfs). Это дешевый НАС, так что, к сожалению, в нем нет ECC-барана. В моей стратегии резервного копирования будут другие копии файлов (онлайн) с использованием таких сервисов, как Crashplan и Mega (я, вероятно, буду использовать оба на всякий случай). Для дальнейшего резервирования сама NAS может быть резервной копии через USB-соединение. Итак, что, по вашему мнению, произойдет, если я увижу некоторую деградацию данных в одном файле.

Будет ли где-нибудь безопасная / рабочая копия? Я никогда не использовал Crashplan раньше, но они должны каким-то образом сохранить оригинальную версию, потому что они не смогут заметить никаких изменений в файле, верно?

Честно говоря, я немного сбит с толку, и мне хотелось бы понять, может ли моя стратегия действительно работать (до тех пор, пока однажды у меня не появится NAS с EMS-овом).

Большое спасибо

Answer 1

Честно говоря, если вы не хотите или не можете использовать ОЗУ ECC, я бы не стал использовать самовосстанавливающуюся файловую систему, такую как ZFS (как описано в сообщении на форуме) или Btrfs.

Причина в том, что функции "самовосстановления" довольно легко могут стать "саморазрушающимися", если есть проблема с оперативной памятью.

Вместо этого в ОЗУ, отличном от ECC, вам, вероятно, лучше использовать обычную файловую систему, например ext4. С сегодняшним состоянием Btrfs (начинающим становиться стабильным, но все еще имеющим ряд неровностей, которые нужно сгладить, и которые еще не увидели значительных реальных развертываний и опыта с ошибками), это заставило бы меня чувствовать себя намного комфортнее. Даже ZFS, которая относительно хорошо зарекомендовала себя как файловая система, все еще имеет некоторые проблемы на хостах Linux; Btrfs не так зрел, как ZFS.

Чтобы обнаружить «гниль» в файловой системе, которая не имеет встроенной возможности проверки контрольных сумм данных, вы можете использовать любой из нескольких инструментов, доступных для этой цели. Одним из таких инструментов, с которым я не связан, является hashdeep, который может делать хэши MD5, SHA1, SHA256, Tiger и Whirlpool. Если вы выполняете это на достаточно регулярной основе (так же, как вы выполняете очистку файловой системы ZFS или Btrfs), то вы можете быть достаточно уверены, что поймаете любую деградацию, которая может произойти. Затем вы можете восстановить поврежденные файлы из резервных копий, как локальных, так и удаленных.

Я не знаком с Crashplan, но я подозреваю, что они смотрят на метаданные файла, чтобы определить, изменился ли файл или нет, и поскольку метаданные файла, скорее всего, не будут затронуты (если только это не является целью повреждения, который либо будет относительно несущественным, либо приведет к сбою проверки хеша), он не должен обнаруживать какие-либо изменения в файле. Следовательно, поврежденные файлы не должны быть сохранены. Если вы хотите быть уверены, сконфигурируйте ваши решения для резервного копирования так, чтобы сохранить как минимум несколько старых версий, доступных на случай, если один из них будет поврежден и сохранен в таком состоянии.