Remastersys + CLI-server =/= BackUp ?

Разве tar -cvvapf /somewhere/backup.tar.xz --one-file-system / для «бекапа системы без отключения» не достаточно?

В нашем случае нет, так как данные на сервере меняются практически постоянно, а об аналогах теневого копирования форточек в мире туксов я ничего не слышал...

данные на сервере меняются практически постоянно

Тогда чем Remastersys лучше? Он никак не блокирует данные перед архивацией. Вы не получаете никаких преимуществ перед tar в этом.
Кроме того, Вам нужно бекапить данные, или операционную систему? Это лучше делать отдельными операциями.

аналогах теневого копирования форточек

LVM snapshot?

О технологии Remastersys я пока ничего не знаю, поэтому не могу сказать будет она блочить данные перед бэкапом или нет. Бэкапить нужно всю ОСь целиком, вместе с данными (которые едва-ли не постоянно перезаписываются).

Про LVM знаю, читал и даже пробовал, но не пошло. К тому же у нас сервера стоят не на LVM, и переносить их туда - ещё та головная боль.

P.S. а ещё на этих серверах нет графической стеды. Им вполне достаточно cli, и хотелось бы избежать лишней траты ресурсов.

О технологии Remastersys я пока ничего не знаю, поэтому не могу сказать будет она блочить данные перед бэкапом или нет.

Почитайте /usr/bin/remastersys, это обычный shell-скрипт:

rsync --exclude='*.log.*' --exclude='*.pid' --exclude='*.bak' --exclude='*.[0-9].gz' --exclude='*.deb' $VAREXCLUDES-a /var/. $WORKDIR/dummysys/var/.
rsync $VAREXCLUDES-a /etc/. $WORKDIR/dummysys/etc/.
<чистка логов, кэша и конфигов>
mksquashfs $WORKDIR/dummysys/ $WORKDIR/ISOTMP/live/filesystem.squashfs -no-duplicates $SQUASHFSOPTSHIGH 2>>$WORKDIR/remastersys.log
<...>
mksquashfs / $WORKDIR/ISOTMP/live/filesystem.squashfs -no-duplicates $SQUASHFSOPTSHIGH -e \
.thumbnails \
.cache \
.bash_history \
Cache \
boot/grub \
dev \
etc \
media \
mnt \
proc \
sys \
tmp \
var \
$WORKDIR $EXCLUDES 2>>$WORKDIR/remastersys.log

Никаких блокировок найти не удаётся.

Я подозревал что это скрипт, когда смотрел на процесс работы, но не было времени найти его и как следует изучить. В любом случае - tar_gz, как и rsync не дают нам гаранитии отсутствия повреждений у файлов в архиве, а переход на LVM с полного ноля знаний и опыта постыдно ссыкотен.

Конечно, можно перелопатить fstab и вырезав UUID`ы обходиться tar`ом, заливающим данные на сетевое хранилище, но проблема остаётся. Чем тогда можно автоматически бэкапить живущую систему с логированием процесса?

Есть идеи?

P.S. где можно найти хорошую доку про бэкап_И_ВОССТАНОВЛЕНИЕ из снапшотов LVM на русском языке?

используй zfs.

я потихоньку внедряю у себя.

Может быть, данные нужно бекапить средствами того, что их хранит? Это база данных? Файловое хранилище?

Доков, к сожалению, под рукой нет. На http://xgu.ru/wiki/LVM есть описание процедуры бекапа и ссылки на статьи на английском.
Фокус снапшотов состоит в том, что они делаются только на время записи бекапа, так что восстановление делается уже не из снапшота, а из снятой с него копии (например, такого же архива.tgz).

Об этом я и сам знаю. Сделали снап, примонтировали его и бэкапим, а система в это время работает. Но фишка в том что в сети полно статей как сделать бэкап через LVM, а вот о восстановлении все как-то забывают написать хоть пару строк...

