Про користь резервного копіювання

Опублікував Сергій Макаренко 1-09-2015 об 10:50

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

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

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

Але цей варіант можна використовувати, якщо ви працюєте за кордоном, або ж обчислювальні ресурси вашої компанії розташовані за межами України. Бо сучасна Україна не може гарантувати жодної безпеки компанії, яка працює на її території. І саме під час бурхливого обговорення можливості зберігати резервні копії на роботі в компанію Maxymiser (яку нещодавно придбав Oracle), де працює один мій знайомий, завітала міліція зі звинуваченням у використанні піратського ПЗ.

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

Дякуючи цим двом поважним панам я зупинив свій вибір в якості засобу автоматизації резервного копіювання на програмі Arq. Хочу зазначити, що вона не дешева. Ліцензія коштує $40 (можливість не платити надалі за мажорні оновлення буде коштувати додаткові $30) на один комп'ютер. Тобто, якщо у вас в родині їх кілька, то вам доведеться купувати по одному примірнику для кожного хоста. Для того, щоб спробувати програму в дії у вас буде місяць пробного періоду, протягом якого обмежень по функціональності немає.

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

В якості сховища для бекапів я вибрав Amazon Cloud Drive та Google Cloud Storage. Свій вибір на Amazon Cloud Drive я зупинив тому, що Amazon запустив атракціон небаченої щедрості. Компанія пропонує сховище в хмарі без обмежень по об'єму даних всього за $60/рік. При цьому Amazon не вимагає додаткових коштів для вилучення бекапів і за будь-які інші дії з даними у хмарі. Заплатив $60 і користуйся необмеженим за розміром сховищем цілий рік. Перед тим, як почати чарджити вашу кредитку Amazon пропонує три безкоштовні місяці повнофункціонального трейлу для того, щоб спробувати послугу.

Google Cloud Storage пропонує кілька тарифів в яких присутня диференціація тарифікації в залежності від того, який тип дій ви виконуєте зі сховищем. Я обрав для себе тариф Nearline. Якщо не заглиблюватися в деталі, то згідно умов цього тарифного плану 1 Гб даних, які ви будете завантажувати у хмаринне сховище Google буде коштувати вам ₵1/міс. Якщо вам знадобиться відновити дані з бекапу, то доведеться доплатити ще один ₵1/міс за кожний відновлений Гб даних. Більш детально з тарифами можна ознайомитися за цим посиланням. Google пропонує спробувати свій сервіс умовно-безкоштовно протягом двох місяців. На цей період вам на баланс нараховуються $300 в якості бонусу, який ви можете використовувати для оплати Google Cloud Storage.

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

Кілька слів про те, як резервне копіювання працює в мене. В Time Capsule завантажується повний вміст жорстких дисків мого Mac Pro і Mac mini Server, на якому хоститься цей блог. Я виключив у винятки тільки папку Downloads в якій знаходяться дані, що не мають ніякої, або дуже низьку цінність для мене на Mac Pro (здебільшого це різноманітні тимчасові файли і торенти) і папки, де зберігають закешовані дані Software Update та Caching Cervices на Mac mini Server.

В Amazon Cloud Drive відбувається копіювання даних з цих двох комп'ютерів з такими ж налаштуваннями, як і для Time Capsule. Дешеве і ємне сховище від Amazon я вирішив використовувати по повній, тому що час від часу буває потрібно знайти старі системні файли, або пакунки, які в нових версіях OS X Server іноді бувають зламані (наприклад, як тут). Резервні копії з двох моїх комп'ютерів займають ~1 Тб. В Google Cloud Storage я копіюю тільки критично важливу для мене інформацію. Це особисті документи та фотографії. Ці дані займають до 15 Гб.

Швидкість завантаження комфортна. Вдома я маю гігабітне підключення від «Ланет». 365 Гб з Mac Pro завантажувалися протягом двох діб, що дуже пристойно. Зараз в процесі копіювання ~650 Гб даних з Mac mini Server. 15 Гб на Google Cloud Storage скопіювалися за сім хвилин. Враховуючи мої потреби я очікую в місяць витрачати пів долара на оплату ресурсів Google Cloud Storage. В одному з наступних постів я більш детально зупинюся на роботі з arq_restore та спробую дати конкретні цифри в контексті швидкості по закачці даних і відновленні з Amazon Cloud Drive та Google Cloud Storage.