Способ для резервного копирования серверов EC2?
Мы запускаем около десятка производственных экземпляров веб-сервера Ubuntu Linux на Amazon VPC. Экземпляры загружаются и управляются через Puppet. Большая часть управления осуществляется через Консоль AWS.
Наши учетные данные AWS довольно безопасны. Мастер-аккаунт практически не нужен, имеет надежный пароль и двухфакторную аутентификацию. Несколько доверенных администраторов имеют доступ к большинству служб через свои собственные учетные записи IAM, а также с надежными паролями и двухфакторной аутентификацией. Некоторые учетные записи IAM имеют очень ограниченный доступ для определенных целей, таких как запись файлов в S3. Доступ других сотрудников к любым учетным данным высокого уровня очень ограничен. В целом, вероятность получения доступа к консоли или API кажется низкой.
Недавний провал Code Spaces, когда кто-то получил высокоуровневый доступ к своей консоли AWS и удалил экземпляры, тома и моментальные снимки EBS, фактически лишив возможности Code Spaces восстановить свой бизнес, заставил меня исследовать методы резервного копирования наших данных. линия / вне сети (т.е. вне зоны досягаемости нашей основной учетной записи AWS).
Как я могу гарантировать, что данные наших клиентов защищены от уничтожения кем-то, кто получает доступ к нашим учетным данным AWS, или от какой-либо аварии в AWS? Должно быть автоматическим, стабильным и по разумной цене.
Кажется, я не могу найти "легкий" путь после нескольких часов поиска. Копирование снимков EBS в другую учетную запись AWS не представляется возможным. Я не могу экспортировать снимки EBS в объекты S3. Я мог бы rsync все важные данные, извлекая из стороннего сервера, но мне нужно было бы сценарий, чтобы обрабатывать такие вещи, как различное количество серверов, хранения, обработки ошибок и т. Д. Похоже, много работы. Я не нашел готового программного обеспечения для этого.
Наша текущая стратегия резервного копирования состоит из ночных автоматических снимков EBS всех томов, а также загрузки сжатых MySQLdumps на S3. Весь исходный код и код Puppet развернут из внешнего управления версиями, но файлы наших клиентов и базы данных MySQL хранятся только на томах EBS и их снимках, т.е. внутри экосистемы AWS.
1 ответ
Многие люди склонны задумываться над этим. Просто подумайте об этих серверах, как если бы они были развернуты в корпоративном или корпоративном центре обработки данных. В таком случае, как бы вы их поддержали?
Скорее всего, это будет через "устаревший" продукт резервного копирования (Netbackup, Amanda, BareOS и т. Д.), Который подключен к ленточной библиотеке или VTL.
Это то, что вы должны рассмотреть для своей инфраструктуры AWS. Создайте сервер резервного копирования и ленточную библиотеку за пределами Amazon и используйте его в качестве метода восстановления "конца света".
Лента является одним из самых надежных механизмов хранения данных и, в отличие от всех других систем облачного резервного копирования, не подвержена типу событий, происходящих с CodeSpaces. Ваши резервные данные действительно находятся в автономном режиме, и вы можете хранить ленты в безопасном месте по вашему выбору - от пожарного сейфа в офисе до аренды сейфа в местном банке. Получить такую защиту от поставщика облачного хранилища невозможно.
У вас уже есть управление конфигурацией на месте. (Да!) Так что в случае аварии вы сможете перестроить свои серверы достаточно быстро, поэтому резервное копирование на магнитную ленту (или VTL) будет в основном для ваших данных. Базы данных, загруженные файлы и т. Д. Вещи, которые не охватываются вашими марионеточными манифестами.
Если это не вариант, следующим лучшим вариантом будет создание совершенно отдельной учетной записи AWS для целей резервного копирования. Внутри этой учетной записи создайте учетные данные IAM для S3, которые имеют разрешения только на загрузку, а затем используйте их в своей производственной среде для отправки резервных копий. Убедитесь, что эти учетные данные хранятся в совершенно отдельном месте от производственных учетных данных, чтобы ограничить вероятность того, что они оба будут скомпрометированы одновременно.