Зберігання резервних копій в амазонівсьокому льодовику (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-а дні.

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


Завантажння з ISO-образу на USB Flash

Прикро, але досі більшість виробників "заліза" випускають свої діагностичні утиліти для найпоширенішої ОС. А ще прикріше, коли ці утиліти під нею не працюють, як сталося у моєму випадку: SeaTools for Windows ніяк не хотіли запускатись.

Насправді все не так погано, Seagate знає про існування інших систем, і на цей випадок зробив SeaTools for DOS, які можна завантажити у вигляді завантажувального ISO-образу. Новий виток "розваг" чекає на вас, якщо комп'ютер не має CD/DVD або під рукою не виявиться "болванки", на яку можна було б записати образ. Як завжди, у скрутній ситуації нас виручить Linux.

Тут закінчується лірика і починається інструкція по запису ISO-образу на USB Flash у такий спосіб, щоб з нього можна було завантажитись. !!! Файлова система на Flash-накопичувачі повинна бути FAT23

Якщо раптом у системі не встановлено пакунок syslinux:

# apt-get install syslinux

Копіюємо MBR із завантажувачем:

# cat /usr/lib/syslinux/mbr.bin /dev/sdX

! MBR копіюється саме на пристрій, а не розділ, наприклад, /dev/sdc

Встановлюємо SYSLINUX на розділ:

# syslinux /dev/sdXY

! А тут уже розділ, наприклад, /dev/sdc1

Монтуємо Flash-накопичувач, якщо він не примонтувався автоматично і копіюємо файли в його корінь:

# cp /usr/lib/syslinux/memdisk /media/flash
# cp ~/downloads/SeaToolsDOS223ALL.ISO /media/flash/

Також у корінь вашого Flash-накопичувача потрібно помістити конфігураційний файл syslinux.cfg з таким вмістом:

DEFAULT SeaTools

LABEL SeaTools

  LINUX memdisk

  INITRD SeaToolsDOS223ALL.ISO

  APPEND iso

Все! Тепер можна завантажуватись з цього накопичувача і користуватись утилітами.

Цей спосіб навряд чи підійде для запису ISO-образів установочних дисків ОС Windows, але усілякі "Utility" і "Firmware" працюють.

По матеріалам статті Preparing a bootable SeaTools USB drive in Fedora від Felix Kaechele.


SSH прості хитрощі

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

Є багато засобів захисту SSH від тупих атак "китайських хакерів", найочевидніший – прикрити фаєрволом від "світу", залишивши доступ тільки з відомих довірених мереж/вузлів. Але такий варіант не завжди підходить, наприклад, є машини які використовуються у якості "точок входу" (на випадок коли немає можливості підключитись по VPN). Стійкі паролі досить надійно захищають від грубих атак, але армія роботів все одно спробує переконати сервер що пароль "Мао*Дзедун", їхні спроби засмічують журнали, що в будь-якому разі не є добре.

Найпростіший спосіб направити цю армію по хибному шляху, перенести службу SSH на інший нестандартний порт, наприклад, tcp/227 або будь-який інший не задіяний для стандартних служб.

!!! Будьте обережні, особливо якщо сервер віддалений, при зміні налаштувань не "зарубайте" доступ самому собі. Для цього виконуйте зміни у наступному порядку:

  • до конфігурації фаєрволу додайте правило, яке дозволить з'єднання по новому нестандартному порту;
  • змініть порт у налаштуваннях SSHd;
  • перевірте з'єднання по новому порту;
  • і тільки тепер заберіть правило, яке дозволяло з'єднання по стандартному порту.

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

~$ ssh -p 227 server.example.com

Справжні спеціалісти не люблять дурної роботи, тому ми навчимо ssh-клієнт пам'ятати у якого сервер який порт використовується. Для цього допишіть у файл ~/.ssh/config ось такі рядки:

Host server.example.com

Port 227

Після цього вам не потрібно буде кожного разу вказувати порт вручну.

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

Host dev

HostName developer.example.com

User vasyadev

Port 227

IdentityFile developer_key

Почитайте man ssh_config. Що краще ви знаєте свій інструмент, то більш ефективною стає ваша робота.


408 - Підступний Chrome

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

Віднедавна я почав помічати на кількох web-серверах (apache2) помилку 408 "Request timeout". Причому кількість помилок поступово зростала. "Фізичний зміст" помилки - браузер встановив з'єднання з сервером, але не надіслав запит протягом відведеного на це часу, тоді сервер закриває з'єднання з помилкою 408.

Перші пояснення, які мені вдалося знайти на форумах, зводилися до (D)DoS атак або злих хробаків. Обидві гіпотези майже зразу спростувалися: сервіси глибоко внутрішні - DDoS-у взятись нема звідки; майже половина машин, які засвітилися з такою помилкою - це робочі станції локальної мережі з ОС Ununtu, які обслуговуються кваліфікованими адміністраторами.

Але другий підхід до цієї проблеми (лишити її так я не міг, Logwatch щодня про неї нагадував) навів мене на справжнього винуватця, ним виявився браузер Chrome від "корпорації добра". Для зменшення часу відкривання сторінок, ця зараза має "фічу" speculative pre-connect, тобто про всяк випадок відкриває з'єднання заздалегідь, сподіваючись що від сервера ще щось знадобиться і тоді треба буде тільки послати запит. На цю "фічу" завели "баг репорт" :)

На цьому місці я зміг посміхнутись і вирішити залишити все як є, навантаження на сервери не велике, Chrome-ів мало. Але для серверів з більшим навантаженням може знадобитись зменшити значення Timeout у конфігурації Apache, щоб зменшити імовірність вичерпання максимальної кількості одночасно підключених клієнтів (MaxClients).

Дуже сподіваюся, що скоро вони таки «improve the accuracy of our preconnect target»


Використовуємо "резервне" місце на ext3/ext4

Сьогодні напишу про дуже просту штуку, але я про неї не зразу згадав, тому можливо і вам буде цікаво.

Є маленький сервер, який використовується для резервного копіювання з допомогою Bacula. Для зберігання резервних копій у нього окремий розділ (515.4 GB) з ext4. Одного дня перестало вистачати місця для зберігання резервних копій протягом 30-днів, забракло якихось 20GB. Я вже заходився підключати новий диск, більший. Аж раптом згадав...

...що при створенні файлових систем ext3/ext4, по замовчуванню 5% резервується на випадок переповнення диску. Ці блоки доступні лише для користувача root, щоб він міг увійти на систему з переповненим диском. Це дуже завбачливо, але є кілька "але":

  • 5% це резонна величина для маленьких дисків/розділів, але для 1 TB - це 51 GB;

  • для успішного входу супер-користувача місце потрібно на / і /tmp, на інших розділах (/home, наприклад) цього не треба;

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

Тому, діючи дуже обережно, ми зменшимо кількість зарезервованих блоків або відключимо резервування, змінивши налаштування ФС.

Подивимось скільки ж ми "втрачаємо":

# tune2fs -l /dev/sdc5 | grep -i block
Block count:              125828608
Reserved block count:     6291430
Free blocks:              488281
... skip ...
Block size:               4096
... skip ...

Як бачимо, 6291430*4096=25.769.697.280 байт дискового простору "гуляє". Для зміни кількості зарезервованих блоків використовується та ж команда, тільки з опцією -m:

# tune2fs -m <скільки відсотків резервувати> /dev/sdb5

Щоб повністю відключити резервування вкажіть кількість відсотків - 0:

# tune2fs -m 0 /dev/sdс5
tune2fs 1.41.11 (14-Mar-2010)
Setting reserved blocks percentage to 0% (0 blocks)
# tune2fs -l /dev/sdc5 | grep -i block
Block count:              125828608
Reserved block count:     0
Free blocks:              6779711
... skip ...
Block size:               4096
... skip ...

"Звільнилася" купа місця :)

