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".

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

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

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

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ 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 есть "даже",
то это пугает...)

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

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

[artiom]

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

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, я так понимаю, файловый бэкап хранят в
виде иерархии файлов на ФС (плюс, используют БД, но файлы всё-равно
остаются доступны с ФС).

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

[Victor Wagner]

On Wed, 14 Mar 2018 20:51:12 +0300
artiom  wrote:

> Я думаю, мой "парк" не разрастётся более десятка машин.
> Но я хочу иметь удобный web-интерфейс и единую точку контроля.
> Иначе, зачем я собираю устройство, второй основной задачей которого
> является бэкап?
> 

И действительно - зачем? По мне так логичнее иметь много разных
устройств  с резервными копиями, желательно географически разнесенных.
Чтобы защититься и от таких маловероятных угроз как пожар или
ограбление.
-- 

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

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Wed, 14 Mar 2018 20:58:21 +0300:

 >>  >> > Для себя сделал вывод, что надежнее самопальной конструкции на базе
 >>  >> > rsync все-таки ничего не придумали.  
 >>  >> 
 >>  >> > Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
 >>  >> > надежность и простота восстановления в любом случае важнее.  
 >>  >> 
 >>  >> Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,
 >> 
 >>  > Лет десять назад именно Артем Чуприна научил меня пользоваться
 >>  > rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
 >>  > что-то другое, чего rsnapshot не умеет.
 >> 
 >> Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
 >> переместился, ни если у него изменилась метаинформация. И если второе —
 >> это ограничение вообще конструкции хардлинков (и правильно, что не
 >> умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
 >> правильно, что не умеет, но по другой причине) временами хочется и
 >> подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
 >> хотя бы переименовали директорию верхнего уровня, не говоря уже о
 >> несколько более содержательной реорганизации.
 >> 
 >> Но всего этого хочется при условии "не потерять в надежности и не
 >> усложнить процедуру восстановления". А описанные комбайны ими таки
 >> жертвуют.
 > Да ну ладно. Эти комбайны (большинство) также предоставляет вам файлы в
 > виде иерархии. А там уж, восстанавливай, как хочешь, куда хочешь и чем
 > угодно.
 > Так что, я не думаю, что они сильно "жертвуют надёжностью".

Спасибо, я внимательно почитал обзор. Возможно, более внимательно, чем
его автор :)

Так, на всякий случай: FUSE-драйвер всегда отлажен хуже, чем нормальная
FS. Особенно — в части работоспособности в случае, когда нижележащее
хранилище имеет частичные сбои в метаинформации. Которая там тоже своя.

 > К тому же, о каких жертвах может идти речь на системе, в которой память
 > с контролем ошибок, диски с контролем ошибок, ФС с контролем ошибок и
 > избыточность, позволяющая восстановить от 1 до 2-х дисков из 4-х?

... и вот на пути ко всему этому мы ставим софт, судя по обзору, не
слишком хорошо написанный. В качестве single point of failure, потому
что он-то как раз не резервирован, средств восстановления после ошибок
лишен заведомо, а средств их контроля скорее всего.

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

[artiom]

12.03.2018 15:07, yuri.nefe...@gmail.com пишет:
> Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 12 Mar 2018
> 11:59:09 +0300:
> ...
>> > Лет десять назад именно Артем Чуприна научил меня пользоваться
>> > rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
>> > что-то другое, чего rsnapshot не умеет.
> ...
> On Mon, 12 Mar 2018, Artem Chuprina wrote:
>>
>> Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
>> переместился, ни если у него изменилась метаинформация. И если второе —
>> это ограничение вообще конструкции хардлинков (и правильно, что не
>> умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
>> правильно, что не умеет, но по другой причине) временами хочется и
>> подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
>> хотя бы переименовали директорию верхнего уровня, не говоря уже о
>> несколько более содержательной реорганизации.
>>
> 
>   Вообще говоря всё это unison умеет. Принцип работы как у rsync,
>   а синхронизацию в обратную сторону можно и запретить.
>   Правда, для полноценного бекапа как то стрёмно его пробовать.
>   А вот для рабочих папок, где всякие перемещения, переименования
>   и т.п. обычное дело, самое то.
> 
> Ю.
О, ещё тулза не попавшаяся мне на глаза.

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

[artiom]

