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

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

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

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


Системы резервного копирования
------------------------------

Проприетарные закрытые решения типа Veeam не рассматриваются, по
условиям политики безопасности.

### Решения на базе unix-утилит

[Решения на основе rsync, tar, rdiff-backup,
etc.](http://www.mikerubel.org/computers/rsync_snapshots/) не
рассматриваются
по причине большого количества работы, которую потребуется выполнить, и
отсутствия необходимого WEB-интерфейса.


### Bareos

[BareOS (Backup Archiving Recovery Open
Sourced)](https://www.bareos.org/en/) - форк Bacula с 2010 года.

Плюсы:

- Стабильная отлаженная система.
- Поддерживает несколько типов агентов под разные ОС.
- Поддерживает различные типы бэкапа: инкрементальный, дифференциальный,
полный.
- WEB-интерфейс очень развит и функционален.
- Гибкая конфигурация.
- Имеется FUSE драйвер, который показывает бэкапы.
- Есть обвязка для Python, позволяющая взаимодействовать с Director.
- Есть агенты для бэкапа специфичных приложений (например, СУБД).
- Все коммуникации между различными компонентами системы аутентифицируются.
- Интеграция с FreeNAS.
- Поддержка большого количества систем хранения.

Минусы:

- Ориентация на ленточный бэкап.
- Многокомпонентная запутанная система.
- Сложная и запутанная конфигурация.
- Требует постоянной поддержки, в случае минимальных изменений.
- Документация обширная (500+ страниц), но несмотря на это, настройка
под типовой вариант использования сложна и занимает много времени.


### BackupPC

[BackupPC](http://backuppc.sourceforge.net) - безагентная система
резервного копирования.

Плюсы и возможности:

- Возможен бэкап без агентов.
- Полные и инкрементальные бэкапы.
- Есть WEB-интерфейс.
- Минимизирует количество дисковых операций.
- Дедупликация. Одинаковые файлы сохраняются однократно, даже если это
файлы на разных машинах.
- Возможность сжатия данных.
- Не нужен клиент, могут использоваться SMB, rsync.
- Возможность восстановления файлов прямо через WEB-интерфейс.
- Возможно восстановить как конкретные файлы, так и скачать все файлы
архивом.
- Гибкая конфигурация, как системная, так и отдельная для каждой машины.
- Возможность посылать уведомления.

Минусы:

- Реализован на Perl, требует установки CPAN.
- Безагентный бэкап менее гибок, чем бэкап через агента, хотя и более
безопасен.
- Нельзя выбрать время начала копирования (компенсируется выбором
периодов, когда делать копирование запрещено).


### UrBackup

[UrBackup](https://www.urbackup.org) - клиент-серверная система
резервного копирования.
Поддерживает FreeNAS.

Плюсы и возможности:

- Простая настройка.
- Есть WEB-интерфейс.
- Полные и инкрементальные бэкапы.
- Файловые бэкапы и бэкапы разделов (в т.ч. инкрементальные).
- Клиенты для Windows, Linux, MacOS X.
- Быстрая дедупликация на клиенте: быстро вычисляются изменения в
дереве, и передаются только новые файлы или сектора диска.
- Бэкап разделов при запущенной системе.
- Возможность бэкапа каталогов при изменении.
- Корректные бэкапы используемых приложениями файлов (например, баз
Outlook, клиент знает о распространённых приложениях).
- Дедупликация. Одинаковые файлы сохраняются однократно, даже если это
файлы на разных машинах.
- Настройки бэкапов (частоту, количество и т.п.) клиент может менять для
себя.
- Простая настройка.
- Предупреждение клиента о том, что бэкап не был сделан.
- Возможно восстановить как конкретные файлы, так и скачать все файлы
архивом.
- Возможность посылать уведомления.
- Безопасные и эффективные бэкапы через Internet.
- Метаданные файлов (например, время изменения) сохраняются.
- Поддержка квот на размер бэкапов.
- Простое восстановление бэкапа раздела (например, через подключенную
USB флешку).
- Автоматическое обновление.

Минусы:

- Клиент под Windows, способный отслеживать изменения блоков, платный.
- Бэкап разделов работает только с NTFS.


### Restic

[Restic](https://restic.net/) - инструмент для резервного копирования и
восстановления с консольным интерфейсом.

Плюсы и возможности:

- Простая настройка.
- Использует шифрование для шифрования резервных копий.
- Дедупликация. Одинаковые файлы сохраняются однократно, даже если это
файлы на разных машинах.
- Нет понятия полного/инкрементального бэкапа. Все они равноценные.
Передаются только новые блоки.
- Все данные и метаданные защищены контрольными суммами. Возможность
проверки корректности бэкапа.
- Сервера бэкапа нет.
- Имеется FUSE драйвер, который показывает бэкапы в виде иерархии host/дата.

Минусы:

- WEB-интерфейса нет.
- Требователен к RAM (~2.7GB на 1TB).
- Не сохраняет ACL и расширенные атрибуты.
- Медленное и требовательное к RAM удаление ненужных бэкапов.
- Удаление ненужных бэкапов блокирует работу (производить бэкап в это
время невозможно).
- Ключи шифрования одни на все хосты (в общем случае любой хост может
прочитать все бэкапы). Проблема может быть решена.
- Медленное восстановление с помощью стандартного интерфейса restic.


### Borgbackup

[BorgBackup](https://www.borgbackup.org/) - дедуплицирующая программа
для резервного копирования.

Плюсы и возможности:

- Серверной части нет.
- Эффективное использование дискового пространства для хранения
резервных копий.
- Достаточно высокопроизводителен (основной код на Python, но критичные
участки реализованы на C и оптимизированы).
- Шифрование.
- Сжатие: LZ4, zlib, LZMA.
- Имеется FUSE драйвер, который показывает бэкапы.
- Простая установка на различные платформы: Linux, macOS, BSD, etc.
- [Есть WEB-интерфейс, как отдельный
проект](https://borgweb.readthedocs.io/en/latest/).
- Поддерживается большим сообществом разработчиков.

Минусы:

- WEB-интерфейс достаточно ограниченный.
- Нет прямой поддержки ОС Windows (только через Linux subsystem или cygwin).


### lsyncd

[Lsyncd](https://github.com/axkibe/lsyncd) - демон, выполняющий
резервирование изменяемых файлов через rsync.

Плюсы и возможности:

- Использует inotify или fsevents для наблюдения за каталогом. После
истечения времени вызывает rsync для копирования изменений.
- Может использовать не только rsync.
- Реализован на Lua, конфиг процедурный тоже на Lua.
- Почти не снижает производительной локальной ФС.
- Гибко настраивается.

Минусы:

- Легковесная система. Не имеет WEB-интерфейса и централизованной настройки.

Reply | Threaded
Open this post in threaded view
|

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

Artem Chuprina-4
artiom -> [hidden email]  @ Fri, 9 Mar 2018 13:47:00 +0300:

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

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

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

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

Reply | Threaded
Open this post in threaded view
|

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

Eugene Berdnikov
On Fri, Mar 09, 2018 at 06:36:44PM +0300, Artem Chuprina wrote:

> artiom -> [hidden email]  @ Fri, 9 Mar 2018 13:47:00 +0300:
>
>  > Выкладываю здесь свой обзор по итогам обсуждения в теме "Backup".
>  > Может, кому пригодится.
>  > Дополнения и исправления приветствуются.
>
> Спасибо, интересно.
>
> Для себя сделал вывод, что надежнее самопальной конструкции на базе
> rsync все-таки ничего не придумали.
>
> Хотя, конечно, дедупликацию к ней добавить было бы приятно... Но
> надежность и простота восстановления в любом случае важнее.

 +1

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

Reply | Threaded
Open this post in threaded view
|

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

artiom
In reply to this post by Artem Chuprina-4


09.03.2018 18:36, Artem Chuprina пишет:

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

Reply | Threaded
Open this post in threaded view
|

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

Artem Chuprina-4
artiom -> [hidden email]  @ Sun, 11 Mar 2018 10:19:04 +0300:

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

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

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

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

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

Reply | Threaded
Open this post in threaded view
|

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

Павел Марченко-2
In reply to this post by artiom
+1 поэтому такие системы и существуют, чтобы не городить велосипед, каждый раз как нужно что-то забэкапить. А если у вас тысячи серверов, которые нужно бэкапить? 

11 мар. 2018 г. 10:20 пользователь "artiom" <[hidden email]> написал:


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


Reply | Threaded
Open this post in threaded view
|

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

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

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

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

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

Reply | Threaded
Open this post in threaded view
|

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

Stanislav Vlasov-2
In reply to this post by Artem Chuprina-4
9 марта 2018 г., 20:36 пользователь Artem Chuprina <[hidden email]> написал:

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

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

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

--
Stanislav
Reply | Threaded
Open this post in threaded view
|

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

Victor Wagner
On Mon, 12 Mar 2018 13:56:31 +0500
Stanislav Vlasov <[hidden email]> wrote:

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

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

--  

Reply | Threaded
Open this post in threaded view
|

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

Stanislav Vlasov-2
12 марта 2018 г., 13:59 пользователь Victor Wagner <[hidden email]> написал:

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

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

--
Stanislav
Reply | Threaded
Open this post in threaded view
|

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

Artem Chuprina-4
In reply to this post by Victor Wagner
Victor Wagner -> [hidden email]  @ Mon, 12 Mar 2018 11:59:09 +0300:

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

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

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

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

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

Reply | Threaded
Open this post in threaded view
|

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

yuri.nefedov
Victor Wagner -> [hidden email]  @ Mon, 12 Mar 2018
11:59:09 +0300:
...
> > Лет десять назад именно Артем Чуприна научил меня пользоваться
> > rsnapshot. Поэтому полагаю, что под дедупликацией он имеет в виду
> > что-то другое, чего rsnapshot не умеет.
...
On Mon, 12 Mar 2018, Artem Chuprina wrote:

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

Ю.
Reply | Threaded
Open this post in threaded view
|

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

Eugene Berdnikov
On Mon, Mar 12, 2018 at 08:07:14PM +0800, [hidden email] wrote:

> Victor Wagner -> [hidden email]  @ 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

Reply | Threaded
Open this post in threaded view
|

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

yuri.nefedov
On Mon, 12 Mar 2018, Eugene Berdnikov wrote:

> On Mon, Mar 12, 2018 at 08:07:14PM +0800, [hidden email] wrote:
>> Victor Wagner -> [hidden email]  @ 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 маковской подошло бы.

Ю.
Reply | Threaded
Open this post in threaded view
|

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

artiom
In reply to this post by Павел Марченко-2
Я думаю, мой "парк" не разрастётся более десятка машин.
Но я хочу иметь удобный web-интерфейс и единую точку контроля.
Иначе, зачем я собираю устройство, второй основной задачей которого
является бэкап?

11.03.2018 11:15, Павел Марченко пишет:

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

Reply | Threaded
Open this post in threaded view
|

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

artiom
In reply to this post by Stanislav Vlasov-2


12.03.2018 11:56, Stanislav Vlasov пишет:

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

Reply | Threaded
Open this post in threaded view
|

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

artiom
In reply to this post by Artem Chuprina-4


12.03.2018 12:27, Artem Chuprina пишет:

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

Reply | Threaded
Open this post in threaded view
|

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

artiom
In reply to this post by yuri.nefedov


12.03.2018 15:07, [hidden email] пишет:

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

Reply | Threaded
Open this post in threaded view
|

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

Artem Chuprina-4
In reply to this post by artiom
artiom -> [hidden email]  @ Wed, 14 Mar 2018 20:58:21 +0300:

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

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

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

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

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

Reply | Threaded
Open this post in threaded view
|

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

Victor Wagner
In reply to this post by artiom
On Wed, 14 Mar 2018 20:51:12 +0300
artiom <[hidden email]> wrote:

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

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


12