Як створити резервну копію працюючого сервера Linode?

Ми хочемо зробити резервну копію всього на нашому сервері Debian, який працює віддалено в інший бік світу (розміщений Linode), не вимикаючи його.

Ця система працює з оболонкою, електронною поштою, XMPP / prosody та веб, з парою простих налаштувань nginx.
Ми хочемо створити резервні копії файлів, пов’язаних із цими речами, лише для того, щоб бути безпечними. Наприклад, користувачі файлів зберігаються у своїх домашніх каталогах.

Нам не потрібно точно копіювати існуючий wrt для установки кожного файлу / etc; замість цього, в першу чергу ми навіть робимо резервну копію, тому ми можемо перенести все це на нове налаштування (новіша версія Debian, яка все ще знаходиться на Linode).

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

Причина цього питання полягає в тому, що коли я намагався робити резервні копії в минулому, я продовжував робити одну з цих двох помилок:

• Я пішов "Гаразд, я просто скопіюю /і все під ним", а потім застряг у якомусь дивному нескінченному циклі або через диск, який я копіював, був встановлений під / media / backup, і він копіював себе рекурсивно [obv ця конкретна проблема тут не застосовується, оскільки ми збираємося робити резервну копію через rsync або подібне], або вона застрягла, намагаючись скопіювати якісь "живі" речі в / proc або / var чи що завгодно, як, наприклад, намагаючись не відставати від постійно змінюваних журналів, або
• Я пішов "Гаразд, я просто захоплю мінімум того, що нам потрібно ... Хм, всі домашні каталоги та наші каталоги веб-сервера (все під /var), і давайте обробимо копію /etcта всі старі листи під / var / vmail ", і тоді я незмінно трахав дозволи на файли або часові позначки (буду впевнений, що цього разу не створю резервну копію файлів Unix на FAT-диску) або щось забув (" о, стріляй, у мене були деякі спеціальні сценарії в / usr / локальний / бін, який я ніде не зберігав, я забув їх отримати, напевно, їх зараз немає ").

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

Питання про помилку сервера Що потрібно для повної системи резервного копіювання? стосується філософії та передової практики, але я шукаю ці більш конкретні деталі:

• Які каталоги мені потрібно скопіювати, а які я виключати (враховуючи, що це система, яка наразі працює та обслуговує вікі, чат XMPP, електронну пошту - з новими повідомленнями, що надходять під час виконання завдання копіювання)
• Які атрибути файлів, такі як часові позначки та власник та група, потрібно подати, і як це зробити? ← Я думаю, що можу відповісти на цю половину запитання самостійно чимось на кшталт ... гм ... rsync -HXazя думаю, що це хороший варіант для нас? Об’єкт -zне дуже пов'язаний з питанням, що "що я зберігаю"

Багато порад щодо резервного копіювання, які я бачу, як, наприклад, використання dd, здається, припускають, що накопичувач відключений і не використовується. Але я не повинен виключати "живих" каталогів, таких як / proc та деякі підкаталоги під / var (однак, деякі речі під / var, які я знаю, ми, безумовно , потрібно зберігати) та / mount? Що ще є над тим, що мені потрібно думати у цій ситуації? Тоді я здогадуюсь, що я можу просто зняти це за допомогою rsync та використати купу --excludeпрапорів.

Або є кращі ідеї, особливо дружні до FOSS?

Отже, ви хочете створити резервну копію всього свого диска без усіх цих неприємних помилок, а також відфільтрувати всі / proc та інші тимчасові папки?

Варіант - встановити кореневу папку на іншу папку файлової системи, наприклад:

$ cd /mnt
$ mkdir drive
$ mount --bind / drive

Це дасть вам усі файли, які є на вашому диску, які не вважаються тимчасовими (наприклад, папки / proc або / sys).

Тепер, коли у вас є чистий вигляд вашої кореневої папки, ви можете просто скопіювати її на резервний диск за допомогою стандартного cpабо rsync. Щось у напрямку:

cp -R /mnt/drive /mnt/backupdrive

Це вирішує обидві зазначені проблеми:

• Ви не потрапляєте в рекурсію, оскільки резервний диск не встановлений в диску (точка зору)
• ви не пропускаєте жодних важливих файлів, тому що ви берете їх усі

Дивіться також: чоловіче кріплення (8)

У Linux все є файлом. Це можливо за допомогою rsync, але є речі, які слід пам’ятати, які (у кращому випадку) важко обійти.

