LINUX.ORG.RU

Какие инструменты для бэкапа лучше использовать?

 


0

4

ЛОР, хочу разодиться очередным высером в бложике, но нужно немножко изучить матчасть прежде чем. за сим спрашиваю у вас сабж.

tar — простой как пять копеек архиватор, можно без проблем схоронить всю систему (корень /) в архив, на другой железке распаковать, прописать загрузчик и всё будет работать как ни в чём небывало.

архив — это один файл, преимущество которого в том, что его можно невозбранно зашифровать, таким же простым как пять копеек способом используя openssl aes-256-cbc -salt, а потом зашифрованный под пароль архив заливается куда угодно: документы вконтакте, облако мэйл.ру, яндекс.диск, гугл драйв... кровавая гэбня не сможет добраться до ваших dotfiles.

однако, у tar имеется фатальный недостаток. он сохраняет не все аттрибуты файлов, такие как xattr и acl, конечно лечится при помощи костылейпачтей, которые являют нам на свет поделие под названием star.

xattr, acl и прочие хипсторские capabilities — да кому они нужны? всю жизнь без них жили-работали в линуксах и норм. ИМХО, вообще пофиг что tar херит их. поделом!

идём дальше. rsync -a -H -A -X, вот оно-то как раз и умеет делать всё. но куда синкать-то? только на свой собственный сервак, а дальше всё, ничего зашифровать нельзя (не будешь же каждый файл шифровать?)... хотя подождите. а что если создать «контейнер» фиксированного размера, отформатировать его в ext4, примонтировать mount -o loop ext4.img /mnt/ext4, затем rsync'ать туда все бэкапы, шифровать контейнер и заливать уже во всякие вконтактики? вроде норм. алсо, rsync это еще и инкрементальные бэкапы.

ЛОР, а я не знаю как быть со всякими частоизменяющимися данными. что если у нас продакшон с кучей разных СУБД в /var крутится, существуют ли инструменты для создания моментальных снимков, чтобы при восстановлении данные не оказались испорчены? или для СУБД следует использовать что-то другое, специальные скрипты для корректного бэкапа баз? а что на выходе? файлик .sql — сценарий с запросами?

ощщем, я и не знаю прям. какой вариант с бэкапами самый правильный?

для локалхоста хватит tar.

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

для чего-то более специфичного типа pgsql, mysql и других субд — что использовать? специализированные инструменты к ним? или как еще делать безопасно бэкап системы целиком.

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 1)

лопату и деревянный ящик

anonymous
()

Объёмная тема

Ну ты тему затронул! Ну смотри, резервные копии мы делаем чтобы восстановить «систему» (какую-то программу, набор сервисов или данных) по состоянию на момент создания копии. Если это файлы, то просто tar'ить или rsync'ать их нельзя, потому что пока ты это делаешь данные могут поменяться. LVM тоже подходит не совсем, потому что делает снимок блочного устройства, а не ФС. Тут надо либо гонять fsck после каждого снятия снимка, либо использовать ФС с атомарными операциями (читай: Reiser4). А если у тебя данные храняться в БД, например MariaDB, то просто сохранение копий файлов не канает, потому что есть ещё содержимое ОЗУ. Нужно использовать инструменты вроде mysqldump. Если же программа хранит данные и в БД, и в файлах, то в общем случае бэкап простыми средствами не сделать. Потому что если делать снимок LVM и mysqldump, то они будут, как ни крути, будут запущены в разные моменты времени, а значит соответствовать разным состояниям программы. Тут надо блокировать кого-нибудь из них на запись, делать снимки, потом разблокировать.

Camel ★★★★★
()
Ответ на: Объёмная тема от Camel

получается, что только полное зеркалирование данных в пару-тройку дополнительных мест спасет отца русской демократии? купил винт, — покупай еще два таких же и зеркалируй.

альтернативный вариант, выключать компьютер, загружаться с live-cd, и делать дамп файловой системы при помощи rsync, а еще лучше при помощи dd чтобы гемороя меньше.

в противном случае, все процессы работающие в памяти (различные sql) бэкапить смысла нет. и только личные данные с которыми работаешь сам и которые не используются другими программами, можно и нужно бэкапить «на горячую» во время работы системы. всякие /home, /etc, /srv

окей, ясно, понятно.

Spoofing ★★★★★
() автор топика
Ответ на: комментарий от Spoofing

Непонятно

получается, что только полное зеркалирование данных в пару-тройку дополнительных мест спасет отца русской демократии?

Нет, не получается. Зеркалирование не спасёт от случайной или злонамеренной порчи данных. Испорченные данные растекутся по всем узлам кластера. Так что всё равно нужны резервные копии.

альтернативный вариант, выключать компьютер, загружаться с live-cd, и делать дамп файловой системы при помощи rsync, а еще лучше при помощи dd чтобы гемороя меньше.

А выключать зачем? Достаточно остановки сервисов.

в противном случае, все процессы работающие в памяти (различные sql) бэкапить смысла нет. и только личные данные с которыми работаешь сам и которые не используются другими программами, можно и нужно бэкапить «на горячую» во время работы системы. всякие /home, /etc, /srv

Таки да, те данные про которые известно, что они не меняются можно просто копировать (свой $HOME, /etc, если ты админ). А бэкапить базы данных можно mysqldump'ом, потому что это не копирование файла БД, а именно снятие снимка состояния БД учитывающее и данные на ФС и в ОЗУ.

Camel ★★★★★
()

У меня на локалхосте rsync на внешний диск, а для шифрования encfs.

anonymous
()
Ответ на: комментарий от anonymous

Снимок для копирования

иногда полезное дополнение к бэкапу, но не спасает от сдохшего диска

Не-не-не, я имел в виду «делать снимок логического тома, монтировать его ФС и копировать с неё данные».

Camel ★★★★★
()

Засунуть систему в загрузочный диск (а лучше собрать с нуля), когда надо, распаковывать squashfs и прописывать загрузчик. Я так себе gentoo восстанавливал.

watashinoshi
()

акронис, по привычке

Deleted
()

Bareos(Bacula) я пока не осилил, duplicity хорошо для мелочи типа хомяка. Серваки можно можно загонять в гипервизоры и пользоваться их средствами. Или zfs + rsync.

FedyaPryanichkov ★★
()

Юзать lvm snapshot + dump/restore уже не молодежно?

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.