Добрый день, второй день ищу как написать команду для ssh,dump(8), для удалённого бекапа.
Находил команды вида - бекап локального раздела с передачей на удалённый хост. Но нужно добиться обратного хода действий...
Есть один сервер для хранения резервных копий. Он должен подключаться к остальным серверам, запускать у них дамп и сохранять его сразу себе на диск. Т.е. бекап удалённого раздела с передачей на локальный хост.
Наверняка кто-то сталкивался с такой проблемой, у кого какие версии решения?
> Но нужно добиться обратного хода действий...
> Есть один сервер для хранения резервных копий. Он должен подключаться к остальным
> серверам, запускать у них дамп и сохранять его сразу себе на диск.Довольно легко "обратный ход действий" превращается в прямой, если подключаться к "остальным серверам" по ssh и запускать на них обычные скрипты резервного копирования. Как-то так:
ssh root@host 'команда резервного копирования'
Если настроить вход только по ключам, можно и из крона запускать - красиво, дёшево, сердито.
> Довольно легко "обратный ход действий" превращается в прямой, если подключаться к "остальным
> серверам" по ssh и запускать на них обычные скрипты резервного копирования.
> Как-то так:
> ssh root@host 'команда резервного копирования'
> Если настроить вход только по ключам, можно и из крона запускать -
> красиво, дёшево, сердито.Да, но тогда нужно хранить скрипты на каждом из серверов, а не на одном (бекап-сервере), к тому же чтобы сразу бекапы лились на сервер-хранения нужно и для него создать ключи, что не очень хорошо, т.к. при взломе одного из серверов будет получен доступ к серверу бекапа и следовательно к данным остальных серверов.
Только у бекап-сервера должны быть ключи ко всем машинам, к нему же ключей быть не должно.
>[оверквотинг удален]
>> ssh root@host 'команда резервного копирования'
>> Если настроить вход только по ключам, можно и из крона запускать -
>> красиво, дёшево, сердито.
> Да, но тогда нужно хранить скрипты на каждом из серверов, а не
> на одном (бекап-сервере), к тому же чтобы сразу бекапы лились на
> сервер-хранения нужно и для него создать ключи, что не очень хорошо,
> т.к. при взломе одного из серверов будет получен доступ к серверу
> бекапа и следовательно к данным остальных серверов.
> Только у бекап-сервера должны быть ключи ко всем машинам, к нему же
> ключей быть не должно.ssh user@host dump -f - /dev/sda1 >file.dump
не ?
>[оверквотинг удален]
>>> красиво, дёшево, сердито.
>> Да, но тогда нужно хранить скрипты на каждом из серверов, а не
>> на одном (бекап-сервере), к тому же чтобы сразу бекапы лились на
>> сервер-хранения нужно и для него создать ключи, что не очень хорошо,
>> т.к. при взломе одного из серверов будет получен доступ к серверу
>> бекапа и следовательно к данным остальных серверов.
>> Только у бекап-сервера должны быть ключи ко всем машинам, к нему же
>> ключей быть не должно.
> ssh user@host dump -f - /dev/sda1 >file.dump
> не ?не или ещё вернее
ssh user@host "bash -c \"dump -f - /dev/mapper/sq-home | xz\"" >file.dump
...
removedопередили :)
Огромное человеческое спасибо за ответы! В итоге получился такой вариант:
ssh -c blowfish host "bash -c \"dump -0uan -L -f - /dev/ad8s1d \" | gzip -2 " > /usr/dump.img.gzПолностью устраивает, но если есть что поменять, то пишите, буду рад =)
> Огромное человеческое спасибо за ответы! В итоге получился такой вариант:
> ssh -c blowfish host "bash -c \"dump -0uan -L -f - /dev/ad8s1d
> \" | gzip -2 " > /usr/dump.img.gz
> Полностью устраивает, но если есть что поменять, то пишите, буду рад =)правильно делать бакап через snapshot'ы (файловой системы или lvm) и rsync'ом (rsnapshot/rdiff-backup) а не при помощи dump, соответственно предварительно выставив низкий приоритет на io и cpu.