Почти все компании утверждают, что у них есть резервные копии, по крайней мере важнейших компонентов, но, как сетует Райан Берч, директор по информационным технологиям в New Harbour Capital, «выглядит очевидным, но часто забывается, что резервная копия, из которой никогда не проводилось восстановление, – это не резервная копия, а просто способ расходования хранилища, что-то, что создает иллюзию безопасности, как страховочный трос, который ни к чему не прикреплен».
Организация резервного копирования – это сложная задача, и, пока вы не выполните полное восстановление системы из резервной копии, вы не сможете узнать, действительно ли в ней сохраняются все компоненты.
Первый вопрос, на который вы должны ответить: что сохранять? Только данные, или же данные и конфигурацию, или же и данные, и конфигурацию, и само приложение? Ответ зависит в первую очередь от цели резервного копирования. Она может быть следующей:
• Восстановление в случае сбоя.
• Периодическая фиксация состояния для контроля соответствия требованиям.
• Использование для целей тестирования/разработки.
В подавляющем большинстве случаев резервные копии создаются для обеспечения бесперебойной работы, и в этом случае важно время восстановления. С каждой минутой простоя компания теряет деньги, а также репутацию и доверие к бренду. Отработанная стратегия резервного копирования станет залогом вашего душевного спокойствия, поскольку в случае аварии вы будете иметь четкий план действий и понимать сроки восстановления.
Обычно рекомендуется хранить файлы резервных копий в зашифрованном виде в отдельной сети или в отдельной учетной записи в облачном сервисе. Но часто, особенно в небольших организациях, резервные копии хранятся не отдельно, а на том же самом компьютере. Исходите здесь не из того, что сбой возможен, а из того, что в какой-то момент он обязательно случится.
Необходимо делать резервное копирование не только для тех сервисов, которые вы обслуживаете самостоятельно, но и для всего, что хранится в сторонних сервисах. Например, регулярно копируйте исходный код, размещенный на GitHub или Bitbucket, в безопасное и управляемое вами место. Часто забывают и о Salesforce, особенно если он применяется в основном как облачная база данных. Если вы используете Google Диск, Office 365, Dropbox – любой сервис, в котором вы храните данные, – спросите себя, к каким последствиями приведет потеря доступа к нему или блокировка учетной записи?
Чтобы создать надежную стратегию резервного копирования и восстановления, требуется много усилий; кроме того, понадобится выполнить первое архивирование и копирование данных и настроек. Но после этого все должно работать на автопилоте, а отчеты должны регистрироваться в централизованной системе журналирования, чтобы вы получали оповещения, если резервное копирование не было выполнено или произошла какая-то ошибка.
Отработайте восстановление системы. Создайте план действий и разместите его в доступном месте, чтобы любой, кто имеет необходимые доступы, мог легко собрать и восстановить систему. Проводите учения не реже, чем раз в год (или даже чаще), чтобы убедиться, что есть резервные копии для всех необходимых компонентов.