> >> > К тому же, о каких жертвах может идти речь на системе, в которой память > >> > с контролем ошибок, диски с контролем ошибок, ФС с контролем ошибок и > >> > избыточность, позволяющая восстановить от 1 до 2-х дисков из 4-х? > >> > >> ... и вот на пути ко всему этому мы ставим софт, судя по обзору, не > >> слишком хорошо написанный. В качестве single point of failure, потому > >> что он-то как раз не резервирован, средств восстановления после ошибок > >> лишен заведомо, а средств их контроля скорее всего. > >> > > Не стал расписывать везде, т.к. думал, что очевидно, но видимо зря. > > Там есть пункт "- Все данные и метаданные защищены контрольными суммами.". > > Он актуален для всех "больших" систем, таких как UrBackup, BackupPC, > > Bareos (в urbackup есть даже "End-to-end verification of all file > backups"). > > Что касается других проблем с надёжностью: три вышеназванные системы > > развиваются уже более 10 лет, исходный код открыт (и в urbackup, на > > первый взгляд, неплох). > > При этом, urbackup и backuppc, я так понимаю, файловый бэкап хранят в > > виде иерархии файлов на ФС (плюс, используют БД, но файлы всё-равно > > остаются доступны с ФС). > > Ну, ок, средства контроля есть. (Надо сказать, что "end-to-end > verification" в rsync подразумевается, и если оно в urbackup есть "даже", > то это пугает...) > Пишут, что это типа "paranoid mode".
> Ну, фиг знает. Хранение файлов на ФС, в общем, уже аргумент за > надежность. Потеря метаданных в случае чего переживабельна. Хотя, неприятна. > Если, > правда, информация об исходном пути к файлу таки сохраняется в > ФС. Потому что вот если эта информация есть только в БД, это уже > стремно. > В БД хранится, куда восстанавливать, я так понял.
