На веб-сайте «Тао резервного копирования» автор утверждает, что следует проверять, какие файлы были изменены между резервными копиями, чтобы избежать резервного копирования поврежденных файлов. Или, по его словам, «тогда вы можете исследовать изменения и восстановить любые поврежденные файлы по своему усмотрению».
Я не понимаю, как это можно сделать, когда простой поиск в Windows показывает, что всего за 24 часа было изменено> 430 файлов. Хотя я могу предположить, что такие вещи, как% userprofile% \ AppData \ LocalLow \ Microsoft \ CryptnetUrlCache, не важны, мне сложно в этом быть уверенным. В конце концов, кто может сказать, что хитрый взломщик не может выяснить ошибку в [вставьте сюда имя любимого браузера], которая превращает поврежденный файл кеша в эксплойт?
Несмотря на эту проблему, я не могу игнорировать предложение проверить целостность файла, потому что нетрудно сделать вывод, что резервное копирование испорченной версии файла не дает вам реальной резервной копии.
Как я могу убедиться, что файлы, для которых я создаю резервные копии, не в руинах, не посвятив остаток своей жизни изучению тонкостей каждой отдельной программы, которая когда-либо запускалась на компьютере, и всех связанных с ними форматов файлов?
Упреждающая мысль:
Если я проверяю файлы только в таких местах, как «Документы», это не спасает меня от резервного копирования испорченных копий, скажем, Visual Studio. И у меня нет желания переустанавливать все свое программное обеспечение с DVD / мучительно медленных загрузок в момент выхода из строя жесткого диска.
Если вы находитесь на этом уровне паранойи (никакая стратегия резервного копирования не может гарантировать 100% безопасность), вы также можете возразить, что разрушающая программа / взломщик также возвращает вам файлы, которые не повреждены, пока вы их проверяете. Он портит только резервные копии.
Единственный вариант, о котором я могу думать, - это заархивировать несколько резервных копий и вручную выбрать ту, которая не повреждена (пока).
Я думаю, что лучшей стратегией было бы избежать этой проблемы с коррупцией: а именно избегать вторжений и вирусов и использовать файловую систему, которая может обнаруживать битовую гниль, такую как ZFS или Btrfs.
Битовая гниль - это совершенно другой вид коррупции, чем несанкционированное изменение; битовая гниль легко обнаружить, так что я пока оставлю это.
Если ты имеешь ввиду этот совет Я не считаю это особенно реалистичным. Если вирус или злоумышленник изменяет ваши файлы «разумно» и медленно, те же файлы, ты также меняются время от времени, никакое автоматическое решение вам не поможет. Ни ECC, ни сумма MD5, ни структурная проверка, ни резервное копирование (!) Не гарантируют, что вы сохраните все свои данные в точности "истинными". Единственное надежное средство - периодически сравнивать все ваши сохраненные данные с данными, которым вы субъективно доверяете, такими как ваш мозг, мозги других людей, физические измерения, бумажный документ и т. Д.
Аккуратно да? Другими словами, если вы пишете книгу (то есть редактируете файл), единственный способ быть полностью уверенным в том, что она не была злонамеренно повреждена в любом случае, - это проверить ее вручную с помощью собственной памяти.
Вот почему этот риск обычно игнорируется.
Только со статическими файлами эта проблема легко решается с помощью достойной резервной копии. Просто восстановите двоичные файлы Visual Studio (статические) из резервной копии, которую вы создали сразу после установки / обновления.