[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Backup



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 для чего?

Сказали же: если его нет в бэкапе, то восстановиться, раскатав бэкап на
чистый диск не получится. Придется ставить систему и накатывать
конфиги. И тут упс... система оказалась поновее, конфиги частично
несовместимы...

 >> В общем, анализировать бэкапные решения надо начинать не с "где
 >> хранить" и "какой транспорт использовать" а с "как будет выглядеть
 >> процедура восстановления". Причем в двух вариантах 
 >>
 > Да, вообще явного анализа восстановления я не провёл.
 > Неявно, подразумеваю, что буду переустанавливать систему и накатывать
 > данные, а не образ.
 > Т.е., мне не требуется "полный бэкап", как это делают с большим парком
 > машин.

Практика восстановления показывает, что если бэкапятся настройки
системы, то лучше бэкапить всю систему. Восстановление работоспособного
состояния получится на порядок быстрее. Пользовательские данные можно (и
часто полезно) бэкапить отдельно.

 >> 1. Сдох жесткий диск, вставляем новый
 >> 2. Обнаружилось, что мы случайно стерли/испортили чрезвычайно ценный
 >> файл, который еще в прошлую субботу точно был.
 >> 
 >> Вот по части второго решения на базе rsync вне конкуренции.
 >> 
 > А Bacula или OwnCloud чем хуже?

 > Ещё несколько пунктов для которых процесс восстановления может различаться:
 > 3. Файл менялся несколько раз, git не было (пусть, это конфиг). Надо
 > восстановить одно из промежуточных состояний.
 > 4. Большое количество пользовательских данных оказались повреждены (не
 > ОС, с ней всё в порядке, а то, на что пользователь имеет права).
 > 5. Требуется восстановить часть данных с одного устройства на другом (с
 > целью синхронизации, например).

При вменяемой системе бэкапа все три пункта - это одно и то же. "Надо
восстановить такое-то место данных за прошлую субботу, а такое - за
позапрошлый понедельник. Ой, нет, за понедельник не то, давайте
попробуем за среду."

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

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


Reply to: