Используя tar и rsync для высокой доступности
У меня есть облачное выполнение серверов Ubuntu, которое у меня нет прямого доступа к, но с ssh. Я использую 'tar', чтобы клонировать или иметь высокую доступность этого сервера. Я следовал учебному руководству из ссылки [текст ссылки] [1]. Я попробовал эту установку нового сервера той же версии. Когда я извлек tar (tar-xvpzf ~/clone.tgz-C/) на (новом) месте назначения, в конце он заканчивается следующим выводом, подобным ниже (не знайте, является ли это ошибка).
tar: var/run: time stamp 2010-11-09 17:09:11 is 7335.159880406 s in the future
tar: var/spool/postfix/usr/lib/zoneinfo: time stamp 2010-11-09 17:08:26 is 7290.159730037 s in the future
tar: var/lib: time stamp 2010-11-09 17:27:51 is 8455.159349527 s in the future
tar: usr/bin: time stamp 2010-11-09 17:28:02 is 8466.159254097 s in the future
tar: usr/share/sgml: time stamp 2010-11-09 17:27:47 is 8451.158909506 s in the future
tar: usr/share/man/man7: time stamp 2010-11-09 17:27:50 is 8454.158393583 s in the future
tar: usr/share/man/man1: time stamp 2010-11-09 17:28:02 is 8466.158166556 s in the future
tar: usr/share/man/man8: time stamp 2010-11-09 17:27:51 is 8455.158057701 s in the future
tar: usr/share/omf/time-admin: time stamp 2010-11-09 17:27:52 is 8456.157830449 s in the future
---------------------------------------------
---------------------------------------------
---------------------------------------------
Я использую следующую команду для создания файла tar указанных каталогов в исходной системе.
tar -cvzf ~/clone.tgz --exclude ~/clone.tgz --exclude /etc/hosts --exclude /etc/hostname --exclude /etc/udev/ --exclude /etc/network/interfaces --exclude /etc/resolv.conf /etc /home /opt /tmp /usr /var /mnt
- Есть ли какие-либо меры предосторожности перед использованием tar? (tar является одним созданием времени с того времени, я буду использовать rsync),
- Мне придется больше включать каталог как мусорное ведро или lib? - предлагают меня
- Мне придется исключить какой-либо каталог? Как у меня было сетевое устройство (eth0), проблема (не удался запустить eth0). Таким образом в вышеупомянутой команде я исключил "/etc/udev /" и после этого я чувствовал, что это было прекрасно. Как это, там какая-либо вещь, которую я должен исключить из/etc/или из какого-либо каталога, который я включал? - предлагают меня.
- Как я мог запланировать rsync (возрастающий bkp) с ssh комбинацией для синхронизации каталогов (указанный в tar) к удаленному местоположению (скажите, что/mnt/newdir), который я мог смолить и извлечь его позже в случае системного отказа. Rsync, как могут планировать, будет работать как пользователь root, но ssh запросит пароль. К вашему сведению sudo полностью отключен и а также прямой вход в систему ssh корня также отключен.
Если существует какой-либо лучший путь без вреда серверу для достижения этого, может предложить.
[1]: http://ubuntuforums.org/showthread.php? t=525660
3 ответа
Сообщения, скорее всего, вызваны тем, что часы нового сервера отстают во времени, чем старые.
Если вы клонируете конфигурацию и базу данных менеджера пакетов (и вы это делаете), вам следует клонировать / bin, / sbin и / lib, иначе система назначения окажется в несовместимом состоянии. Другим подходом будет исключение /etc/dpkg.info / etc / apt / var / lib / apt и / var / lib / dpkg и переустановка всех пакетов в целевой системе.
Файлы в / var / dpkg и / var / apt содержат информацию о том, что установлено в вашей системе. Если вы не исключите их, менеджер пакетов будет считать, что все программы и зависимости в родительской системе установлены в целевой системе. Но если вы не скопировали / bin, / sbin и т.д ... они не будут. Очень вероятно, что что-то сломается при следующей установке или обновлении.
Для последующей синхронизации с rsync я всегда использовал сертифицированную аутентификацию, а не пароли. Это довольно легко настроить, я помню, что я сделал это, просто читая справочную страницу в первый раз. Вот краткое руководство , если вам нужна дополнительная информация, я считаю, что это заслуживает нового вопроса.
Я бы порекомендовал вам вместо этого использовать rsync, это позволит вам выполнять реальную синхронизацию системы с системой без необходимости во временных файлах. Это также дает преимущество создания дополнительных обновлений, когда вам нужно обновить клон.
Я бы исключил только: / proc / / sys / dev / tmp / mnt В системе клонирования вам необходимо убедиться, что / etc / fstab и /boot/grub/grub.cfg обновлены с UUID клона Системные перегородки.
Если у вас есть база данных, такая как mysql, вам нужно быть осторожным и останавливать базу данных перед выполнением копирования.
Во-первых, многие облачные провайдеры IaaS предлагают мощные возможности моментальных снимков, которые решают эту проблему довольно легко.
В EC2, если вы запускаете систему на основе EBS, вы можете просто периодически снимать ее. Если с исходным экземпляром происходит что-то ужасное, вы можете вернуться к предыдущему снимку на новом экземпляре. Если вы хотите заархивировать снимок, вы можете загрузить другой экземпляр с прикрепленным к нему и использовать что-то вроде tar + s3, не оказывая негативного влияния на производственный блок.
Есть ряд проблем с этим подходом, которые могут быть не очевидны прямо сейчас.
- Вы запираетесь в единую технологию. Если вы работаете с Ubuntu 10.10 и хотите перейти на 11.04, вам нужно обновить исходную систему, а затем сделать снимок снова. Аналогичным образом, если вы используете снимки EBS EC2, вам нужно новое решение, если вы отправляетесь в облачное хранилище.
- У вас нет истории изменений, если вы используете rsync. Если вы что-то измените в системе 1, то что-то сломается, вы, скорее всего, тоже сломаете свою систему резервного копирования при rsync.
- Rsync может очень сильно повлиять на вашу производственную систему.
Что вам действительно нужно, так это система управления конфигурацией и высокая доступность данных.
Я бы порекомендовал вам выбрать систему управления конфигурациями, например, puppet (в основном!), Chef или cfengine. Начните выполнять все свои настройки в системе управления конфигурациями, а затем вы можете просто загрузить общую систему и применить к ней управление конфигурацией. Добавьте «etckeeper», и у вас есть история.
Для обеспечения высокой доступности данных rsync должен работать и быть намного более простым, поскольку вы можете просто скопировать данные, которые вы хотите. Есть также drbd, чтобы иметь то, что составляет «сетевой RAID1». Они не заменяют резервные копии данных, которые должны включать исторические снимки (будь то через снимки блочных устройств или что-то вроде tar), а не синхронизироваться с хостом восстановления (что, если кто-то удалит все данные, которые были синхронизированы с полем восстановления, удалив их все) там тоже?)