Полный бэкап системы по расписанию

BOJIODbKA

New member
Сообщения
4
#1
Всем привет, на сервере установлен контроллер м.2. Установлена астра линукс воронеж на м.2, смонтирована еще одна м.2. Задача - раз в неделю ночью делать полный бэкап системы с одной м.2 на вторую, чтобы в случае выхода из строя одной плашки м.2 можно было загрузиться со второй. Как это организовать?
 

Alex-der

New member
Сообщения
130
#6
Всем привет, на сервере установлен контроллер м.2. Установлена астра линукс воронеж на м.2, смонтирована еще одна м.2. Задача - раз в неделю ночью делать полный бэкап системы с одной м.2 на вторую, чтобы в случае выхода из строя одной плашки м.2 можно было загрузиться со второй. Как это организовать?
Первый раз - dd (man dd), потом, по расписанию - tar (man tar), не? tar позволит минимизировать запись на вторую ssd-шку.
 

Alex-der

New member
Сообщения
130
#7
Soft-RAID можно сделать на любых носителях, хоть в файл. Причём, в линуксе это делается на ядрёном модуле - после первой настройки думать о том, как оно там работает уже необязательно. Но помнить надо!...
 

Карл

New member
Сообщения
501
#8
Первый раз - dd (man dd), потом, по расписанию - tar (man tar), не? tar позволит минимизировать запись на вторую ssd-шку.
врятли это возможно при рабочей системе - т.к. во время работы dd|tar|rsync ужt будет изменения основного диска, а еще второй диск ТС хочет иметь загрузочным
 

Alex-der

New member
Сообщения
130
#9
врятли это возможно при рабочей системе - т.к. во время работы dd|tar|rsync ужt будет изменения основного диска, а еще второй диск ТС хочет иметь загрузочным
???
Принципиальных проблем не будет. dd сделает второй диск загрузочным, а tar потом будет накатывать недельные изменения. Какие критичные/принципиальные изменения ФС могут происходить во время процесса ? своп? темп? вар? Оно точно критично?
 

Карл

New member
Сообщения
501
#10
???
Принципиальных проблем не будет. dd сделает второй диск загрузочным, а tar потом будет накатывать недельные изменения. Какие критичные/принципиальные изменения ФС могут происходить во время процесса ? своп? темп? вар? Оно точно критично?
1. я не знаю какие могут быть проблемы, но вполне могут, тестировать все это надо т.е. это не готовое решение
2. если днем будет установка обновление ядра - все корректно сделает tar ночью на второй диск ?
3. тут скорее не tar нужен, а rsync с опцией удаления со второго диска файлов, которых уже нет на первом

ТС предстоит всё это проверять самостоятельно )
 

oko

New member
Сообщения
1 254
#11
*в сторону*
Если сервер можно вырубить 1 раз в неделю на допустимое время, то лучше автозапуска LiveCD с dd с нужными параметрами bs и проч. (после бэкапа перезагрузить в целевую ОС) никто придумать не сможет - полная копия без обиняков...
Если же сервер должен работать 24/7 + обслуживать "клиентов" в период "прозрачного" бэкапа на случай сбоя + чтобы время его восстановления == перезагрузке с нужного накопителя, то... проще потратить пару дней и переставить все на вменяемый RAID10 (хоть mdadm, хоть аппаратный с защитой write и неплохим кэшем). И спать спокойно с инкрементальным бэкапом любыми доступными средствами. Хоть rsync, хоть tar, хоть прости Шеннон Rubackup какой-нибудь...
А если дополнительно задуматься о возможности целевого воздействия на такой сервер, то идея с еженедельным полным бэкапом байт-в-байт начинает пахнуть тухлятиной - "зараза" сейчас умная, может и недельку, и месяц подождать перед активацией вредоносных функций, ага...
 

BOJIODbKA