12.03.2018 12:27, Artem Chuprina пишет:
> Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 12 Mar 2018 11:59:09 
> +0300:
> 
>  >> > Для себя сделал вывод, что надежнее самопальной конструкции на базе
>  >> > rsync все-таки ничего не придумали.  
>  >> 
>  >> > Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
>  >> > надежность и простота восстановления в любом случае важнее.  
>  >> 
>  >> Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,
> 
>  > Лет десять назад именно Артем Чуприна научил меня пользоваться
>  > rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
>  > что-то другое, чего rsnapshot не умеет.
> 
> Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
> переместился, ни если у него изменилась метаинформация. И если второе —
> это ограничение вообще конструкции хардлинков (и правильно, что не
> умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
> правильно, что не умеет, но по другой причине) временами хочется и
> подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
> хотя бы переименовали директорию верхнего уровня, не говоря уже о
> несколько более содержательной реорганизации.
> 
> Но всего этого хочется при условии "не потерять в надежности и не
> усложнить процедуру восстановления". А описанные комбайны ими таки
> жертвуют.
Да ну ладно. Эти комбайны (большинство) также предоставляет вам файлы в
виде иерархии. А там уж, восстанавливай, как хочешь, куда хочешь и чем
угодно.
Так что, я не думаю, что они сильно "жертвуют надёжностью".
К тому же, о каких жертвах может идти речь на системе, в которой память
с контролем ошибок, диски с контролем ошибок, ФС с контролем ошибок и
избыточность, позволяющая восстановить от 1 до 2-х дисков из 4-х?

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

[artiom]

12.03.2018 11:56, Stanislav Vlasov пишет:
> 9 марта 2018 г., 20:36 пользователь Artem Chuprina  
> написал:
> 
>> Для себя сделал вывод, что надежнее самопальной конструкции на базе
>> rsync все-таки ничего не придумали.
> 
>> Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
>> надежность и простота восстановления в любом случае важнее.
> 
> Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,
> но с дедупликацией между разными бекапами при помощи хардлинков.
> В результате работы - несколько каталогов по одному на каждый бекап с
> деревом каталогов внутри. Восстановление - копированием.
> 
Он у меня был до недавнего момента.
Как раз, похоже на то, что так рекламирует Артём Чуприна: самодельная
бэкапилка на rsnapshot с интерфейсом "файловой системы".
Плюс, fuse, который показывал бэкап в виде иерархии по дням.

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

[artiom]

Я думаю, мой "парк" не разрастётся более десятка машин.
Но я хочу иметь удобный web-интерфейс и единую точку контроля.
Иначе, зачем я собираю устройство, второй основной задачей которого
является бэкап?

11.03.2018 11:15, Павел Марченко пишет:
> +1 поэтому такие системы и существуют, чтобы не городить велосипед,
> каждый раз как нужно что-то забэкапить. А если у вас тысячи серверов,
> которые нужно бэкапить? 
> 
> 11 мар. 2018 г. 10:20 пользователь "artiom"  > написал:
> 
> 
> 
> 09.03.2018 18:36, Artem Chuprina пишет:
> > artiom -> debian-russian@lists.debian.org
>   @ Fri, 9 Mar 2018 13:47:00
> +0300:
> >
> >  > Выкладываю здесь свой обзор по итогам обсуждения в теме "Backup".
> >  > Может, кому пригодится.
> >  > Дополнения и исправления приветствуются.
> >
> > Спасибо, интересно.
> >
> > Для себя сделал вывод, что надежнее самопальной конструкции на базе
> > rsync все-таки ничего не придумали.
> >
> > Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
> > надежность и простота восстановления в любом случае важнее.
> >Но в прошлой теме вы говорили, что важнее выбирать инструмент,
> исходя из
> политики резервного копирования (с чем буду разбираться, когда FreeNAS
> нормально поставлю) и прочих условий.
> Если машин много или требуется интерфейс, есть подозрение, что ваша
> конструкция превратится либо в backuppc, либо в bareos, ну или в
> urbackup, накрайняк.
> Так зачем же делать работу, которую уже сделали за меня?
> 
> 

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

[yuri . nefedov]

On Mon, 12 Mar 2018, Eugene Berdnikov wrote:


On Mon, Mar 12, 2018 at 08:07:14PM +0800, yuri.nefe...@gmail.com wrote:

Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 12 Mar 2018
11:59:09 +0300:
...

Лет десять назад именно Артем Чуприна научил меня пользоваться
rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
что-то другое, чего rsnapshot не умеет.

...
On Mon, 12 Mar 2018, Artem Chuprina wrote:


Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
переместился, ни если у него изменилась метаинформация. И если второе ???
это ограничение вообще конструкции хардлинков (и правильно, что не
умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
правильно, что не умеет, но по другой причине) временами хочется и
подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
хотя бы переименовали директорию верхнего уровня, не говоря уже о
несколько более содержательной реорганизации.



  Вообще говоря всё это unison умеет. Принцип работы как у rsync,
  а синхронизацию в обратную сторону можно и запретить.


