разумная стратегия резервного копирования для веб-приложений

Question

Я создаю веб-приложение, и мне нужен план резервного копирования.Вот что у меня есть на данный момент:

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

:)