Помогите с backup ОС

KRUTO, Накатай инструкцию... другим понадобится. Только если будешь писать, пиши подробно. Приклеим тему и все ок.

--=XliN=--,
С удовольствием напишу, т.к. часто пишу себе заметки, чтобы не забыть...
В виде сообщения прикрепить???

Кстати, для копирования backup на удаленную машину, кто чем пользуется?? Сейчас выбираю из:
1) ssh по открытому ключу
2) rsync
Первое не нравится возможностью входа без пароля
Второе не нравится тем, что rsync надо запускать в режиме демона и входить по паролю, который хранится в открытом виде... Насколько это безопасно?

KRUTO написал:

В виде сообщения прикрепить???

Ты сделай, а мы прикрепим :D

KRUTO написал:

Кстати, для копирования backup на удаленную машину, кто чем пользуется?? Сейчас выбираю из:
Второе не нравится тем, что rsync надо запускать в режиме демона и входить по паролю, который хранится в открытом виде... Насколько это безопасно?

Значит, не читали man rsync. По умолчанию он работает через ssh. Если, конечно скомпилён с его поддержкой. НО здесь уже пинайте мейнтейнера, если не поддерживает

KRUTO написал:

Кстати, для копирования backup на удаленную машину, кто чем пользуется?? Сейчас выбираю из:
1) ssh по открытому ключу
2) rsync
Первое не нравится возможностью входа без пароля
Второе не нравится тем, что  rsync надо запускать в режиме демона и входить по паролю, который хранится в открытом виде... Насколько это безопасно?

если все дело происходит в рамках одной сети, то это безопасно, пароль будут знаь только 2 человека или один даже. Далее можно пользоваться следующей схемой:
1)сервер с nfs или cifs
2) монтируем шару на локальной машинке
3) делаем бэкап в шару с помощью tar
4) и запускать все это дело по крону или анакрону
Тяжеловесы: amanda или bacula smile

man rsync
There are two different ways for rsync to contact a remote system:
using a remote-shell program as the transport (such as ssh or rsh) or
contacting an rsync daemon directly via TCP. The remote-shell trans-
port is used whenever the source or destination path contains a single
colon (:) separator after a host specification. Contacting an rsync
daemon directly happens when the source or destination path contains a
double colon (::) separator after a host specification, OR when an
rsync:// URL is specified (see also the “USING RSYNC-DAEMON FEATURES
VIA A REMOTE-SHELL CONNECTION” section for an exception to this latter
rule).
Где написано, что через ssh, ткните пальцем? Я же имел в виду:

KRUTO написал:

Второе не нравится тем, что rsync надо запускать в режиме демона и входить по паролю, который хранится в открытом виде... Насколько это безопасно?

KRUTO написал:

Второе не нравится тем, что  rsync надо запускать в режиме демона и входить по паролю, который хранится в открытом виде... Насколько это безопасно?

сделайте между хостами вход по ключам, и запускайте через cron команду rsync blablabla используя ssh, в чем проблема то? oO

i2ks написал:

сделайте между хостами вход по ключам, и запускайте через cron команду rsync blablabla используя ssh, в чем проблема то?

Не -- это понятно, но можно пользоваться же запуском rsync в режиме демона на машине, куда сохраняешь backup и входом по парольному файлу: примерно так:
rsync -r user123@192.168.1.1::images /live/images --password-file rsync.pwd
Но парольный файл rsync.pwd содержит пароль в открытом виде.
А вход по ключам в одной подсети безопасен при том, что одна из машин смотрит в инет напрямую??

i2ks,
Стоит ли вообще смотреть в сторону amanda и bacula -- или это всё заморочки???? Мне кажется проще tar+rsync???

KRUTO написал:

Стоит ли вообще смотреть в сторону amanda и bacula -- или это всё заморочки???? Мне кажется проще tar+rsync???

Если бекапить от 100 и выше серверов, то стоит посмотреть на bacula или amnda, если <50 то tar+rsync хватит за глаза, хотя даже с помощью тара можно делать инкрементальыне бекапы.

