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 именно из соображений сложной > настройки. Они, как я понимаю, хороши, когда у вас толпа разнородных > машин и есть человек, который регулярно подкручивает эту конструкцию. С > квалификацией админа и наличием _регулярно_ времени на эту работу. > Насколько регулярно и насколько велик объём донастройки?
