Використання смоли та rsync для високої доступності

У мене працюють хмарні сервери Ubuntu, до яких я не маю прямого доступу, але з ssh. Я використовую 'tar' для клонування або для забезпечення високої доступності цього сервера. Я стежив за підручником за посиланням [текст посилання] [1]. Я спробував це, встановивши новий сервер тієї ж версії. Коли я видобув дьоготь (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

• Чи є якісь запобіжні заходи перед використанням дьогтю? (дьоготь - це одноразове створення, тоді я буду використовувати rsync)
• Чи повинен я включати ще якийсь каталог, наприклад, бін або lib? - запропонуйте мені
• Чи слід виключати будь-який каталог? Начебто у мене була проблема з мережевим пристроєм (eth0) (не вдалося запустити eth0). Тож у наведеній вище команді я виключив "/ etc / udev /", і після цього я відчув, що це добре. Як це, чи є щось, що я повинен виключити з / etc / або з будь-якого каталогу, який я включив? - запропонуйте мені.
• Як я міг запланувати rsync (інкрементальний bkp) з комбінацією ssh, щоб синхронізувати каталоги (вказані в tar) у віддалене місце (скажімо / mnt / newdir), яке я міг би застосувати та витягнути пізніше у разі відмови системи. Rsync може бути заплановано запустити як root користувача, але ssh запропонує пароль. FYI, sudo повністю відключений, а також прямий sh вхід до root також вимкнено.

Якщо є якийсь кращий спосіб без шкоди для сервера, щоб досягти цього, можна підказати.

[1]: http://ubuntuforums.org/showthread.php ? t = 525660

Я б рекомендував вам замість цього використовувати rsync, це дозволить вам зробити живу систему для системної реальної синхронізації без необхідності тимчасових файлів. Це також дає перевагу робити додаткові оновлення, коли вам потрібно оновити клон.

Я виключаю лише: / proc / / sys / dev / tmp / mnt У системі клонування вам потрібно буде переконатися, що / etc / fstab та /boot/grub/grub.cfg оновлюються UUID-кодами системних розділів.

Якщо у вас є база даних на зразок mysql, вам потрібно бути обережним і зупинити БД перед виконанням копії.

По-перше, багато постачальників хмарних технологій IaaS пропонують потужні можливості знімків, які вирішують це досить легко.

На EC2, якщо ви запускаєте систему на базі EBS, ви можете періодично робити її знімок. Якщо з оригінальним екземпляром трапиться щось жахливе, ви можете повернутись до попереднього знімка абсолютно нового екземпляра. Якщо ви хочете заархівувати знімок, ви можете завантажити інший примірник із доданим файлом та використовувати щось на зразок tar + s3, не впливаючи негативно на виробництво.

Існує низка проблем із таким підходом, які зараз можуть не бути очевидними.

1. Ви замикаєтесь в єдиній технології. Якщо ви працюєте над Ubuntu 10.10 і хочете перейти до 11.04, вам доведеться оновити вихідну систему, а потім зробити її ще раз. Так само, якщо ви використовуєте знімки EBS від EC2, вам потрібно нове рішення, якщо ви переходите до хмари стійки.
2. У вас немає історії змін, якщо ви використовуєте rsync. Якщо ви щось модифікуєте в системі 1, то щось порушується, ви, ймовірно, порушите і систему резервного копіювання, коли ви rsync.
3. Rsync може мати надзвичайно сильний вплив на вашу виробничу систему.

Те, що вам справді хочеться, це система керування конфігурацією та висока доступність даних.

Я рекомендую вибрати систему керування конфігурацією, наприклад, лялькову (в основному!), Шеф-кухаря чи cfengine. Почніть виконувати всю свою конфігурацію в системі управління конфігураціями, і тоді ви можете просто завантажити загальну систему та застосувати до неї керування конфігурацією. Додайте в "etckeeper" і у вас є історія.

Для забезпечення високої доступності даних rsync повинен працювати і бути набагато більш прямим вперед, оскільки ви можете просто скопіювати потрібні дані. Також є drbd, щоб мати те, що означає "мережевий RAID1". Це не заміни для резервного копіювання даних, які повинні містити історичні знімки (чи то через знімки блокових пристроїв чи щось на зразок дьогтю), а не синхронізацію з хостом відновлення (що робити, якщо хтось видаляє всі дані, які отримує rsynced, до вікна відновлення, видаляючи все це там теж?)

Повідомлення, ймовірно, викликані тим, що новий годинник сервера відстає від часу, ніж старий.

Якщо ви клонуєте конфігурацію менеджера пакунків та базу даних (і ви є), ви повинні клонувати / bin, / sbin та / lib, або система призначення буде у невідповідному стані. Іншим підходом буде виключення /etc/dpkg.info / etc / apt / var / lib / apt та / var / lib / dpkg та встановлення всіх пакетів у цільовій системі.

Файли в / var / dpkg та / var / apt містять інформацію про те, що встановлено у вашій системі. Якщо ви не виключаєте їх, менеджер пакунків вважатиме, що всі програми та залежності в батьківській системі встановлені в цілі. Але якщо ви не скопіювали / bin, / sbin тощо ... вони не будуть. Дуже ймовірно, що щось порушиться при наступній установці чи оновлення.

Щоб синхронізуватись із rsync, я завжди використовував сертифіковану автентифікацію, а не паролі. Це досить просто в налаштуванні, я пам’ятаю, що це я зробив, лише прочитавши сторінку людини вперше. Ось короткий посібник , якщо ви хочете отримати більше інформації, я вважаю, що це заслуговує нового питання.