Спершу слід подумати про реплікацію, особливо це стосується баз даних. Крім того, це гарна ідея встановити проксі / балансир завантаження перед основним сервером, щоб ви могли легко перемикатися вперед і назад з вашими первинними і дзеркальними серверами під час переходу.

На апаратному рівні найкращою ситуацією буде наявність дзеркального сервера з іншого боку, з такою ж кількістю Ethernet портів, однаковою версією hdd тощо. Все, що відрізняється, означає необхідність зміни конфігурації системи.

наприклад, якщо у вас є два порти et, ви хочете переконатися, що мережева конфігурація, брандмауер та інше відповідають назвам інтерфейсу на обох серверах, і, якщо він відрізняється, вам потрібно буде змінити конфігурацію після rsync або змінити ім'я пристрою на другому (призначення) сервер.

Те саме з компонуванням перегородок. Вам слід створити ті самі розділи, що і на вашому первинному сервері, але якщо ви створюєте їх з нуля, у вас з'являться різні UUID, тому вам потрібно буде змінити fstab, grub, mdadm (якщо задіяний soft-raid) тощо. .

Але також є багато речей, які можуть піти не так, як, наприклад, бази даних, які можуть бути непослідовними, якщо їх не зупинити раніше (перш ніж робити rsync).

Найкращою стратегією буде спочатку підготувати апаратну та файлову систему (розділи) - щоб відповідати конфігурації основного сервера. Потім змонтуйте порожні парафітони через посередницьку систему (наприклад, живий компакт-диск із тимчасово встановленим ssh-сервером). Ви створюєте порожній / proc, / dev, / sys, а потім rsync решту, наприклад:

rsync -avz -H --delete /etc /bin (...and so on) destserver:/mnt/yourrootfs/

Тоді вам потрібно встановити grub на пристрій і попрацювати над його налаштуванням, зробити його завантажувальним, змінити конфігурацію мережі, fstab та інші речі, згадані раніше.

Ви також можете спробувати встановити свіжу систему (з тією ж версією, яку ви використовуєте на своєму основному сервері), потім вимкнути її, встановити через іншу, тимчасову систему (наприклад, живий cd), а потім замінити що-небудь, крім / proc, / sys, / dev та / boot з rsync.

Але це лише загальна ідея. Все може ускладнюватися залежно від того, що ви насправді маєте на цьому сервері, яка конфігурація, налаштування мережі та обладнання. Зрештою, це може бути дуже важко або неможливо зробити без помітних простоїв.

Те, що ви насправді хочете, - це відновлення. Що б ви не робили, ви повинні регулярно відновлювати тест.

У Linode є послуга резервного копіювання.Знімки можна робити за обмеженим заздалегідь визначеним графіком або за допомогою API.

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

Я використовую BackupPC для мого невеликого віртуального приватного сервера, це працює досить добре. BackupPC може використовувати rsync під кришкою та підтримує повне та додаткове резервне копіювання. Погляньте на це і подивіться, чи покриє він ваші вимоги.

Запустіть систему на ZFS. Тоді ви можете зробити миттєвий атомний знімок, використовуючи щось подібне:

# zfs snap -r tank@name-of-backup

де tankназваний ваш пул ZFS. Цей знімок гарантовано є миттєвим моментальним знімком файлової системи та всіх її дочірніх файлових систем.

Після створення знімка ви можете перенести його на інший хост за допомогою zfs sendта ssh.

Я думаю, це залежить від того, що і де ти працюєш сервер з внутрішньою командою Linux, це неможливо, ти повинен імітувати / передати цілісні дані та бібліотеки. Якщо ви працюєте на vmware і добре налаштовані, він забезпечує живу міграцію. Або ж вам доведеться використовувати сторонні інструменти. Сподіваюся, що це вам допоможе. Ще кілька посилань Як зробити резервну копію живого сервера?

Rsync добре контролює синхронізацію даних між серверами.

Є два рішення, де вам не потрібно покладатися (більше) на пропущені біти, а також на відсутність одного пункту у вашому списку через неповний контрольний список або, можливо, просто не помічене щось гаряче.

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

По-друге, я рекомендую прописати налаштування вашого повного сервера за допомогою системи управління конфігурацією, наприклад, Ansible. Це буде

• документуйте все, що ви налаштували в керуванні джерелами

• дозволяють тестувати відтворення сервера із резервного копіювання чи чистого металу, щоб переконатися, що ваші сценарії оновлені

• дозволяють повторно запускати скрипт в більш новій операційній системі, як правило, з досить незначними змінами.