Переезд на другой сервер

[Strannic]

Подскажите как можно перенести сайты с одного сервера на другой,
учитывая что на исходном сервере места на жестком осталось 3 гига, а размер сайтов около 100 гигов, при чем в составе которых десятки миллионов мелких файлов, соответственно заархивировать на исходном сервере все это дело - нет места, а передавать просто через ftp - мега долго.....
Выручайте братцы!

[creator123]

поток из gzip можно писать прямо по ssh на другой серв. Типа того.

[Strannic]

Сообщение от creator123

поток из gzip можно писать прямо по ssh на другой серв. Типа того.

вот это уже интереснее! в принципе то что нужно! покурю гугл....

den2099 места нету на сервере все одним архивом зажать.

UPD В общем нашел!
Всем спасибо за идеи!
Буду тестировать.

Возникает желание передавать резервируемые данные на другую машину по сети, чтобы обеспечить их максимальную сохранность. Чтобы эта передача была прозрачной для резервирующих приложений, применим, к примеру, уже упомянутую NFS или SMBFS либо станем контролировать сетевой транспорт самостоятельно. Для последнего выберем SSH-сессию. Да, неоригинально. Зато надежно. Проще всего воспользоваться утилитой scp, входящей в комплект OpenSSH:

$> tar -zc -f mybackup.tar.gz srcdir && scp mybackup.tar.gz [email protected]:/home/dstuser/ && rm -f mybackup.tar.gz

Однако это не удовлетворяет моему требовательному подходу: промежуточный архив mybackup.tar.gz требует места на диске и при этом может оказаться весьма немаленьким
В ситуации, когда непозволительно временно сохранять промежуточный архив на локальном диске, будем архивировать не на диск, а прямо в SSH-сессию. Архиватор будет выдавать архив в stdout (опция -f -), который через pipe-конвейер попадает в stdin SSH-клиента, а оттуда — прямо в сетевую SSH-сессию:

$> tar -zc -f - srcdir | ssh -C [email protected] "cat > /home/dstuser/mybackup.tar.gz"

Если вдруг на хосте-хранилище не окажется возможности поднять SSH-сервер, хранилище может самостоятельно инициировать создание резервной копии в обратном порядке и принять ее на себя (вместо cat можно использовать dd, в качестве входного файла по умолчанию — stdin):

dsthost$> ssh -C srcuser@srchost "tar -zc -f - srcdir" | dd of=/home/dstuser/mybackup.tar.gz

Однако предыдущая схема предпочтительнее в плане безопасности, так как srcuser'у могут требоваться достаточно большие привилегии (для того чтобы бэкапить некоторые данные), в то время как dstuser практически во всех случаях имеет шансы остаться бесправным на своей машине. Ясно, что подобное использование SSH-сессии в качестве транспорта распространяется не только на архиваторы, но и на любые рассмотренные мной утилиты. К примеру, dd по умолчанию сливает данные в stdout. Осталось только перенаправить:

$> dd if=/dev/cdrom bs=2048 | ssh -C [email protected] "dd of=/home/dstuser/mycd.iso"

Наши занятия выглядели весьма пристойно, пока мы работали руками. Только проявится автоматизация, сразу же возникнет вопрос: «Кто будет вводить пароли?» Чтобы вопроса даже не возникало, я сгенерю пару ключей:

$> ssh-keygen -t rsa

Утвердительно отвечаем на все вопросы и вводим пустую passphrase два раза, чтобы не вводить ее в качестве пароля (тем не менее, мы хорошо защищены асинхронным криптоалгоритмом, ключи для которого были сгенерированы только что). Затем кладем публичный ключ на удаленную машину:

$> cat ~/.ssh/id_rsa.pub | ssh dstuser@dsthost "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys"

В ходе этой процедуры мы ввели пароль в последний раз, больше не потребуется. Обращаю особое внимание на смену прав на публичный ключ и каталог, содержащий его на стороне сервера. sshd — умный демон, и если доступ к публичному ключу получит кто-нибудь, кроме соответствующего пользователя, пользоваться ключом станет невозможно.

Итак. Довольно подробно мы рассмотрели аспекты, пригодные для создания автоматизированных скриптов, использующих в качестве сетевого транспорта SSH-сессию.

[chesser]

не занимайтесь изобретением собственных велосипедов.
для решения этой задачи есть rsync, в котором уже есть режим сжатия + игнорирование уже созданных файлов (писали выше)

rsync --флаги user@IP:/DIR_источника DIR_для_результата

например, запускать на новом сервере:

rsync -avz --exclude='тут можно указать dir-исключения' --exclude='можно несколько раз повторить' root@IP_сервера_с сайтами:/home/www /home

флаг -a - он составной и в себе содержит несколько флагов(-r -l -p -t -g -o -D), которые наиболее популярны при архивации, читаем man rsync
флаг -v - это визуализация процесса в терминале
флаг -z - это сжатие гзипом, при желании можно еще указать --compress-level

на обоих серверах должен быть установлен rsync. Например: yum install rsync

если ssh имеет нестандартный порт, то к команде rsync прибавляется флаг -e 'ssh -p2222', будет так:
rsync --флаги -e 'ssh -p2222' user@IP:/DIR_источника DIR_для_результата