The post has been translated automatically. Original language: Russian
Hello, community!
The DR-plan often looks decent: scheme, system table, RTO, RPO, responsible persons, recovery procedure. But so far, the team has never run this scenario with their hands, this is not a plan - this is an assumption.
The most unpleasant thing about an accident is that not only what was in focus breaks. Dependencies break down. And they are the ones that usually pop up on DR-tests.
What is detected during a normal DR-drill?
1. The system depends on services that are not included in the plan
We wanted to restore the ERP, but we need AD, DNS, VPN, licensing, a file system, a message queue, integration with the bank, and a notification service. Formally, they are "auxiliary", but without them the critical system does not start.
2. Access points are not ready
Passwords are outdated, no one has checked the break-glass account, the MFA is tied to a specific employee, the documentation is in an inaccessible wiki, and the rights on the backup circuit differ from production.
3. The network differs from the scheme
There are routes on paper. In practice, DNS looks the wrong way, the firewall cuts the desired port, the VPN does not rise, the NAT is configured differently, and the application stores a hardcoded IP.
4. There is a backup, but the recovery is not going through
Incomplete copy, broken data, incorrect version, restore too slow, lack of space, dependence on storage, which itself is unavailable. A backup without a recovery test is not protection, but hope.
What should be in a mature DR process?
- A runbook with specific actions, not general words;
- list of systems and dependencies;
- Roles and escalations;
- actual RTO/RPO measurements;
- criteria for successful recovery;
- report after the test;
- backlog of fixes.
CloudFort can conduct scheduled DR exercises: raise a test scenario, verify recovery, record actual RTOS/RpoS, and help update the plan.
At DRaaS, it is important not only to have a backup resource, but also to regularly verify that this resource will actually save the business at the time of the accident.
Bottom line: If the DR plan hasn't been tested, you don't have a plan. You have the file.
Colleagues, how often do you actually run DR scripts? And what breaks down most often on tests: the network, accesses, DNS, startup order, or the backups themselves? 👇
And, by the way, we have special conditions for our services for all AstanaHub participants - please contact us!
#CloudFort #AstanaHub #DRaaS #DisasterRecovery #SRE #DevOpsKZ #RTO #RPO #Backup #BusinessContinuity
Привет, комьюнити!
DR-план часто выглядит прилично: схема, таблица систем, RTO, RPO, ответственные, порядок восстановления. Но пока команда ни разу не запускала этот сценарий руками, это не план - это предположение.
Самое неприятное в аварии: ломается не только то, что было в фокусе. Ломаются зависимости. И именно они обычно всплывают на DR-тестах.
Что обнаруживается во время нормального DR-drill?
1. Система зависит от сервисов, которых нет в плане
Хотели восстановить ERP, но нужны AD, DNS, VPN, лицензирование, файловая шара, очередь сообщений, интеграция с банком и сервис уведомлений. Формально они «вспомогательные», но без них критичная система не стартует.
2. Доступы не готовы
Пароли устарели, break-glass учетку никто не проверял, MFA завязан на конкретного сотрудника, документация лежит в недоступной wiki, а права на резервном контуре отличаются от production.
3. Сеть отличается от схемы
На бумаге маршруты есть. На практике DNS смотрит не туда, firewall режет нужный порт, VPN не поднимается, NAT настроен иначе, а приложение хранит hardcoded IP.
4. Бэкап есть, но восстановление не проходит
Неполная копия, битые данные, неверная версия, слишком медленный restore, нехватка места, зависимость от хранилища, которое само недоступно. Бэкап без recovery test - это не защита, а надежда.
Что должно быть в зрелом DR-процессе?
- Runbook с конкретными действиями, а не общими словами;
- список систем и зависимостей;
- роли и эскалации;
- фактические замеры RTO/RPO;
- критерии успешного восстановления;
- отчет после теста;
- backlog исправлений.
CloudFort может проводить DR-учения по расписанию: поднимать тестовый сценарий, проверять восстановление, фиксировать фактические RTO/RPO и помогать обновлять план.
В DRaaS важен не только резервный ресурс, но и регулярная проверка того, что этот ресурс действительно спасет бизнес в момент аварии.
Итог: если DR-план не тестировался, у вас нет плана. У вас есть файл.
Коллеги, как часто вы реально прогоняете DR-сценарии? И что чаще всего ломается на тестах: сеть, доступы, DNS, порядок запуска или сами бэкапы? 👇
И, кстати, для всех участников AstanaHub у нас действуют особые условия на наши сервисы - обращайтесь!
#CloudFort #AstanaHub #DRaaS #DisasterRecovery #SRE #DevOpsKZ #RTO #RPO #Backup #BusinessContinuity
Share
