разумная стратегия резервного копирования для webapps

Question

Я делаю webapp и нуждаюсь в резервном плане. Вот что у меня до сих пор:

• еженощно зашифрованное резервное копирование базы данных SQL на Amazon S3 и мой внешний диск (инкрементальный, если это возможно, не слишком знакомы с PostgreSQL еще, но это другая тема)
• еженощно резервное копирование моего Mercurial repo (включая конфигурацию Apache, развертывание скриптов и т. д.) на S3 (с локальными резервными копиями через Time Machine)

Следует ли добавить что-нибудь еще или накрыть его? Для определения того, насколько важны данные/будет, это приложение для управления проектами по строкам Basecamp.

Answer 1

Недельная полная резервная копия вашей базы данных, а также ночные инкрементные, а может быть?

Это означает, что если одна из ваших старых инкрементных резервных копий повреждена, вы потеряли менее недели данных.

Кроме того, убедитесь, что у вас есть план резервного копирования, чтобы обеспечить резервное копирование. Есть много историй ужасов вокруг этого, от компаний, которые делали резервные копии в течение многих лет, никогда не проверяя их, а затем выясняя, что ни один из них не является хорошим, когда они в них нуждаются. (Я тоже был в такой компании. К счастью, я заметил, что резервные копии не работали до того, как они были необходимы, и исправили проблемы).

Answer 2

Одна из лучших стратегий, которые работали для меня в прошлом, заключалась в том, чтобы процесс «резервного копирования» был таким же, как и процесс установки, то есть мы полностью выполнили сценарий в Linux, конфигурацию сервера, создание приложений, настройку базы данных и т. Д. и т.д. поэтому установка будет выглядеть так:

./install.sh [сервер] [имя приложения] и резервное копирование/восстановление ./install [сервер] [имя приложения] -database [файл резервной копии базы данных]

С точки зрения резервного копирования база данных была полностью скопирована (база данных MySQL), cronjob

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

Это была установка для корпоративного приложения Saas, которое я проработал несколько лет назад, поэтому у нас был полный контроль над серверами.

Answer 3

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

Однако, если вы используете дифференциал, то каждый дифференциал содержит все изменения с момента последнего резервного копирования. поэтому, даже если одна из резервных копий не удалась ранее на этой неделе, вы все равно сможете полностью восстановить, если у вас есть успешная недавняя резервная копия.

Надеюсь, я объясню это хорошо!

:)