Робота з бекапами в хмарі

Опублікував Сергій Макаренко 8-09-2015 об 06:53

Кілька тижнів тому я став активно використовувати сховища у хмарі в якості інструменту для створення розподілених бекапів. Вибір було зроблено на користь Amazon Cloud Drive, Google Cloud Storage та програми для резервного копіювання Arq. В цілому можу сказати, що ця схема мене цілком влаштовує і система працює сама по собі, мого втручання не потребує.

Резервне копіювання даних з сервера

Я незадоволений тільки швидкістю, з якою відбувається резервне копіювання. Наприклад, бекап з мого Mac Pro розміром 365 Гб копіювався в Amazon Cloud Drive точнісінько 48 годин. Шляхом нескладних обрахунків отримуємо середню швидкість завантаження в Amazon Cloud Drive — 16,9 Мбіт/сек, що дуже непогано. Але на жаль ця швидкість не постійна і може коливатися в досить великому діапазоні.

Зараз ще в процесі перше копіювання вмісту жорсткого диску з сервера. Загалом там вийшло 630 Гб. Процес завантаження було розпочато в п’ятницю, 28 серпня о восьмій вечора і закінчився сьогодні о 20:06. Тобто дані завантажувалися з середньою швидкістю 5,3 Мбіт/сек. Причини у себе, через яку б спостерігалося таке коливання швидкості, я не знайшов.

Найважливішим моментом в питанні резервного копіювання даних є перевірка їх цілісності. Тобто, як мінімум, вам потрібно перевірити, чи можна потім використати ці бекапи для того, щоб відновити втрачені дані. Бо часто буває так, що, наче, бекапи робляться, але в час «Ч» з’ясовується, що інформація в них пошкоджена і відновити дані неможливо.

Відновлення фото з Amazon Cloud Drive

Для відновлення даних можна використати або програму Arq, або консольну утиліту arq_restore. На жаль останнє рішення на даний час є можливість використовувати тільки з Google Cloud Storage оскільки arq_restore поки що не підтримує Amazon Cloud Drive. В обох випадках швидкість відновлення не велика, якщо порівнювати зі швидкістю відновлення даних з бекапу на Time Machine.

Перелік з'єднань Arq під час відновлення з Amazon Cloud Drive

В якості експерименту я вирішив відновити медіатеку Photos яка у мене важить зовсім нічого — 12,6 Гб. Відновлення даних з Amazon Cloud Drive тривало 6 годин 15 хвилин (середня швидкість становить 4,58 Мбіт/сек), а з Google Cloud Storage — 8 годин 11 хвилин (середня швидкість 3,42 Мбіт/сек). Досить довго, але терпимо. Трохи неочікуваним для мене виявився той факт, що відновлення файлів з Amazon Cloud Drive (я зробив кілька спроб впродовж однієї доби, результат незмінний) відбувається швидше, ніж з Google Cloud Storage. Мені здавалося, що буде навпаки.

Приклад рядка з аргументами arq_restore

Тепер кілька слів про роботу з arq_restore. З одного боку це зручний засіб прямо з консолі відновлювати дані (це відкриває певні перспективи для автоматизації за допомогою bash), з іншого мені не подобається необхідність вводити велику кількість аргументів для програми вручну. Типовий рядок для отримання переліку зареєстрованих комп’ютерів в Google Cloud Storage буде виглядати так:

arq_restore listcomputers googlecloudstorage GOOGPABC123DEF456GHI "g0uU0r3G4da+kr8Aa4fRCm5iWJz8UNElCuOGSP" arq-bucketname

Погодьтеся, не дуже зручно кожного разу цю команду набирати руками. Але це можна пережити. Для того, щоб отримати змогу працювати зі сховищем Google з командного рядку потрібно увімкнути доступ до Cloud Storage через API і створити ключ за допомогою якого буде проходити автентифікація.

Увімкнення автентифікації для доступу через API до Google cloud Drive

Для цього необхідно зайти в Google Developer Console —> Storage —> Cloud Storage —> Settings —> Interoperability. Після цього Access Key та Secret можна буде використовувати для того, щоб за допомогою arq_restore працювати зі сховищем з командного рядка.

Рахунок за послуги Google Cloud Platform

Окрім цього 4 вересня я отримав перший рахунок для оплати послуг Google Cloud Storage. Google нарахував мені до сплати цілих ₵13 (вони були вирахувані з $300, коштом яких я можу сплачувати послуги Google Cloud Platform протягом двох місяців пробного періоду). В принципі, такої суми я і очікував. До тих файлів, що я вже маю в Google Cloud Storage я збираюся додати ~7 Гб критичних для мене даних з сервера. То ж місячний рахунок збільшиться ще на сім центів.

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

Помилки при відновленні даних з Amazon Cloud Drive

Надійність задовільна. Після відновлення інформацію з бекапів можна використовувати, хоча інколи можуть з’являтися повідомлення про помилки під час копіювання даних з Amazon Cloud Drive. Отже, якщо вас не лякає вартість такої моделі розподілених бекапів, то можете сміливо її використовувати. Головне, щоб в житті не виникали ситуації, після яких треба користуватися цим бекапом.