- Вопрос или проблема
- Ответ или решение
- Как предотвратить копирование поврежденного файла с компьютера на NAS и перезапись исправной версии
- 1. Регулярная проверка целостности данных
- 2. Выбор правильного ПО для резервного копирования
- 3. Интеграция NAS как основного хранилища
- 4. Настройка умных правил для резервного копирования
- 5. Психология хранения данных и регулярные проверки
- Заключение
Вопрос или проблема
Вот сценарий, который я бы попытался предотвратить:
- Сегодня 11 ноября 2024 года. С SSD на моем Mac все в порядке (надеюсь…). Я создаю резервную копию с Mac на NAS.
- Время идет…
- Теперь “сегодня” 1 июня 2025 года. Я создаю новую резервную копию с Mac на NAS. Но я не знал, что тот же файл на Mac был поврежден из-за деградации, и теперь поврежденная версия с SSD Mac перезаписала “нормальную” версию на NAS. “Нормальная” версия утеряна, и теперь у меня есть две копии поврежденной версии.
Можно ли предотвратить такой сценарий? Какой должен быть рабочий процесс?
-
Система также не знает, что данные повреждены. К сожалению, APFS от Apple не хранит контрольные суммы данных (ваш NAS, вероятно, использует ZFS или Btrfs, которые это делают). Поэтому вам нужно поддерживать их самостоятельно – найдите инструмент, который будет генерировать sha1sum или xxhash для всех фотографий в файл; настройте его на инкрементальную работу (т.е. генерировать контрольные суммы для новых файлов, но никогда не генерировать их заново для “известных” файлов); затем проверяйте эти контрольные суммы перед резервным копированием и генерируйте новые контрольные суммы везде, где вы импортируете фотографии.
- Если NAS использует ZFS, то он должен выполнять периодический ‘scrub’, который автоматически заметит повреждение (и даже может автоматически восстановить его, если он настроен как массив RAID1 или RAIDZ). В этом случае может быть хорошей идеей использовать NAS в качестве основного хранилища для таких данных (как отдельная вещь от папки “резервные копии”), и оставлять только вторичную копию на ноутбуке.
-
Не используйте “копировать и вставить всю папку раз в квартал” в качестве вашей системы резервного копирования. Существуют различные системы резервного копирования с дедупликацией (например, Borg, Restic), которые работают аналогично Git, сохраняя множество снимков с течением времени, где идентичные данные хранятся только один раз. (Time Machine от Apple аналогична, но я думаю, что она не совсем соответствует требованиям.)
Поскольку дедупликация в таких инструментах основана на контрольных суммах хранимых данных, а не на названиях файлов, это также означает, что не идентичные данные (например, внезапно поврежденные файлы) будут храниться отдельно и никогда не перезапишут ранее хранящуюся другую версию, что означает, что вам не нужно идти на компромисс по частоте резервного копирования – например, даже если вы запускаете резервное копирование каждый день, наличие этих старых снимков все равно дает вам несколько недель или месяцев для повторного выполнения ранее упомянутых ручных проверок sha1/контрольных сумм и обнаружения повреждений.
- (Хотя, скорее всего, программа просто пропустит резервное копирование поврежденного файла, так как случайный битовой разложение фактически не изменяет его ‘время изменения’.)
Дополнительно к принятому ответу, btrfs и ZFS позволяют создавать снимки файловой системы. Файловая система копируется только при записи, поэтому, если вы можете избежать записи неизмененных данных, дополнительное пространство, занимаемое хранением большого количества снимков, возвращающихся в прошлое, является приемлемо маленьким. (Btrfs и ZFS также имеют возможности дедупликации, которые я не изучал.)
Я использую btrfs для своего архива и rsync -a --delete --inplace --stats, чтобы скопировать текущее состояние в архив.
Резервное копирование Borg лучше для архива, который будет храниться вне площадки, потому что все данные шифруются перед записью (и дедуплицируются, и опционально сжимаются). Тем не менее, это требует очень значительного времени ЦП, если данные измеряются в терабайтах, тогда как файловой системе btrfs просто нужно достаточно места для всех снимков и обычных накладных расходов файловой системы.
Ответ или решение
Как предотвратить копирование поврежденного файла с компьютера на NAS и перезапись исправной версии
В современных условиях хранения данных потеря целостности файлов становится серьезной проблемой. Учитывая ваш сценарий, важно разработать надежный рабочий процесс, который минимизирует риск копирования поврежденных файлов и перезаписи исправных версий. Рассмотрим несколько подходов и технологий, которые помогут вам избежать подобных ситуаций.
1. Регулярная проверка целостности данных
Вы должны понимать, что файловые системы, такие как APFS на macOS, не обеспечивают автоматическую проверку целостности через контрольные суммы. Поэтому важным шагом будет внедрение системы проверки целостности данных перед их резервным копированием:
- Использование контрольных сумм: Запускайте скрипт или используйте программу, которая сможет генерировать контрольные суммы (например, SHA-1 или xxHash) для всех файлов, которые вы собираетесь копировать. Сохраняйте эти контрольные суммы в отдельном файле или базе данных.
- Периодическая проверка: Настройте график выполнения проверки контрольных сумм, чтобы убедиться, что файлы на вашем Mac не были повреждены. Это позволит вам обнаружить проблемы до резервного копирования на NAS.
2. Выбор правильного ПО для резервного копирования
Необходимо избегать простого копирования и вставки файлов в NAS. Вместо этого используйте решения для резервного копирования, которые имеют встроенные механизмы защиты:
- Дедупликация и инкрементальные резервные копии: Ищите программы, такие как Borg или Restic, которые используют системы дедупликации и инкрементального резервного копирования. Эти системы позволяют сохранять несколько версий файлов без их перезаписи, даже если файл был поврежден.
- Создание снимков: Если NAS использует файловую систему, такую как ZFS или Btrfs, регулярно используйте функцию создания снимков (snapshots). Это поможет сохранить состояние данных на определенный момент времени и легко откатить изменения в случае повреждения.
3. Интеграция NAS как основного хранилища
Рассмотрите возможность использования NAS как основного хранилища для важных файлов, а не просто как резервное копирование:
- Настройка RAID: Настройте NAS с использованием RAID-массивов (например, RAID1 или RAIDZ). Это улучшит отказоустойчивость и сохранность данных в случае аппаратных сбоев.
- Систематическая шапка (scrub): Если вы используете ZFS, периодически выполняйте операции "scrub" для проверки и исправления возможной корррупции на уровне хранилища.
4. Настройка умных правил для резервного копирования
Важно адаптировать стратегию резервного копирования, основываясь на более умных правилах:
- Используйте правила исключения: Настройте ваше программное обеспечение для резервного копирования так, чтобы оно пропускало файлы, которые были повреждены или изменены некорректно. Зачастую программы резервного копирования игнорируют файлы, которые не изменялись (не изменено их время модификации), что может защитить вас от случайного копирования поврежденной версии.
5. Психология хранения данных и регулярные проверки
Также важно обеспечить регулярный аудит и понимание вашей информации:
- Обучение и осведомленность пользователей: Убедитесь, что каждый член команды понимает важность целостности данных и соблюдает процедуры резервного копирования.
- Регулярные проверки: Применяйте стратегию регулярного аудита хранимых данных, чтобы убедиться, что все версии файлов актуальны и целы.
Заключение
Применение данных стратегий поможет вам защититься от потери целостности файлов и обеспечить сохранность важных данных на NAS. Учтите, что работа с данными – это не только технологии, но и процессы, необходимость их соблюдения и постоянная их оптимизация. Настройка правильного рабочий процесса резервного копирования – обязательный шаг к долгосрочной защите данных.