Краткий обзор систем резервного копирования

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Краткий обзор систем резервного копирования

artiom
> Так, на всякий случай: FUSE-драйвер всегда отлажен хуже, чем нормальная
> FS.
Допустим, я поверю, что это не является предубеждением.

> Особенно — в части работоспособности в случае, когда нижележащее
> хранилище имеет частичные сбои в метаинформации. Которая там тоже своя.
>Но это мало мне поможет. Потому что хранить данные на ФС достаточно
проблематично, если я хочу пофайлово восстанавливать данные с разных ФС.
Возможно, что с ZFS это сделать легче, но ещё легче с готовым инструментом.
Касательно метаинформации: даже у tar она "своя". Только, допустим, мне
нужно сохранить ACL и какие-нибудь "дополнительные потоки" (применимо к
NTFS).
Может ли это сделать rsync+tar?

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

Reply | Threaded
Open this post in threaded view
|

Re: Краткий обзор систем резервного копирования

artiom
In reply to this post by Victor Wagner


15.03.2018 09:35, Victor Wagner пишет:

> On Wed, 14 Mar 2018 20:51:12 +0300
> artiom <[hidden email]> wrote:
>
>> Я думаю, мой "парк" не разрастётся более десятка машин.
>> Но я хочу иметь удобный web-интерфейс и единую точку контроля.
>> Иначе, зачем я собираю устройство, второй основной задачей которого
>> является бэкап?
>>
>
> И действительно - зачем? По мне так логичнее иметь много разных
> устройств  с резервными копиями, желательно географически разнесенных.
> Чтобы защититься и от таких маловероятных угроз как пожар или
> ограбление.
>
Одно другого не исключает. Синхронизироваться только неудобно, если
центрального устройства нет. И нескольким людям без него тяжело
синхронизироваться.

Reply | Threaded
Open this post in threaded view
|

Re: Краткий обзор систем резервного копирования

Artem Chuprina-4
In reply to this post by artiom
artiom -> [hidden email]  @ Thu, 15 Mar 2018 20:42:32 +0300:

 >> Особенно — в части работоспособности в случае, когда нижележащее
 >> хранилище имеет частичные сбои в метаинформации. Которая там тоже своя.
 > Но это мало мне поможет. Потому что хранить данные на ФС достаточно
 > проблематично, если я хочу пофайлово восстанавливать данные с разных ФС.
 > Возможно, что с ZFS это сделать легче, но ещё легче с готовым инструментом.
 > Касательно метаинформации: даже у tar она "своя". Только, допустим, мне
 > нужно сохранить ACL и какие-нибудь "дополнительные потоки" (применимо к
 > NTFS).
 > Может ли это сделать rsync+tar?

NTFS - нет.

 >>  > К тому же, о каких жертвах может идти речь на системе, в которой память
 >>  > с контролем ошибок, диски с контролем ошибок, ФС с контролем ошибок и
 >>  > избыточность, позволяющая восстановить от 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 есть "даже",
то это пугает...)

Ну, фиг знает. Хранение файлов на ФС, в общем, уже аргумент за
надежность. Потеря метаданных в случае чего переживабельна. Если,
правда, информация об исходном пути к файлу таки сохраняется в
ФС. Потому что вот если эта информация есть только в БД, это уже
стремно.

Reply | Threaded
Open this post in threaded view
|

Re: Краткий обзор систем резервного копирования

artiom
>  >>  > К тому же, о каких жертвах может идти речь на системе, в которой память
>  >>  > с контролем ошибок, диски с контролем ошибок, ФС с контролем ошибок и
>  >>  > избыточность, позволяющая восстановить от 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".

> Ну, фиг знает. Хранение файлов на ФС, в общем, уже аргумент за
> надежность. Потеря метаданных в случае чего переживабельна.
Хотя, неприятна.

> Если,
> правда, информация об исходном пути к файлу таки сохраняется в
> ФС. Потому что вот если эта информация есть только в БД, это уже
> стремно.
>
В БД хранится, куда восстанавливать, я так понял.

12