Похоже на btrfs. Есть ссылки на статьи с описанием восстановления из таких бэкапов? (Только не на буржуйском - мне всё ещё тяжело даётся чтение мануалов на чужом языке.)

тред не читай@rsync отвечай

А зачем вообще иксы на сервере? Remastersys не панацея. И вообще данное ПО не для бэкапа. Если вам нужно теневое копирпование, вам нужны снэпшоты. LVM или Btrfs вам в помощь. Это для бэкапа всей системы. Просто данные можно жать таром, и не изобретать велосипед. Remastersys создаёт копию вашей файловой системы, в squashfs, но далеко не полную. Чистит кеш, удаляет временные файлы, не сохраняет ту часть файловой системы, которую ядро и сервисы создают на лету(/dev и т.п.). В общем, я не считаю результат деятельности данного ПО бэкапом. И оно ничего не блокирует, тупо жмёт как и tar с gzip или xz.

Развивая приведенный пример, предположим, что нам нужно выполнить резервирование базы данных. Для этой задачи мы будем использовать устройство-«снапшот». Этот тип устройства представляет собой доступную только на чтение (при использовании опции --permission r) копию другого тома на момент выполнения процедуры «снапшот». Это дает возможность продолжать работу не заботясь о том, что данные могут измениться в момент резервного копирования. Следовательно, нам не нужно останавливать работу базы данных на время выполнения резервного копирования. Остановка нужна только на момент создания устройства-«снапшот», который значительно короче самого копирования.

Резервное копирование при помощи «снапшотов»

а вот о восстановлении все как-то забывают написать хоть пару строк...

В общем случае вот:

dd if=/patch/to/snapshot of=/patch/to/dev bs=8M

А зачем вообще иксы на сервере?

А представьте себе - некоторые сервисы всё-таки требуют графического управления. Я бы и сам рад отказаться от оболочки, но современные программисты порой вообще забывают о функциональности CLI, и пишут такой софт, который из shell можно только запустить или убить, а все настройки реализуются только через GUI, ибо в конфигах изобилуют множественные хэши, странные, не документированные букво-цифры, непонятные диалекты чего-то в роде собственного XML и тому подобное, что делает невозможным настройку из CLI в принципе.

P.S. Иногда мне кажется что эта аномалия памяти программистов вообще искуственного рода. Насаждается извне. На подобии паскаля/делфи под фортачками как «единственно верного пути программирования!»

Буду курить маны по поддерживающим снепшоты ФС, но вот ещё нарыл чудо: BackupPC и fwbackups.

Про первую даже есть статья на русской вики. Радует наличие web-морды, SSH и возможность работы с tar и rsync. Но на сколько я понимаю, и tar и rsync не дадут полноценной замены «теневого копирования». А использует-ли эта программа блокировку копируемых данных - просто неизвестно.

О второй программе известно гораздо меньше. Существует как в deb (для х86 и х64), так и в exe. Понимает только SSH (но никто не отменял монтирование внешних ФС в локальную структуру каталогов...). Принцип действия неизвестен.

Стоит-ли обращать на них внимание? Всё-таки по понятным причинам мне очень хочется обойтись без необходимости переустановки ОС на серверах... А теневое копирование однозначно потребует новых ФС или, даже, LVM.

В случаем с LVM Вам не стоит думать о том какой софт работает и как. Для предосторожности достаточно на момент включения режима snapshot приостановить приложение.

К сожалению все случаи без LVM, на мой взгляд, это околесица.

По какой причине околесица? Если ФС поддерживает снепшоты (типа btrfs), то можно сделать снап, потом примонтировать его и бэкапить, по окончании отмонтировать и удалить снап (или лставить). По возможностям бэкапа это почти полный аналог теневого копирования через LVM. Или я что-то упустил?

Я за этими фактами не уследил, простите. Я имел ввиду это:

Для тех, кто не знает: Remastersys создаёт из живой системы live-iso образ

А раз Btrfs позволяет то можно наверное. Надо изучать вопрос, насколько это отлажено работает:

Btrfs включена в основную ветвь ядра Linux начиная с версии 2.6.29-rc,[5] но остаётся экспериментальной и не готова для промышленного использования. В июне 2010 года разработчики не рекомендовали использовать данную ФС ни для чего кроме тестирования, так как, по словам одного из разработчиков, она «могла съесть ваши данные» (англ. may eat your data).[9]

Кстате вот

Спасибо. Интересно было.

Если сложно инфраструктуру переделывать то может обратиться к Acronis Backup & Recovery 11.5 Server for Linux.

Мы как раз по этой причине и стали искать аналоги... У нас сейчас 2 сервера, и планируется расширение парка.

На текущий момент решили обойтись тарболами без БД - их позже средствами самого sql слить можно. Понимаю всю кастыльность метода, но, похоже, чего-то бОльшего ждать не приходится.

У нас сейчас 2 сервера, и планируется расширение парка.

Самое время спроектировать «правильный бэкап»

На текущий момент решили обойтись тарболами без БД - их позже средствами самого sql слить можно.

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

К сожалению, о том и речь. Дядю Акроню закупать не охота, а готовых систем онлайн бэкапа для линукс словно и нет и не было и не будет. LVM, конечно, штука хорошая, но её ещё освоить надо, а начать делать бэкапы стоило уже вчера, плюс переустановка сервера со всем что на него навешано - не быстрое дело. В это же время Zfs & BTRfs как-то пугают статусами «бэт», заявлениями о «поедании файлов» и отсутствием поддержки уровня ядра из коробки. Остаются добрые друзья tar, dump, dd, rsync...

Так же рассматривал bacula. По всей видимости, приётся её отвергнуть:

Для индивидуального применения лучше подыскать другую программу (эта слишком тяжела в развёртывании), зато после настройки работает в полностью автоматическом режиме. Плохо переносит резкие смены конфигурации (как убрать все упоминания об удалённом клиенте, его заданиях и томах?). Плохая обработка ошибок при работе с диском (заполненный диск, глюки с созданием нового тома при наличии файла) и сетью, перезагрузке серверов и клиентов, завершившиеся с ошибкой задания остаются в БД навсегда (и, вообще, БД не чистится от мусора). Хорошо хоть оператора извещает. Много ручной работы (беготня по меню), нет создания нескольких копий одновременно, нет консолидации частично заполненных носителей, нет автоматического обнаружения новых серверов, файловых систем, СУБД. Ручная установка как серверов, так и клиентов. Средства перехода на новую версию - вручную. Требуется LD_ASSUME_KERNEL=2.4.19 для запуска в RH с ядром 2.4 (проблема с нитями).

Своя система аутентификации и авторизации для администраторов с возможностью разбивки по ролям и областям ответственности, учёт действий пользователей. Для аутентификации между процессами используется CRAM-MD5, обеспечивающий достаточный уровень защиты, пароли не передаются, но хранятся в открытом виде. Передаваемые между серверами данные можно шифровать с помощью TLS. В версии 3 добавлена возможность аутентификации с помоью TLS. Шифровка данных на стороне клиента в версии 2.

Высокая скорость (наличие каталога с информацией о местонахождении требуемого файла) и лёгкость восстановления (поиск по имени, времени). Слабая защита «от дурака» в текстовой версии. Независимость восстановления от платформы в версии 2 (с потерей атрибутов). Возможность восстановления на другой хост, другой каталог (и возможность ограничить это).

И так далее... Не очень радует такая перспектива.

Каждому Вашему слову могу возразить, только смысла не вижу. Я вижу для Вас два возможных варианта:

• Перепроектирование инфраструктуры. Тщательная проработка и внедрение системы бэкапов;
• Использование чего-то готового, типа Acronis.

Выбора особого нет. Только выбор готовой продукции. А если не прокатывает - самопал@кастыль. Это не мне решать.

Нарыл скрипт, бэкапящий инкрементально tar`ом. Довольно полезная штука в нашей ситуации, но это очередной кастыль.