Unison не умеет ни хардлинки, ни симлинки. Может, я что-то проспал и
месяц или два назад он всему научился, но предыдущие 8 лет активного
его использования это представляло проблему. Да, unison наконец начал
понимать, что файл куда-то переместили без изменений (случилось это,
как мне кажется, полгода-год назад), он уже не качает переименованный
каталог заново, но до возможностей rsync ему ещё очень далеко.


  Хардлинки не умеет, это да, тут я поспешил.
  А симлинки всегда мог, за исключением  ntfs, где не умеет.
  Я им уже лет пять пользуюсь и перемещение файлов и папок
  он отслеживает, за что и понравился. Ну иногда тупит бывает,
  но это если его просить еще свой бекап файлов создавать.


  Правда, для полноценного бекапа как то стрёмно его пробовать.
  А вот для рабочих папок, где всякие перемещения, переименования
  и т.п. обычное дело, самое то.


Для бэкапа unison вообще не предназначен. Это средство синхронизации
с возможностью сохранять старые версии изменённых файлов.

Бэкап это то, из чего можно восстановить дерево каталогов по состоянию
на определённую отметку времени, из юнисона же сделать это крайне
проблематично.


  Да согласен я, согласен. Только чаше бывает, что из всего этого
  дерева нужен один файл, а время и даже название из дырявой головы
  уже утекли...
  Тут скорее что-то типа time machine маковской подошло бы.

Ю.

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

[Eugene Berdnikov]

On Mon, Mar 12, 2018 at 08:07:14PM +0800, yuri.nefe...@gmail.com wrote:
> Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 12 Mar 2018
> 11:59:09 +0300:
> ...
> >> Лет десять назад именно Артем Чуприна научил меня пользоваться
> >> rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
> >> что-то другое, чего rsnapshot не умеет.
> ...
> On Mon, 12 Mar 2018, Artem Chuprina wrote:
> >
> >Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
> >переместился, ни если у него изменилась метаинформация. И если второе ???
> >это ограничение вообще конструкции хардлинков (и правильно, что не
> >умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
> >правильно, что не умеет, но по другой причине) временами хочется и
> >подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
> >хотя бы переименовали директорию верхнего уровня, не говоря уже о
> >несколько более содержательной реорганизации.
> >
> 
>   Вообще говоря всё это unison умеет. Принцип работы как у rsync,
>   а синхронизацию в обратную сторону можно и запретить.

 Unison не умеет ни хардлинки, ни симлинки. Может, я что-то проспал и
 месяц или два назад он всему научился, но предыдущие 8 лет активного
 его использования это представляло проблему. Да, unison наконец начал
 понимать, что файл куда-то переместили без изменений (случилось это,
 как мне кажется, полгода-год назад), он уже не качает переименованный
 каталог заново, но до возможностей rsync ему ещё очень далеко.

>   Правда, для полноценного бекапа как то стрёмно его пробовать.
>   А вот для рабочих папок, где всякие перемещения, переименования
>   и т.п. обычное дело, самое то.

 Для бэкапа unison вообще не предназначен. Это средство синхронизации
 с возможностью сохранять старые версии изменённых файлов.

 Бэкап это то, из чего можно восстановить дерево каталогов по состоянию
 на определённую отметку времени, из юнисона же сделать это крайне
 проблематично.
-- 
 Eugene Berdnikov

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

[yuri . nefedov]

Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 12 Mar 2018
11:59:09 +0300:
...

> Лет десять назад именно Артем Чуприна научил меня пользоваться
> rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
> что-то другое, чего rsnapshot не умеет.

...
On Mon, 12 Mar 2018, Artem Chuprina wrote:


Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
переместился, ни если у него изменилась метаинформация. И если второе —
это ограничение вообще конструкции хардлинков (и правильно, что не
умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
правильно, что не умеет, но по другой причине) временами хочется и
подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
хотя бы переименовали директорию верхнего уровня, не говоря уже о
несколько более содержательной реорганизации.



  Вообще говоря всё это unison умеет. Принцип работы как у rsync,
  а синхронизацию в обратную сторону можно и запретить.
  Правда, для полноценного бекапа как то стрёмно его пробовать.
  А вот для рабочих папок, где всякие перемещения, переименования
  и т.п. обычное дело, самое то.

Ю.

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

[Artem Chuprina]

Victor Wagner -> debian-russian@lists.debian.org  @ Mon, 12 Mar 2018 11:59:09 
+0300:

 >> > Для себя сделал вывод, что надежнее самопальной конструкции на базе
 >> > rsync все-таки ничего не придумали.  
 >> 
 >> > Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
 >> > надежность и простота восстановления в любом случае важнее.  
 >> 
 >> Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,

 > Лет десять назад именно Артем Чуприна научил меня пользоваться
 > rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
 > что-то другое, чего rsnapshot не умеет.

Exactly. В смысле, чего rsync не умеет. А он не умеет ни если файл
переместился, ни если у него изменилась метаинформация. И если второе —
это ограничение вообще конструкции хардлинков (и правильно, что не
умеет, хотя на задаче бэкапа тоже хочется уметь), то первое (тоже
правильно, что не умеет, но по другой причине) временами хочется и
подправить. Когда на бэкап-клиенте :) большое поддерево переместили или
хотя бы переименовали директорию верхнего уровня, не говоря уже о
несколько более содержательной реорганизации.

Но всего этого хочется при условии "не потерять в надежности и не
усложнить процедуру восстановления". А описанные комбайны ими таки
жертвуют. Больше, как я понимаю, надежностью — FUSE-драйвера, которые
позволяют сохранить простоту восстановления, по крайней мере у половины
есть.

И прикрутить к имеющемуся сверху тоже можно, но это несколько
дополнительный велосипед.

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

[Stanislav Vlasov]

12 марта 2018 г., 13:59 пользователь Victor Wagner  написал:

>> > Для себя сделал вывод, что надежнее самопальной конструкции на базе
>> > rsync все-таки ничего не придумали.
>>
>> > Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
>> > надежность и простота восстановления в любом случае важнее.
>>
>> Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,
>
> Лет десять назад именно Артем Чуприна научил меня пользоваться
> rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
> что-то другое, чего rsnapshot не умеет.

Подозреваю, что тогда под дедупликацией имеется ввиду что-то вроде
дедупликации в zfs или аналогичных.
Но там, куда я могу положить бекап, сделанный rsync, я не могу
воткнуть достаточно памяти, чтоб ещё и дедупликацию в zfs сделать.
А там где могу - нельзя хранить бекапы, так как это их источник.

-- 
Stanislav

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

[Victor Wagner]

On Mon, 12 Mar 2018 13:56:31 +0500
Stanislav Vlasov  wrote:

> 9 марта 2018 г., 20:36 пользователь Artem Chuprina 
> написал:
> 
> > Для себя сделал вывод, что надежнее самопальной конструкции на базе
> > rsync все-таки ничего не придумали.  
> 
> > Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
> > надежность и простота восстановления в любом случае важнее.  
> 
> Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,

Лет десять назад именно Артем Чуприна научил меня пользоваться
rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
что-то другое, чего rsnapshot не умеет.

--  

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

[Stanislav Vlasov]

9 марта 2018 г., 20:36 пользователь Artem Chuprina  написал:

> Для себя сделал вывод, что надежнее самопальной конструкции на базе
> rsync все-таки ничего не придумали.

> Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
> надежность и простота восстановления в любом случае важнее.

Рекомендую глянуть на rsnapshot - как раз конструкция на базе rsync,
но с дедупликацией между разными бекапами при помощи хардлинков.
В результате работы - несколько каталогов по одному на каждый бекап с
деревом каталогов внутри. Восстановление - копированием.

-- 
Stanislav

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

[Eugene Berdnikov]

On Sun, Mar 11, 2018 at 11:15:17AM +0300, Павел Марченко wrote:
> +1 поэтому такие системы и существуют, чтобы не городить велосипед, каждый
> раз как нужно что-то забэкапить. А если у вас тысячи серверов, которые
> нужно бэкапить?

 Если у вас тысячи source-серверов и, как следствие, тысячи destination,
 то web-интерфейс к каждому вряд ли будет интересовать. Да и ко всем вместе
 скорее всего интересовать будет не сильно.

 Вероятно, конфиг такой бэкапалки будет скриптовый, и заскриптована там
 будет некая логика, которую в web-интерфейс для чайников никому в голову
 не придёт засунуть.

 PS. Пожалуйста, не надо топ-квотить.
-- 
 Eugene Berdnikov

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

[Павел Марченко]

+1 поэтому такие системы и существуют, чтобы не городить велосипед, каждый
раз как нужно что-то забэкапить. А если у вас тысячи серверов, которые
нужно бэкапить?

11 мар. 2018 г. 10:20 пользователь "artiom"  написал:



09.03.2018 18:36, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Fri, 9 Mar 2018 13:47:00
+0300:
>
>  > Выкладываю здесь свой обзор по итогам обсуждения в теме "Backup".
>  > Может, кому пригодится.
>  > Дополнения и исправления приветствуются.
>
> Спасибо, интересно.
>
> Для себя сделал вывод, что надежнее самопальной конструкции на базе
> rsync все-таки ничего не придумали.
>
> Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
> надежность и простота восстановления в любом случае важнее.
>Но в прошлой теме вы говорили, что важнее выбирать инструмент, исходя из
политики резервного копирования (с чем буду разбираться, когда FreeNAS
нормально поставлю) и прочих условий.
Если машин много или требуется интерфейс, есть подозрение, что ваша
конструкция превратится либо в backuppc, либо в bareos, ну или в
urbackup, накрайняк.
Так зачем же делать работу, которую уже сделали за меня?

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

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Sun, 11 Mar 2018 10:19:04 +0300:

 >>  > Выкладываю здесь свой обзор по итогам обсуждения в теме "Backup".
 >>  > Может, кому пригодится.
 >>  > Дополнения и исправления приветствуются.
 >> 
 >> Спасибо, интересно.
 >> 
 >> Для себя сделал вывод, что надежнее самопальной конструкции на базе
 >> rsync все-таки ничего не придумали.
 >> 
 >> Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
 >> надежность и простота восстановления в любом случае важнее.

 > Но в прошлой теме вы говорили, что важнее выбирать инструмент, исходя из
 > политики резервного копирования (с чем буду разбираться, когда FreeNAS
 > нормально поставлю) и прочих условий.
 > Если машин много или требуется интерфейс, есть подозрение, что ваша
 > конструкция превратится либо в backuppc, либо в bareos, ну или в
 > urbackup, накрайняк.
 > Так зачем же делать работу, которую уже сделали за меня?

Ключевые слова в моем комментарии — "для себя" :)

Если у меня будет задача бэкапа, к которой потребуется веб-интерфейс,
выбор может оказаться другим. А пока мне к ней нужен интерфейс файловой
системы и нотификаций заинтересованным персонам, он таков.

Если машин будет много, задача дедупликации может встать в полный
рост. До такой степени, что придется пожертвовать некоторой частью
надежности. Но сейчас не стоит.

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

[artiom]

09.03.2018 18:36, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Fri, 9 Mar 2018 13:47:00 +0300:
> 
>  > Выкладываю здесь свой обзор по итогам обсуждения в теме "Backup".
>  > Может, кому пригодится.
>  > Дополнения и исправления приветствуются.
> 
> Спасибо, интересно.
> 
> Для себя сделал вывод, что надежнее самопальной конструкции на базе
> rsync все-таки ничего не придумали.
> 
> Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
> надежность и простота восстановления в любом случае важнее.
>Но в прошлой теме вы говорили, что важнее выбирать инструмент, исходя из
политики резервного копирования (с чем буду разбираться, когда FreeNAS
нормально поставлю) и прочих условий.
Если машин много или требуется интерфейс, есть подозрение, что ваша
конструкция превратится либо в backuppc, либо в bareos, ну или в
urbackup, накрайняк.
Так зачем же делать работу, которую уже сделали за меня?

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

[Eugene Berdnikov]

On Fri, Mar 09, 2018 at 06:36:44PM +0300, Artem Chuprina wrote:
> artiom -> debian-russian@lists.debian.org  @ Fri, 9 Mar 2018 13:47:00 +0300:
> 
>  > Выкладываю здесь свой обзор по итогам обсуждения в теме "Backup".
>  > Может, кому пригодится.
>  > Дополнения и исправления приветствуются.
> 
> Спасибо, интересно.
> 
> Для себя сделал вывод, что надежнее самопальной конструкции на базе
> rsync все-таки ничего не придумали.
> 
> Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
> надежность и простота восстановления в любом случае важнее.

 +1

 К выделенным А.Чуприной "надёжность" и "простота" я бы ещё добавил
 "скорость восстановления", а также возможность выбирать восстанавливаемые
 объекты по критериям, которые заранее неизвестны и, бывает, формулируются
 лишь после аварии. Здесь решениям на основе rsync просто нет равных.
-- 
 Eugene Berdnikov

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

[Artem Chuprina]

artiom -> debian-russian@lists.debian.org  @ Fri, 9 Mar 2018 13:47:00 +0300:

 > Выкладываю здесь свой обзор по итогам обсуждения в теме "Backup".
 > Может, кому пригодится.
 > Дополнения и исправления приветствуются.

Спасибо, интересно.

Для себя сделал вывод, что надежнее самопальной конструкции на базе
rsync все-таки ничего не придумали.

Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
надежность и простота восстановления в любом случае важнее.