Стратегія резервного копіювання Amazon EC2

У мене є кілька налаштувань веб-сервера / DB-сервера за допомогою EC2 Amazon. Я щодня роблю знімки всіх моїх системних та електронних дисків, що містять усі мої файли додатків, файли БД, вихідний код та резервні копії БД. У мене є консольний додаток, який виконує створення резервних копій за графіком. Мої зображення - це зображення EBS.

Я працюю над завданням, яке скине мої знімки через стільки днів. Я думаю, моє запитання: чи / чи можу я також запланувати повне завдання для зображення / EBS? Таким чином, якщо сервер виходить з ладу або пошкоджений, я можу просто запустити останнє зображення, а потім застосувати останній знімок.

Під час роботи над стратегією резервного копіювання я використовую диск Jungle для створення резервних копій дисків даних.

Мої рекомендації:

1. Завжди документуйте та / або скриптуйте налаштування кожного нового примірника, щоб ви могли відтворити інсталяцію програмного забезпечення та конфігурацію системи у випадку втрати цього примірника. Перевірте це, запустивши новий екземпляр і дотримуючись процедури. Ви можете використовувати користувальницький приватний AMI, якщо установка займає тривалий час і вам потрібно швидко запускати екземпляри, але сам AMI повинен бути побудований за допомогою документально підтвердженої та / або скриптованої процедури.

2. Зберігайте важливі дані про окремі томи EBS, а не про кореневий том EBS. Це має багато переваг, включаючи полегшення передачі даних до нових примірників (наприклад, на основі різних AMI) та полегшення отримання копій даних в інших екземплярах (наприклад, з знімками та новими томами).

3. Створюйте регулярні знімки томів даних EBS. Якщо можливо / застосовно, використовуйте такий інструмент, як мій знімок, який відповідає моменту ec2, щоб поліпшити шанси на те, що ви робите знімок послідовної файлової системи / бази даних. Створіть резервні копії даних за межами AWS / EC2, оскільки ваш рахунок AWS сам по собі є єдиною точкою помилки.

4. Час від часу створюйте знімки кореневого тома EBS у важливих екземплярах. Хоча це може допомогти вам у випадку збою обсягу EBS або обсягу EBS, ця частина не є настільки критичною через №1 та №2 вище. Основна причина, що я роблю це, полягає в тому, що створення знімків знижує ризик виходу з ладу самого кореневого обсягу EBS.

Швидкість виходу з ладу об'єму EBS безпосередньо пов'язана з кількістю блоків, які були змінені на цьому томі з моменту останнього знімка EBS.

Чи повинен / я можу також запланувати повне завдання для зображення / EBS?

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

Якщо вас цікавить, я написав клас Java, щоб зробити знімок усіх підключених томів EBS, а також видалити їх через певний час. В даний час я роблю резервну копію щотижня, а третю резервну копію відкидаю через два тижні.

https://github.com/stivlo/obliquid-cp/blob/master/src/main/java/org/obliquid/sherd/runner/RequestSnapshots.java

Він виконує лише одну дію за цикл, наприклад, знімати або видаляти знімок, тому що він повинен бути поміщений у крон щогодини, щоб не перевантажувати десятками знімків одночасно, якщо у вас багато EBS, як у мене.

Ми використовуємо просту, але потужну стратегію резервного копіювання: створити новий AMI на базі запущених екземплярів EC2 EBS два рази на день та видалити "старі" AMI. Через API (CreateImage) ви можете встановити прапор не перезавантажувати екземпляр під час створення нового AMI або, якщо ви використовуєте програмне забезпечення raid - ssh для примірника перед викликом CreateIImage API та заморожувати файлову систему з "fsfreeze" на найбільш популярних файлових системах на нових ядрах або xfs_freeze, якщо ви використовуєте старіші ядра та xfs.

Створений "резервний" AMI запам'ятовує всі підключені до оригінальних запущених дисків EBS (через посилання на створені знімки) і, у разі використання програмних рейдів з декількома дисками, дозволяє відновити новий екземпляр у будь-якому AZ просто за допомогою одного дзвінка API або через Інтернет -інтерфейс.