Re: Backup

[artiom <artiom14@yandex.ru>]

16.02.2018 10:55, Artem Chuprina пишет:
> artiom -> debian-russian@lists.debian.org  @ Fri, 16 Feb 2018 08:43:17 +0300:
> 
>  > Кроме того, rsync использует жёсткие ссылки, не на всех ФС есть.
> 
> Он их использует только на бэкап-сервере. Если же их нет на его ФС, то
> вопрос в непрофильную рассылку :)
> 
Да верно, он же дедупликацию на приёмнике таким образом делает.

>  >>> Также, в перспективе, могут резервироваться машины с Windows и MacOS,
>  >>> возможно Android планшет.
>  >> 
>  >> Вот windows rsync-ом не забэкапишь. Windows я в свое время бэкапил
>  >> ntfsclone способом "перегрузился в linux, создал клон". Но это для
>  >> ситуации когда пользовательские данные в ней не хранятся. 
>  >> 
>  > А может всё-таки Bacula, NextCloud, etc.?
> 
> Этот вопрос надо задавать тем, кто ими пользуется...
> 
Здесь такие есть.

>  >>> На Debian-based машинах хочу резервировать конфигурацию в /etc и
>  >>> выбранные пользовательские данные.
>  >> 
>  >> Меня в свое время убедили что не надо экономить те считанные гигабайты,
>  >> которые занимает /usr и бэкапить и ее тоже. Чтобы потом после
>  >> восстановления не разбираться если версии конфигурации в /etc остались
>  >> от чуточку более старых пакетов, чем поставились из дистрибутива при
>  >> восстановлении системы.Хм... У меня 50 Гб в / (сейчас там же /usr).
>  > Как минимум, две машины (плюс, ещё /opt).
>  > В /usr я руками ничего не правлю обычно (за крайне редким исключением
>  > для Oracle Java на рабочей машине).
>  > /var ещё надо бэкапить. Но /usr для чего?
> 
> Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
> чистый диск не получится. Придется ставить систему и накатывать
> конфиги. И тут упс... система оказалась поновее, конфиги частично
> несовместимы...
> 
Это не столь серьёзная проблема в моём случае: как правило, система
более ли менее новая.

>  >> В общем, анализировать бэкапные решения надо начинать не с "где
>  >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
>  >> процедура восстановления". Причем в двух вариантах 
>  >>
>  > Да, вообще явного анализа восстановления я не провёл.
>  > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
>  > данные, а не образ.
>  > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
>  > машин.
> 
> Практика восстановления показывает, что если бэкапятся настройки
> системы, то лучше бэкапить всю систему. Восстановление работоспособного
> состояния получится на порядок быстрее. Пользовательские данные можно (и
> часто полезно) бэкапить отдельно.
> 
Хорошо, но зачем мне 50+ Гб того, что я и так получу?
Мало того, не всегда мне нужно будет восстанавливать ту же самую
систему: на том же железе и в точности с той же конфигурацией, плюс к
этому, у меня ещё не было ни одного случая, чтобы полностью загнулся Debian.
Падение скорости восстановления здесь для меня терпимо.

>  >> 1. Сдох жесткий диск, вставляем новый
>  >> 2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
>  >> файл, который еще в прошлую субботу точно был.
>  >> 
>  >> Вот по части второго решения на базе rsync вне конкуренции.
>  >> 
>  > А Bacula или OwnCloud чем хуже?
> 
>  > Ещё несколько пунктов для которых процесс восстановления может различаться:
>  > 3. Файл менялся несколько раз, git не было (пусть, это конфиг). Надо
>  > восстановить одно из промежуточных состояний.
>  > 4. Большое количество пользовательских данных оказались повреждены (не
>  > ОС, с ней всё в порядке, а то, на что пользователь имеет права).
>  > 5. Требуется восстановить часть данных с одного устройства на другом (с
>  > целью синхронизации, например).
> 
> При вменяемой системе бэкапа все три пункта - это одно и то же. "Надо
> восстановить такое-то место данных за прошлую субботу, а такое - за
> позапрошлый понедельник. Ой, нет, за понедельник не то, давайте
> попробуем за среду."
> 
Так у меня было на rdiff-backup реализовано, но достаточно медленно
(инкрементальные бэкапы), к тому же, восстановлением таким образом я
пользовался редко.
Хотя, это удобно.
Возможно было заходить в каталоги за день в течение месяца, плюс
использовалось сжатие на базе fuse-compress.
Минус был в несколько сложной настройке. Кроме того, изредка бэкапилка
ломалась, приходилось разбираться (к тому, что не хочется снова делать
своё велосипед, лучше взять промышленно изготовленный).

> Решение с обратно-инкрементальным бэкапом на базе rsync дает этот
> результат бесплатно. Остальные - смотреть надо. Dropbox вот, например
> (если говорить об облачных средствах, которые вообще-то синхронизаторы,
> а не бэкаперы), насколько я вижу интерфейс, дает доступ к версиям
> отдельных файлов, а запросить с него состояние папки на позавчера
> невозможно. Это как бы не его задача.
> 
Хорошо, с этим разобрались: облака - не бэкап, они идут параллельно и
решают другие задачи.

> Средства бэкапа (та же Bacula), по идее, должны давать. Но в свое время
> я не стал настраивать ни ее, ни BackupPC именно из соображений сложной
> настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных
> машин и есть человек, который регулярно подкручивает эту конструкцию. С
> квалификацией админа и наличием _регулярно_ времени на эту работу.
> 
Насколько регулярно и насколько велик объём донастройки?