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