
Я настроилАмазон EC2экземпляр с использованием серверной версии Ubuntu, и я установилЛАМПАstack на нем. Я сделал веб-приложение PHP, работающее на MySQL. Я протестировал веб-приложение на Amazon EC2, и оно работает.
Я официально не запустился, но мне нужно знать это перед запуском. Нужно ли мне делать резервную копию данных моей базы данных? Если да, то как это сделать максимально экономически эффективно?
Ранее для другого веб-приложения я написал скрипт Perl или Bash (не помню), который будет выполнятьсяхронежедневно.
Затем скрипт создаст резервную копию базы данных в один .sql
файл и отправит его в виде вложения к электронному письму на мой аккаунт Gmail.
Это веб-приложение было на общем хостинге, поэтому я был уверен, что мне нужно сделать резервную копию моей базы данных. Мои файлы находятся в репозитории Git, поэтому я не беспокоюсь об этом.
Для этого нового веб-приложения наВеб-сервисы Amazon(AWS), я не определился, потому что:
Я не думаю, что это хорошее решение, так как данные, отправленные по электронной почте, небезопасны. Насколько я помню, SSL нет, хотя это было дешевое решение. Бесплатно. Легко восстанавливается по дате.
Amazon, возможно, сделал резервное копирование излишним, потому что они уже это делают. Все, что мне нужно знать, это как восстановить его в случае катастрофы (постучать по дереву)
- (Я подозреваю) есть более совершенный и экономически эффективный способ сделать резервную копию, используяАмазон S3.
Я разрешаю пользователям загружать файлы, поэтому мне нужно как-то делать резервные копии и этих файлов. Чего я не знаю, как делать, и никогда не делал этого раньше ни в какой форме.
Что мне нужно: ежедневное резервное копирование моей базы данных и файлов изображений с максимальной экономией, а также четкое пошаговое руководство по его реализации и восстановлению в случае аварии.
Фон:
Я совершенно не знаком с AWS. Знаю только, как настроить аккаунт. Вот и все.
<< Годовой опыт новичка в Ubuntu. Большую часть жизни в Windows.
В основном близок к программированию на PHP. Знание других языков программирования не столь хорошее из-за отсутствия использования.
решение1
Amazon хранит файлы вашей базы данных на избыточном хранилище, но предоставляет лишь ограниченную информацию о том, как оно настроено, поэтому вам придется составить собственное мнение о том, подходит ли это для ваших нужд. Однако они не хранят старые версии, поэтому это защитит вас только от сбоя оборудования, а не от какой-либо пользовательской ошибки (которая более вероятна, чем сбой оборудования).
Также имейте в виду, что если ваш сервер EC2 находится в хранилище экземпляров, данные будут стерты, если сервер когда-либо остановится. Для постоянного хранения ваши данные должны находиться на томе Elastic Block Storage (EBS). После того, как они будут на томе EBS, вы можете делать периодические снимки (вручную или автоматически с помощью API Amazon), что позволит вам затем откатиться к более старым версиям. AWS SDK для PHP довольно хорош, и вы можете найти его здесь:http://aws.amazon.com/sdkforphp/.
решение2
У Amazon очень много сервисов, иногда это может сбивать с толку всеми этими технологиями. Имейте в виду, что Amazon создает все эти сервисы для решения конкретных проблем.
Резервное копирование MySQL в S3 очень распространено и хорошо документировано во многих блогах. Я рекомендую следовать руководству здесьhttp://agiliq.com/blog/2009/02/automatically-backup-mysql-database-to-amazon-s3-u/
Никогда ничего не предполагайте, S3 разработан как отказоустойчивое устройство хранения, но это не помешает мне делать резервные копии всего локально на моем компьютере или у какого-то другого провайдера. Тома EBS недостаточно надежны, чтобы быть единственным устройством хранения для вашей резервной копии, не говоря уже о том, что ваша база данных также хранится на том же диске.
Какой бы метод вы ни выбрали, я бы рекомендовал вам следовать следующим шагам при создании резервной копии:
- Создавайте резервную копию ежедневно
- Отправьте резервную копию на S3 (обязательно используйте контрольную сумму MD5, чтобы быть уверенным в надежности резервной копии)
- Загрузите резервную копию с S3 локально или у другого провайдера, не S3
- Очистка старых резервных копий с использованием истории скользящего типа резервного копирования
- Сохраните резервную копию за последние 7 дней.
- Сохраняйте резервную копию пятницы каждую неделю в течение 1 месяца.
- Хранить резервную копию последнего месяца в течение 1 года