рекомендації щодо ефективного віддаленого резервного копіювання рішення vm's

Я шукаю рекомендації щодо резервного копіювання своїх поточних 6 вм (і незабаром виростуть до 20). В даний час я використовую кластерний промокс-кластер з двома вузлами (який є базовою базою для debian, що використовує kvm для віртуалізації з користувальницьким веб-переднім кінцем для адміністрування). У мене є дві майже однакові коробки з материнськими платами amd femin II x4 та asus. Кожен має 4 500 ГБ sata2 hdd, 1 для ОС та інші дані для встановлення proxmox, і 3, використовуючи mdadm + drbd + lvm, щоб розділити 1,5 ТБ пам'яті між двома машинами. Я монтую lvm зображення в kvm для всіх віртуальних машин. Наразі я маю можливість робити передачу в реальному часі з однієї машини на іншу, як правило, протягом декількох секунд (це займає близько 2 хвилин на найбільшому vm, що працює win2008, з m $ sql сервером). Я використовую вбудовану утиліту vzdump промокс для того, щоб робити знімки vm ' s та зберігайте їх на зовнішньому жорсткому диску в мережі. Потім у мене є служба в джунглідиську (за допомогою стійки), щоб синхронізувати папку vzdump для віддаленого резервного копіювання за межами сайту.

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

Набагато кращим рішенням було б, звичайно, те, що дозволяє мені негайно взяти різницю у два часові моменти (сказати те, що було написано з 6 ранку до 7 ранку), застебнути його, а потім надіслати цей файл різниці на сервер резервного копіювання, який миттєво перенесеться на віддалене зберігання на стійці. Я трохи заглянув у zfs, і це вміння робити надсилання / отримання. Це в поєднанні з набором даних у bzip чи щось здається ідеальним. Однак, здається, що реалізація сервера nexenta з zfs по суті потребує хоча б одного або двох більше виділених серверів зберігання, щоб обслуговувати томи блоків iSCSI (через zvol's ???) на проксимальних серверах. Я вважаю за краще зберегти налаштування якомога менше (тобто НЕ мати окремих серверів зберігання даних), якщо це можливо.

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

Отже, zfs, zumastor чи інше?

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

Залежно від ваших віртуальних машин і для чого вони використовуються, ви можете просто створити їх для резервного копіювання даних там, де ви зараз зберігаєте знімки щодня (або в будь-який графік, який підходить), і тоді JungleDisk може створити резервну копію лише даних. Це дозволить ефективніше перенести змінені файли, і зменшиться простір, необхідний для резервного копіювання, а також необхідний час. Крім того, ви можете робити знімки, щоб зберегти, і робити це набагато рідше (наприклад, щотижня).

У цьому випадку ви завжди можете просто створити нову віртуальну машину та відновити дані, або скористатися старішим знімком для відновлення VM, а потім скористатись резервною копією даних для відновлення до останньої точки.

Якби я робив резервні копії за межами сайтів, я вибрав би наступні варіанти:

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

або

(b) Встановіть інструмент управління сервером на зразок Webmin і отримайте це для автоматичного резервного копіювання. Зараз я співаю це на своїх виробничих серверах зараз без проблем, це просто працює бездоганно. Я також рекомендую cloudmin (платний) для управління багатьма VM, оскільки він пропонує рішення "все в одному".

кілька додаткових посилань:

http://www.debianhelp.co.uk/backup.htm

http://ubuntuforums.org/showthread.php?t=35087

Сподіваюся, що це допомагає, Рейкуанг

ви можете поглянути на резервну копію.

backuppc може працювати над rsync, що робить поступову копію.

Крім того, ви можете легко записати чорний список папок, які не потрібно робити резервні копії. Наприклад: temp / / tmp .garbages / ...

http://backuppc.sourceforge.net/

backuppc має чистий веб-інтерфейс, що дозволяє завантажувати деякі частини резервної копії безпосередньо у вигляді поштового файлу. Це може бути відстежено нагіосами за допомогою check_backuppc.

Я не впевнений, скільки архітектурних змін ви планували внести, щоб підвищити масштабованість. Однак, якщо ви будете відкриті для перемикання платформ VM, ви можете подивитися на VMWare.

Є багато хороших резервних рішень для резервного копіювання VMWare, я особисто використовував VzionCore. Потім ви можете зробити деякі гладкі речі із знімками та вказати час відновлення. Існує навіть можливість переходу на віддалений сайт.

zfs це чудово, ви вже згадали, знаючи, що хоча і недолік не працює чудово на шкалі 2 сервера. Він також не надасть вам відмову від DRDB, тобто Nexenta буде єдиною точкою відмови.

Ви можете спробувати придбати VirtualBox на OpenSolaris або NexentaCore, але не так просто, як ProxMox + DRDB, щоб ви могли повторно використовувати наявні машини.

Якщо ви виміряєте свої зміни та знайдете їх досить низькими, ви можете спробувати DRDB із 3-м дзеркальним офсайтом - він працюватиме лише тоді, коли кількість записів буде надзвичайно низькою у ваших віртуальних машинах.

Стів Радіч - Хостинг Windows та продуктивність SQL з 1995 року - http://www.BitShop.com/Blogs.aspx

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

Розглянемо рішення резервного копіювання файлів "у гостях", якого існує багато. Backuppc, Urbackup, бакула, аманда тощо ...

Це буде набагато швидше, витратить набагато менше місця і буде набагато простіше відновити конкретні файли.

Я думаю, що, можливо, я знайшов остаточну відповідь на моє запитання:

BUP https://github.com/bup/bup

Особливості:

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

  Він використовує формат packfile від git (система контролю версій з відкритим кодом), тому ви можете отримати доступ до збережених даних, навіть якщо вам не подобається користувальницький інтерфейс bup.

  На відміну від git, він записує пакети файлів безпосередньо (замість того, щоб проводити окремий етап збору / перепакування сміття), тому це швидко навіть при безкрайно величезній кількості даних. Вдосконалені формати індексу bup також дозволяють відстежувати набагато більше імен файлів, ніж git (мільйони), і відслідковувати набагато більше об’єктів (сотні чи тисячі гігабайт).

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

  Ви можете створити резервну копію безпосередньо на віддаленому сервері bup, не потребуючи тонни тимчасового дискового простору на комп'ютері. І якщо ваше резервне копіювання буде перервано на півдорозі, наступний запуск вибере там, де ви зупинилися. І легко налаштувати сервер bup: просто встановіть bup на будь-якій машині, де у вас є доступ до ssh.

  Bup може використовувати резервування "par2" для відновлення пошкоджених резервних копій, навіть якщо на вашому диску виявлено погані сектори.

  Навіть коли резервна копія є додатковою, вам не доведеться турбуватися про відновлення повної резервної копії, а потім кожен з них; додаткова резервна копія діє так, ніби це повна резервна копія, вона просто займає менше місця на диску.

  Ви можете змонтувати сховище вашої програми як файлову систему FUSE і таким чином отримати доступ до вмісту і навіть експортувати його через Samba.

Редагувати: (19 серпня 2015 р.) І виходить ще одне чудове рішення, яке ще краще: https://github.com/datto/dattobd

Це дозволяє робити знімки в реальному часі, по суті надаючи функції, подібні COW, до будь-якої звичайної старої файлової системи в Linux.

Редагувати: (15 липня 2016 р.) І ще одне чудове рішення, яке видуває бупу з води: https://github.com/borgbackup/borg

Особливо краще, ніж кущ при обрізку. Здається, вона має велику підтримку стиснення, шифрування та ефективного дедупликації. dattobd + borg ftw !!!