Резервные копии AWS RDS

Поэтому недавно я начал использовать AWS и Elastic Beanstalk с RDS.

Интересно, каковы наилучшие методы создания резервных копий базы данных?

Пока моя установка такая.

  1. Включите автоматическое резервное копирование.
  2. bash, который каждый день создает снимки вручную и удаляет снимки старше 8 дней.
  3. bash, который создает дамп базы данных в формате sql и загружает его на S3.

Причина, по которой я создаю моментальные снимки вручную, заключается в том, что если бы я удалил базу данных по ошибке, то у меня все еще были бы моментальные снимки.

Сценарии bash находятся в экземпляре EC2, запущенном с ролью IAM, которой разрешено выполнять эти сценарии.

Я на правильном пути здесь?

Я очень ценю ответы, спасибо.


person hendricks    schedule 02.11.2016    source источник


Ответы (1)


Немного контекста...

То, что автоматические резервные копии не сохраняются после удаления БД, является очень важной технической проблемой. Я видел, как это застало разработчиков врасплох, так что спасибо, что подняли этот вопрос.

После удаления экземпляра БД RDS сохраняет этот последний моментальный снимок БД и все другие созданные вручную моментальные снимки БД на неопределенный срок. Однако все автоматизированные резервные копии удаляются и не могут быть восстановлены при удалении экземпляра БД. источник

Я подозреваю, что большинству людей достаточно финального снимка.

По заданному вопросу...

  1. Да. 110%. Абсолютно.

  2. Я бы не стал создавать снимки вручную; скорее скопируйте автоматизированные.

    Вариант 1. У вас уже есть доступные автоматические моментальные снимки. Почему бы просто не скопировать автоматический снимок (меньше ненужной нагрузки на БД; хотя, по общему признанию, меньше проблем, если вы находитесь в нескольких зонах доступности, поскольку вы будете делать снимки из реплики), который создал снимок вручную . Я бы автоматизировал это, используя aws sdk и задание cron.

    Вариант 2: требуется ручное прилегание. Просто скопируйте свои автоматические снимки (для создания снимков вручную) перед завершением работы БД.

  3. Непонятно, зачем вам нужен дамп s3, если у вас есть снимки.

    Для изменений схемы?: Если вы делаете это для изменений схемы, они действительно должны обрабатываться с помощью миграции (мы используем knex.js, но выбери свой яд). Если это слишком далеко, помните, что есть вариант для дампов только схемы (pg_dump --schema-only). Гораздо более управляемый.

    Получение данных? Ваши снимки уже находятся на s3, см. часто задаваемые вопросы . Вы всегда можете загрузить снимок и сделать дамп sql, если захотите. Я не вижу сразу очевидной причины для преднамеренного дублирования ваших данных.

person rmharrison    schedule 02.11.2016