i2ks,
Не -- это понятно, но можно пользоваться же запуском rsync в режиме демона на машине, куда сохраняешь backup и входом по парольному файлу: примерно так:
rsync -r user123@192.168.1.1::images /live/images --password-file rsync.pwd
Но парольный файл rsync.pwd содержит пароль в открытом виде.
А вход по ключам в одной подсети безопасен при том, что одна из машин смотрит в инет напрямую??

KRUTO написал:

Не -- это понятно, но можно пользоваться же запуском rsync в режиме демона на машине, куда сохраняешь backup и входом по парольному файлу: примерно так:
rsync -r user123@192.168.1.1::images /live/images --password-file rsync.pwd
Но парольный файл rsync.pwd содержит пароль в открытом виде.
А вход по ключам в одной подсети безопасен при том, что одна из машин смотрит в инет напрямую??

KRUTO написал:

А вход по ключам в одной подсети безопасен при том, что одна из машин смотрит в инет напрямую??

Ключи только у вас будут и все. Вход по ключам является одним из самых безопасных способов авторизации и аунтификации. Ключик можете хранить на флеш накопители под замком в железном сейфе и пользоваться им только в том случае когда делаете бэкап, а так же каждые 2 недели генерировать новый ключик, для пучности можете ssh повесить на другой порт > 1024 =)

А вообще почитайте про работу ssh и rsync, и вам все станет ясно и понятно.

i2ks написал:

А вообще почитайте про работу ssh и rsync, и вам все станет ясно и понятно.

i2ks,
Что ж вы меня все тыкаете: "Почитай, да почитай..." Если бы не читал -- не спрашивал бы...
Я также читал, как прекрасно ломать эти ключики, а вот про rsync с паролем мне кто-нибудь ответит??

Ведь можно использовать rsync без ssh

KRUTO написал:

There are two different ways for rsync to contact a remote system:
using a remote-shell program as the transport (such as ssh or rsh) or
contacting an rsync daemon directly via TCP. The remote-shell trans-
port is used whenever the source or destination path contains a single
colon (:) separator after a host specification. Contacting an rsync
daemon directly happens when the source or destination path contains a
double colon (::) separator after a host specification, OR when an
rsync:// URL is specified (see also the “USING RSYNC-DAEMON FEATURES
VIA A REMOTE-SHELL CONNECTION” section for an exception to this latter
rule).

Значит ситуация такая: 1) создаю файл с паролем, например rsync.pwd на машине-приемнике
2) указываю его в rsyncd.conf на машине-приемнике
3) создаю файл с паролем, например rsync.pwd на машине-источнике
4) запускаю rsync -d (в режиме демона) на машине-источнике
5) передаю файл:
rsync -r user123@192.168.1.1::images /live/images --password-file rsync.pwd


Так кто не читал-то?? Мне надо знать такое использование rsync безопаснее ssh с открытым ключом, т.к. пароль хранится в открытом виде как на машине-источнике, так и на машине-приемнике???

KRUTO, я вам уже написал то что безопасно, ваш метод так же не панацея, и ломается в два счета, а если вы сомневаетесь в работе ssh и ключа, то делайте соответствующий вывод. Для дальнейшего мазохизма можете еще и openpgp прикрутить.

i2ks,
И правда мазохизм, хех -- для этого бэкап, чтобы не заморачиваться... пусть каждые сутки делается, а БД вообще каждый час -- и черт с ним.... Спасибо вам за ликбез

--=XliN=--,
Обещанная инструкция:

ИНСТРУКЦИЯ ПО BACKUP

Цель – создание «гибкого» архива рабочей системы на лету с возможностью последующего восстановления в сжатые сроки.

Первым делом, смотрим сколько места занимает система-источник:

[console]df -kPh:
Файловая система Разм Исп Дост Исп% смонтирована на
/dev/sda1 25G 12G 12G 52% /[/console]

Необходимо, чтобы на диске-приемнике было достаточно места для переноса нашей системы, делаем вывод что нам необходимо минимум 13 ГБ на диске-приемник.

