Зберігання резервних копій в амазонівсьокому льодовику (Amazon Glacier)

Піддався і я модним тенденціям, переношу свою господарку в амазонівські хмари (AWS). Статичні сайти — на S3, домени — на Route 53, поштарку — на EC2. Все це вже працює пару тижнів, політ нормальний. Але тепер необхідно налаштувати резервне копіювання, і почну я з даних EC2-шної машинки.

Для зберігання резервних копій ми будемо використовувати найбільш підходящий для цього сервіс — Льодовик (Glacier). Нічого дивного, його саме для цього і проектували і коштує він зовсім не дорого (на момент написання статті 0,01$ за 1 Гб на місяць).

Коли я тільки збирався налаштовувати цю господарку, я знав що у Glacier є тільки суворий API, який дозволяє оперувати даними як KEY-BLOB. Але виявилось, що амазонці не стоять на місці і інтегрували його з S3, а значить писати своє чудисько для запихання даних не потрібно, підійдуть вже опановані інструменти для роботи з S3.

Ну, S3 так S3, потрібно створити відро (bucket) спеціально для резервних копій. При виборі регіону врахуйте наступне: якщо будете бекапитись з EC2, то логічно вибрати той же регіон, якщо резервні копії будуть завантажуватись з поза меж AWS, то вибирайте найближчий. Думаю, для більшості моїх читачів це буде "Ireland".

Тепер потрібно налаштувати переміщення файлів з S3 у Glacier. Для цього йдемо до налаштувань відра і дивимось у розділ "Lifecycle":

AWS Lifecycle

Додаємо правило, яке назвали "Freazing backups", встановлюємо галочку "Apply to Entire Bucket", адже це відро ми створили тільки для резервних копій. Додаємо "Transition" – переміщення у Glacier через 1 день (нема сенсу довго зберігати резервну копію на дорожчому S3). Додаємо "Expiration" - видалення об'єктів після 32-х днів (Glacier дешевий, але не безкоштовний).

AWS Lifecycle Rule

Після того як відро створено і "замерзання" налаштоване, потрібно створити користувача і надати йому відповідні права доступу. Для цього в консолі керування AWS переходимо до розділу IAM. Процедура створення користувача дуже проста, тільки не забудьте зберегти ключі, вони нам знадобляться при конфігуруванні s3cmd. А ще, я рекомендую зробити для програм і скриптів групу, наприклад "Programms", і помістити нашого користуваа туди.

Коли користувача створено, виділимо його та перейдемо на вкладку "Permissions" (внизу). Щоб надати цьому користувачу права доступу до відра, натисіть "Attach User Policy". Оскільки нам потрібно дотати дозвіл на одну операцію з одним об'єктом, вибираємо "Policy Generator". Вибираємо сервіс до якого потрібно надати доступ (Amazon S3) і дію "PutObject".

AWS Permission

В полі "Amazon Resource Name" вводимо ARN нашого відерка:

arn:aws:s3:::moby.backup/*

Все, тиснемо "Add Statement" і "Continue". Бачимо нашу політику у форматі JSON, натискаємо "Apply Policy". Доступ налаштовано.

На цьому підготовка відра і льодовика закінчена.

Тепер треба організувати запихання наших резервих копій в S3. Для цього скористаємося утилітою s3cmd. Установка і налаштування:

pip install s3cmd
... skip ...
s3cmd --configure

Конфігуратор спитає у вас ключі (Access Key і Secret Key), "Encryption password" вводити не потрібно (цією конфігурацією користуватиметься скрипт), бажано включити HTTPS. Воно само одразу перевірить конфігурацію, якщо все гаразд перейдемо до підготовки резервних копій.

Мені необхідно зробити резервні копії критичної інформації поштового сервера, а це:

  • конфігурація;
  • база даних;
  • пошта.

Пишемо для цього простий bash-скрипт s3backup.sh:

#!/bin/bash

DST=/tmp/s3-backup # Тимчасовий каталог для резервних копій

DBUSER=root # Користувач БД
DBPASS=db_p@ssw0rd # Пароль від БД !!! Погано, тому пильнуйте права на скрипт !!!

DATE=$(date +%Y-%m-%d)

mkdir ${DST}

# Configs
/bin/tar -czf ${DST}/etc-${DATE}.tar.gz -C / etc

# Mail
/bin/tar -czf ${DST}/mail-${DATE}.tar.gz -C / var/mail_virtual

# MySQL
for db in $(echo 'show databases;' | mysql -s -u ${DBUSER} -p${DBPASS}) ; do
    mysqldump --opt --single-transaction -u ${DBUSER} -p${DBPASS} $db | gzip -c > ${DST}/mysql-${db}-${DATE}.sql.gz
done

# S3 sync
s3cmd put ${DST}/* s3://<назва відра>/

rm -rf ${DST}

Обережно!!! Скрипт може містити логін/пароль до БД і скоріш за все супер-користувача :(, тому ОБОВ'ЯЗКОВО встановіть на скрипт права 7000

Дописуємо у crontab виконання скрипта раз на добу у зручний час. От і все, маємо резервні копії даних за 32-а дні.

Бережіть себе і свої дані!


Mac OS X і зовнішній жорсткий диск

Задача: ефективно/зручно використовувати для резервного копіювання і зберігання всяких даних зовнішній жорсткий диск ємністю 1ТБайт у операційних системах Linux, Mac OS X і опціонально Windows.

Теоретична частина (вибір ФС для диску)

З чого будемо вибирати: рідна для Linux — Ext3, рідна для Mac OS X — HFS+, рідна для Windows — NTFS, на FAT не дивимось бо її обмеження у XXI-у столітті виглядають смішними.

. Ext3 - дуже симпатичний кандидат (OSS4ever!), але вимагає установки

милиць у інші ОС, як виявилося пізніше дуже кривих.

. HFS+ - Apple way, Джобз тріумфує (дай йому Бог здоров'я), для інших

ОС знадобляться додаткові танці, але я сподіваюсь Linux, як завжди, потішить, а на Windows нам начхати (зовсім необов'язково)

. NTFS - "обітєль зла", на Mac треба додатковий софт, на Linux хоч і

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

Добряче почухавши потилицю, вибираємо HFS+, подивимось як заведеться під Linux.

Практична частина (зберігаючи хронологію, але без матюків)

Диск був відформатований у Ext3, оскільки раніше я використовував виключно Linux (Ubuntu). На ньому накопичилась купка даних, які треба тимчасово перенести на Mac (більше ніде немає достатньо місця), попутно пробуємо варіант №1 з теоретичної частини.

Спроба № раз — macfuse і ext2fuse

Взагалі, способів установки ПЗ на Mac забагато; і .dmg, і .pkg, для OSS - macports, а віднедавна ще й AppStore. Я, як новачок, ще й досі гублюся... але для OSS вибрав один єдиний "православний" і "кошерний" спосіб — macports.

Вони ж (ports) мене і підвели, як ти їх не умовляй хоч через variants, хоч через macports.conf, все одно збирали модуль ядра тільки для архітектури i386.

Помордувавшись трохи, подумав, біс із ним, перезавантажив систему у 32-бітному режимі. І тут невдача, щось йому там "connection timed out", вирішив далі не розбиратись. Зніс ext2fuse і macfuse.

Спроба № два — Ext2fsx

Проект дохлий, не оновлюється з 2006-го, але знайшлася пара статей за 2010 «ставте все працює» — дзуськи! На Snow Leopard (10.6.7) воно не працює ні разу. Нічого дивного, йдемо далі.

Спроба № три — Paragon (Бог трійцю любить)

За рекомендацією приятеля ставлю комерційний Paragon ExtFS for Mac OS X, "тик-тик-тик", встановлено — працює. Ура!

Не душила б жаба заплатити $40 (але краще "Deore по кругу" для ровера, а якщо й до комп'ютера то Portal 2 ;)), використовував би на диску Ext3 і горя не знав, але ставлю 10-денну демо-версію, щоб тільки раз переписати файли з Ext3 на Mac.

Фініш

На цьому мої поневіряння закінчились, файли переписано, диск переформатовано у HFS+ (без журналювання). Linux побачив HFS+, хоч і без журналювання, зате «з коробки» на читання/запис, чим вкотре підтвердив свою позитивну репутацію «приспособлєнца».