Чи повинен я і як зробити резервну копію бази даних для веб-додатків, розміщених на сервері Amazon EC2?

Я створив екземпляр Amazon EC2 за допомогою серверного видання Ubuntu, і встановив на ньому стек LAMP . Я створив веб-додаток PHP, що працює на MySQL. Я протестував веб-додаток на Amazon EC2, і він працює.

Я офіційно не запускав, але мені потрібно це знати перед запуском. Чи варто робити резервну копію даних бази даних? Якщо так, то як мені це зробити максимально економічно?

Раніше для іншої веб-програми я писав сценарій Perl або Bash (не пам'ятаю), який виконуватиметься cron щодня.

Потім сценарій створить резервну копію бази даних в єдиний .sqlфайл і надішле як вкладення електронної пошти на мій обліковий запис Gmail.

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

Для цієї нової веб-програми на веб- сервісах Amazon (AWS) я не визначився, оскільки:

1. Я не думаю, що це гарне рішення, оскільки дані, що надсилаються по електронній пошті, не є безпечними. Наскільки я пам'ятаю, SSL немає, хоча це було дешеве рішення. Безкоштовно. Легко отримати за датою.

2. Амазонка, можливо, зробила для мене зайвим робити резервне копіювання, оскільки вони вже роблять це. Все, що мені потрібно знати, - це відновити його у випадку катастрофи ( торкніться деревини )

   • (Я підозрюю) існує чудовий і економічно ефективний спосіб зробити резервне копіювання за допомогою Amazon S3 .

3. Я дозволяю користувачам завантажувати файли, тому мені потрібно якось також створити резервну копію цих файлів. Якого я не знаю, як і ніколи раніше цього не робив у будь-якій формі.

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

Фон:

• Я абсолютно не знайомий із AWS. Знати лише стільки, скільки налаштувати рахунок. Це все.

• << Однорічний досвід роботи як Ubuntu. Більшу частину свого життя в Windows.

• Здебільшого інтимний з програмуванням PHP. Володіння іншими мовами програмування не так добре через недостатнє використання.

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

Також слід попередити, що якщо ваш сервер EC2 знаходиться в сховищі примірників, дані будуть стерти, якщо сервер коли-небудь зупиниться. Для постійного зберігання ваші дані повинні містити об'єм еластичного блокового сховища (EBS). Після того, як він буде розміщений на томі EBS, ви можете робити періодичні знімки (вручну або автоматизовано за допомогою API Amazon), які потім дозволять вам повернутися до більш старих версій. PHP AWS для PHP досить непоганий, і ви можете його знайти тут: http://aws.amazon.com/sdkforphp/ .

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

Резервне копіювання MySQL в S3 дуже поширене, і це добре зафіксовано у багатьох блогах. Я рекомендую дотримуватися посібника тут http://agiliq.com/blog/2009/02/automatically-backup-mysql-database-to-amazon-s3-u/

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

Який би метод ви не вибрали, під час створення резервної копії я б дотримувався наступних кроків

1. Створюйте резервну копію щодня
2. Надішліть резервну копію на S3 (обов'язково використовуйте контрольну суму MD5, щоб ви знали, що ваша резервна копія хороша)
3. Завантажте резервну копію з S3 локально або у іншого постачальника, а не S3
4. Очистіть старі резервні копії, використовуючи прокатну історію резервного копіювання
   • Зберігайте резервну копію останніх 7 днів
   • Зберігайте резервну копію п'ятниці щотижня протягом 1 місяця
   • Зберігайте резервну копію минулого місяця протягом 1 року