Увага! Зовсім не потрібно бігти відключати резервування на всіх-всіх-всіх розділах, при невисокій ціні на жорсткі диски, 5% не така висока ціна за додаткову надійність. Тому міняйте налаштування резервування блоків тільки тоді, коли точно знаєте що робите.

Я би просто полінувався міняти, але морока зі зміною розділів була більшою ;) Про LVM там теж вчасно не згадали :)


Перенаправлення запитів з HTTP на HTTPS

Часто виникала необхідність зробити автоматичне перенаправлення всіх запитів з http на https, а головне зробити це максимально простим способом і не влазячи в код програми.

А робиться це наступним чином, в потрібному (найчастіше webroot) каталозі розмішується .htaccess з наступним вмістом:

RewriteEngine OnRewriteCond %{HTTPS} offRewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

PostgreSQL schema diff

Я з 2008-го року мріяв про інструмент який шукає різниці між схемами БД, а виявляється є такий. Зустрічайте - Another PostgreSQL Diff Tool (apgdiff)!

apgdiff є в репозиторіях Ubuntu. Дуже дивно як я його раніше не знайшов.


Прості правила зберігання даних (Linux)

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

Маємо сервер з ОС Linux та програмним RAID1 або RAID5, хоча поради будуть слушні і для інших типів масивів.