Подключим и подготовим диск-приемник к переносу программой fdisk, вот моя структура разделов:

fdisk –l

[console]Диск /dev/sda: 40.0 ГБ, 40020664320 байт
255 heads, 63 sectors/track, 4865 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0xe120e120
Устр-во Загр Начало Конец Блоки Id Система
/dev/sda1 * 1 3187 25599546 83 Linux
/dev/sda2 3188 3252 522112+ 82 Linux своп / Solaris
Диск /dev/sdb: 20.4 ГБ, 20416757760 байт
255 heads, 63 sectors/track, 2482 cylinders
Units = цилиндры of 16065 * 512 = 8225280 bytes
Disk identifier: 0x7e8a96e0
Устр-во Загр Начало Конец Блоки Id Система
/dev/sdb1 * 1 2417 19414521 83 Linux
/dev/sdb2 2418 2482 522112+ 82 Linux своп / Solaris[/console]

У меня диск /dev/sda – на котором установлена система-источник, /dev/sdb – диск-приемник.
При необходимости разбейте диск-приемник как пожелаете программой fdisk. При этом учитывайте, что раздел, с которого будете грузится должен быть загрузочным, размер свопа (как выяснилось после многочисленных проб и ошибок) не имеет значения при восстановлении (пусть он будет хоть 64 Кб).

Отформатируйте разделы, например:

mkfs.ext3 /dev/sdb1
mkswap /dev/sdb2

Теперь подготовим BackUp-архив, лучше всего для этого подходит программа архивирования tar (другие способы вызывали проблемы с ссылками), будем сохранять архив в папку /var/BackUp, опции программы tar смотрим man tar – быстрее запомнятся:

tar  -cvpzf  /var/BackUp/myback.tar.gz  /  --exclude={"/proc", "/dev", "/sys", "/mnt" ,"/selinux", "/srv" ,"/var/BackUp"}

На моем очень слабеньком компьютере эта процедура занимает часа полтора.

Перекурили….

Ну вот из 12 Гб, мы получили архив в 2 Гб.

Теперь создаем директорию для монтирования диска-приемника. У меня это «/mnt/DiskDva» и монтируем раздел sdb1 диска-приемника:

mount –t ext3 /dev/sdb1 /mnt/DiskDva

Распаковываем архив:

tar -xvpzf /var/BackUp/myback.tar.gz -C /mnt/DiskDva

Курим…. (хоть я табак не курю)

Затем нам надо поправить два файлика: /etc/fstab и /boot/grub/grub.conf. (Я использую загрузчик GRUB, он у меня проблем не вызывает, простой как правда.)
Там нам надо поменять UUID разделов-источника на UUID разделов-приемника, хорошая вещь эти UUID, раньше их помнится не было (в /etc/fstab были имена разделов такие как /dev/sda1).
Чтобы получить UUID воспользуйтесь, например, программой blkid

!!!! Обратите осовое внимание на файлы /etc/fstab /boot/grub/grub.conf

Создаем папки псевдо файловых систем: proc, dev, mnt, srv, sys, selinux

В заключении всего, отмонтируйте раздел диска-приемника:

umount /mnt/DiskDva

Выключаемся. Отключаем диск-источник и грузимся с нового диска… И – оба-на какие мы молодцы. Даже загрузчик не надо восстанавливать, не надо менять местами диски, Linux по барабану…

P.S.
1. Если будут проблемы с загрузчиком – делаем chroot в директорию-приемник и восстанавливаем загрузчик:

chroot /mnt/DiskDva
root (hd0,0) – где, hdm,n: m – номер диска, n – номер раздела диска.
setup (hd0)
quit

2. Я использую tar – потому, что
-- архив занимает мало места;
-- сохраняются файловые ссылки, я пробывал просто копированием

sudo cp –ax / /mnt/DiskDva и rsync

– были проблемы с правами доступа и ссылками
-- возможность хранения архива на другом компьютере;
могу и в .doc формате, хех
Отзывы???

KRUTO, оформить сообщение с использованием тегов (code / console итп) разве нельзя было? Каша какая-то нечитабельная.

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