New member
Сообщения
4
#12
*в сторону*
Если сервер можно вырубить 1 раз в неделю на допустимое время, то лучше автозапуска LiveCD с dd с нужными параметрами bs и проч. (после бэкапа перезагрузить в целевую ОС) никто придумать не сможет - полная копия без обиняков...
Если же сервер должен работать 24/7 + обслуживать "клиентов" в период "прозрачного" бэкапа на случай сбоя + чтобы время его восстановления == перезагрузке с нужного накопителя, то... проще потратить пару дней и переставить все на вменяемый RAID10 (хоть mdadm, хоть аппаратный с защитой write и неплохим кэшем). И спать спокойно с инкрементальным бэкапом любыми доступными средствами. Хоть rsync, хоть tar, хоть прости Шеннон Rubackup какой-нибудь...
А если дополнительно задуматься о возможности целевого воздействия на такой сервер, то идея с еженедельным полным бэкапом байт-в-байт начинает пахнуть тухлятиной - "зараза" сейчас умная, может и недельку, и месяц подождать перед активацией вредоносных функций, ага...
Сервер нужен с 8 до 18, в остальное время можно вырубать.
Какой вариант всё же лучше?
 

Карл

New member
Сообщения
501
#13
есть сомнения что после dd загрузка со второго диска пройдет успешно т.к. их имена из в /dev/ могут не совпадать (см. также fstab), а установлены они в разные разъемы, имеют разные серийные номера

я бы делал так:
1. как самый надежный вариант - https://clonezilla.org/show-live-doc-content.php?topic=clonezilla-live/doc/03_Disk_to_disk_clone, 1 раз в неделю это сделать можно
2. искать чтото еще, если п.1 не устраивает
 

Alex-der

New member
Сообщения
130
#14
Какой вариант всё же лучше?
Вы практически ничего не сказали о бюджете вашей задачи. Если деньги есть - можно хоть акронис повыбирать, хоть Commvault или (Net|Ru)Backup какой-нибудь в рамках бюджета. Если денег не дают и костылить предполагается самостоятельно, то - man tar, nan rsync - сравниваем (не)возможности, думаем и решаем для себя, что вам конкретно лучше.
 
Последнее редактирование:

Alex-der

New member
Сообщения
130
#15
есть сомнения что после dd загрузка со второго диска пройдет успешно т.к. их имена из в /dev/ могут не совпадать (см. также fstab), а установлены они в разные разъемы, имеют разные серийные номера
Ну, коллега! Давайте оставим товарищу хоть какую-то возможность пожевать самостоятельно, а то он так и глотать разучится...
Тут главное, на мой взгляд, чтобы система (ядро) вообще со второго диска загрузила(о)сь, а подправить fstab уже и в singleuser можно. Если у товарища, как он утверждает, fulluptime не критичен, он может позволить себе провести эксперимент, отключив вечерком основной диск, загрузиться с бэкапа, подправить необходимые конфиги, чтобы взлетало без ручного вмешательства, и исключить эти конфиги из перезаписи. Я не думаю, что fstab будет меняться часто, а в остальном точек затыка я не вижу.

ЗЫ: Я не видел клонзиллу, но подозреваю, что имена дисков он тоже не клонирует. Разделов - может быть, но там тоже есть подводные камни: не могут, согласно fstab разделы иметь одинаковые uuid-ы, иначе как ядро поймёт, с какого диска раздел надо монтировать.
 

oko

New member
Сообщения
1 254
#16
to Карл
Это может быть, если в fstab UUID прописаны, а если по-старинке /dev/sd (или /dev/nvme и т.п. - хз, что там за M2-диск у топикстартера), то никакой проблемы. Сдох первый диск, выдернули его, запустились, полетели (на крайний случай воткнули запасной клонированный в разъем первого)...

to Alex-der

Про жевать и глотать улыбнуло :)
 

Карл

New member
Сообщения
501
#17
Ну, коллега! Давайте оставим товарищу хоть какую-то возможность пожевать самостоятельно, а то он так и глотать разучится...
да не нужен он, теперь мы далее обсуждаем сами для себя )

клонезилла может uuid и переписать и скорректировать, это всеже не тупой dd )
 

oko

New member
Сообщения
1 254
#19
to Карл
Знаю. Но никто же не мешает слепить собственный велосипед под конкретную задачу...
 

BOJIODbKA

New member
Сообщения
4
#20
Вы практически ничего не сказали о бюджете вашей задачи. Если деньги есть - можно хоть акронис повыбирать, хоть Commvault или (Net|Ru)Backup какой-нибудь в рамках бюджета. Если денег не дают и костылить предполагается самостоятельно, то - man tar, nan rsync - сравниваем (не)возможности, думаем и решаем для себя, что вам конкретно лучше.
Бюджета 0. Спасибо за советы.