Моніторинг RAID-масиву

Відкрийте файл /etc/mdadm/mdadm.conf, та розкоментуйте і виправте, вказавши потрібну E-mail адресу, наступний рядок:

MAILADDR sysadmin@ваш.домен.ua

Моніторинг стану жорстких дисків (всіх, не тільки з RAID масиву)

Про те, що диск скоро треба буде замінити, хотілося б знати заздалегідь, для цього ми налаштуємо smartd з пакунку smartmontools.

Відкрийте файл /etc/default/smartmontools та розкоментуйте рядок:

start_smartd=yes

, це дозволить smartd запускатись при старті системи.

Стандартна конфігурація smartd передбачає автоматичний пошук дисків, які підтримують S.M.A.R.T., тому вам достатньо відредагувати файл /etc/smartd.conf, встановивши правильну E-mail адресу в опції автопошуку:

DEVICESCAN -m sysadmin@ваш.домен.ua -M exec /usr/share/smartmontools/smartd-runner

Після перезапуску в журналі /var/log/syslog ви побачите приблизно таке:

Jul 19 14:21:21 psi smartd[18491]: smartd version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Jul 19 14:21:21 psi smartd[18491]: Home page is http://smartmontools.sourceforge.net/#012
Jul 19 14:21:21 psi smartd[18491]: Opened configuration file /etc/smartd.conf
Jul 19 14:21:21 psi smartd[18491]: Drive: DEVICESCAN, implied '-a' Directive on line 22 of file /etc/smartd.conf
Jul 19 14:21:21 psi smartd[18491]: Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
Jul 19 14:21:21 psi smartd[18491]: Problem creating device name scan list
Jul 19 14:21:21 psi smartd[18491]: Device: /dev/sda, opened
Jul 19 14:21:21 psi smartd[18491]: Device /dev/sda: using '-d sat' for ATA disk behind SAT layer.
Jul 19 14:21:21 psi smartd[18491]: Device: /dev/sda, opened
Jul 19 14:21:21 psi smartd[18491]: Device: /dev/sda, found in smartd database.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sda, is SMART capable. Adding to "monitor" list.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdb, opened
Jul 19 14:21:22 psi smartd[18491]: Device /dev/sdb: using '-d sat' for ATA disk behind SAT layer.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdb, opened
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdb, found in smartd database.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdb, is SMART capable. Adding to "monitor" list.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdc, opened
Jul 19 14:21:22 psi smartd[18491]: Device /dev/sdc: using '-d sat' for ATA disk behind SAT layer.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdc, opened
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdc, not found in smartd database.
Jul 19 14:21:22 psi smartd[18491]: Device: /dev/sdc, is SMART capable. Adding to "monitor" list.
Jul 19 14:21:22 psi smartd[18491]: Monitoring 0 ATA and 3 SCSI devices

На одному з серверів я мав проблему з автовизначенням, тому довелося закоментувати DEVICESCAN та прописати диски вручну, ось так:

/dev/sda -a -d sat -m sysadmin@ваш.домен.ua
/dev/sdb -a -d sat -m sysadmin@ваш.домен.ua

, де -a — набір стандартних перевірок, -d — для дисків схованих за 'SAT layer' (у сучасних дистрибутивах всі диски виглядають та керуються, як диски з послідовним інтерфейсом), -m — адреса, куди надсилатимуться звіти та попередження.

Запускаємо smartd:

/etc/init.d/smartmontools start

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


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+, хоч і без журналювання, зате «з коробки» на читання/запис, чим вкотре підтвердив свою позитивну репутацію «приспособлєнца».