Partnerfy — надёжный технологический партнёр агентств и брендов. Компания создана, чтобы предоставлять бизнесу решения полного цикла в разработке ПО и цифровом маркетинге.
Хотите программировать будущее вместе с нами?
«Резервные копии есть?» — ответ должен быть «да», но этого мало. Настоящий вопрос другой: «Сможем ли мы действительно восстановиться, за какое время и с какой потерей данных?» Ежечасные зашифрованные резервные копии, три копии на двух типах носителей, одна из них — на удалённой площадке, неизменяемое WORM-хранилище (immutable storage), учения с реальным восстановлением раз в три месяца и чёткие цели RPO/RTO — только это и имеет значение в плохой день.
Непроверенное восстановление — это не резервная копия, а надежда. Мы не продаём надежду: мы даём измеримое время восстановления и подтверждённые отчёты о восстановлении.
При отказе основной системы резервная автоматически принимает нагрузку — это подтверждено реальными учениями.
Первая горькая правда: подавляющее большинство резервных копий никогда не проверяют. Cron срабатывает каждую ночь, в логе написано «OK», дашборд мониторинга горит зелёным, но при попытке восстановиться из этой копии выясняется, что файлы повреждены, ключ расшифровки потерян или версия схемы несовместима. Пока копию не восстановили, это не резервная копия, а всего лишь надежда. С каждым клиентом мы обязательно проводим полные учения по восстановлению не реже раза в три месяца и документируем результат.
Вторая проблема: многое из того, что называют «резервной копией», на деле оказывается снимком (snapshot) на самом рабочем сервере. Копия, которая лежит на том же диске, доступна для записи той же учётной записи и сгорит в том же пожаре, — это не резервная копия, а второе имя для тех же данных. При сбое оборудования, атаке программы-вымогателя (ransomware) или случайном удалении таблицы такая «копия» исчезает вместе с рабочими данными. Настоящая резервная копия должна храниться в отдельной системе, под отдельной учётной записью и в идеале в другом географическом регионе.
Третья проблема: нет копии на удалённой площадке. Резервная копия, которая хранится в одном дата-центре или одном облачном регионе, становится недоступной при сбое в этом регионе, стихийном бедствии или блокировке аккаунта. AWS может отключить целый регион, Microsoft — заблокировать аккаунт за считаные часы, а пожар в дата-центре может длиться часами. В таких сценариях копия на удалённой площадке — единственное, что отделяет непрерывность бизнеса от банкротства. Единица в правиле 3-2-1 не обсуждается.
Четвёртая проблема: незашифрованные резервные копии. Файл резервной копии — это полная копия вашей рабочей базы данных, то есть все записи о клиентах, следы данных банковских карт, хеши паролей и внутренняя переписка лежат в одном архиве tar.gz. Если этот файл украдут, утечка останется утечкой: Общий регламент ЕС по защите данных (GDPR) и KVKK (турецкий закон № 6698 о защите персональных данных) не сделают скидку на то, что это была резервная копия. Все резервные копии должны быть зашифрованы и при хранении (AES-256), и при передаче (TLS 1.3), а ключи должны лежать в KMS отдельно от системы резервного копирования, иначе резервная копия становится поверхностью атаки, а не защитой.
Пятая проблема: нет неизменяемости. Современные программы-вымогатели не просто шифруют рабочие данные: злоумышленник сначала проникает в систему резервного копирования, удаляет или портит копии за последние три месяца и только потом шифрует рабочую среду. Если учётные записи резервного копирования используют тот же каталог, тот же VPN и тот же SSO, что и рабочая среда, вымогатель найдёт и их. Решение — хранилище WORM (write-once-read-many), S3 Object Lock, Veeam Hardened Repository, изолированная офлайн-копия (air gap), то есть уровень, на котором удаление математически невозможно даже с правами администратора.
Шкала восстановления, симуляция очистки от вымогателя и панель сравнения RPO/RTO позволяют заранее измерить решения, которые придётся принимать после аварии.
Ежечасные снимки + ежедневные полные копии + еженедельная консолидация + ежемесячный архив. Точку восстановления можно выбрать с точностью до секунды.
Зашифрованные данные → восстановление из неизменяемой копии → чистые данные отмечены зелёной галочкой.
Оцените с первого взгляда разницу между сценарием «без резервных копий» и нашей архитектурой.
Час потерянных данных — это сотни заказов, тысячи складских операций и сорванная сверка платежей.
Восстанавливать всю таблицу ради данных одного арендатора — не вариант.
Записи о пациентах нужно хранить годами и с возможностью аудита; любая потеря — нарушение KVKK/HIPAA.
Записи для BDDK, SPK и MASAK (финансовые регуляторы Турции) должны годами храниться без удаления и изменений.
Потеряете файлы дизайна, видеопроекты и репозитории кода — придётся обзванивать клиентов по одному.
Петабайты исходных съёмок и невосполнимые исторические материалы требуют отдельной архитектуры.
Стоит потерять конфигурацию одного контроллера, и производственная линия встанет на несколько часов.
Дипломы, выписки с оценками и учёт посещаемости должны быть непрерывными, долговечными и доступными для аудита.
От разработки стратегии до регламента (runbook): десять уровней в одном пакете — ни один не пропущен и ни один не раздут.
Анализ влияния на бизнес, инвентаризация активов, матрица RPO/RTO и цели, закреплённые в договоре.
Физическое или виртуальное устройство на вашей площадке для максимально быстрого восстановления.
Асинхронная или синхронная репликация в другой дата-центр или облачный регион.
Оптимизированные по стоимости резервные копии с политиками жизненного цикла в S3, Blob и GCS.
S3 Object Lock, Wasabi Compliance, Veeam Hardened — уровень, данные в котором нельзя удалить.
PostgreSQL WAL, MySQL binlog, MongoDB oplog, журнал транзакций MSSQL.
VSS, fsfreeze и pre/post-хуки для согласованных образов диска во время записи.
Регулярное восстановление в песочнице + проверка целостности + отчёт.
Пошаговый письменный план: кто выполняет, кто согласует, кто фиксирует.
Триггер → изоляция → форензика → восстановление → образ, чистый по итогам форензики.
Определяем критичность каждой системы, допустимую потерю данных и время восстановления, проводим анализ влияния на бизнес.
Три копии, два типа носителей, один уровень на удалённой площадке; документируем неизменяемость, шифрование и модель доступа.
Запускаем локальное устройство, облачный аккаунт, сетевую изоляцию, мониторинг и оповещения.
Цикл: ежечасно / ежедневно / еженедельно / ежемесячно; AES-256 при хранении, TLS при передаче, отдельные ключи в KMS.
Восстанавливаемся по реальным сценариям, сравниваем измеренные RPO/RTO с целями из договора, устраняем отклонения.
Успешность копирования, динамика хранилища и время восстановления на дашбордах; ежемесячный отчёт + ежегодный пересмотр архитектуры.
Мы не продаём отдельные инструменты сами по себе. Мы проектируем вашу архитектуру, объясняем, какой инструмент подходит для какого уровня, и прозрачно показываем совокупную стоимость владения.
Магазин с 250 тыс. SKU зашифрован в пятницу в 03:14; рабочая среда полностью восстановлена за 38 минут из неизменяемой копии в Wasabi, ни один заказ не потерян.
Разработчик удалил таблицу в рабочей базе; PostgreSQL PITR обеспечил полностью согласованное восстановление за 4 минуты.
Больница прошла аудит PHI за 7 лет; полнота записей в неизменяемом архиве доказана математически.
У старшего дизайнера украли ноутбук; 2 ТБ материалов для клиентов ежечасно копировались на удалённую площадку через Restic.
Архив исходных съёмок вещательной компании перевели на многоуровневое хранение; активный S3 + Glacier Deep Archive дали экономию 63% в год.
Сбой AWS eu-central-1; автоматическое переключение DNS и БД на eu-west-1 за 11 минут, клиентский трафик не прерывался.
Нет, снимок сам по себе — не резервная копия. Снимок — это «фотография» диска или тома на определённый момент, и в подавляющем большинстве случаев он находится в той же системе хранения, что и рабочие данные, а часто и на том же диске. Поэтому при потере рабочих данных теряется и снимок. Сбой оборудования, отказ системы хранения, программа-вымогатель или ошибка администратора затрагивают и его. Снимки отлично подходят как первый уровень для очень быстрого восстановления (вернуться можно за секунды), но, чтобы получить настоящую резервную копию, снимок нужно скопировать в отдельную систему, под отдельную учётную запись и в идеале в другой географический регион. В нашей архитектуре снимок — всегда лишь одна из ступеней: за ним следуют копия на удалённой площадке, неизменяемый архив и репликация для аварийного восстановления.
Правило 3-2-1 — это проверенный годами минимальный стандарт резервного копирования: три (3) копии данных на двух (2) разных типах носителей, причём одна (1) копия хранится на удалённой площадке. Одна из трёх копий — сама рабочая среда, две — резервные, так что, если одна из них повреждена, остаётся вторая. Два типа носителей защищают от системного сбоя одной технологии (например, когда все SSD выходят из строя из-за ошибки в прошивке): диск + лента, диск + объектное хранилище, NAS + облако. Копия на удалённой площадке защищает от пожара, наводнения, кражи, регионального сбоя или блокировки аккаунта; копия в том же здании и даже в том же городе удалённой не считается. Современное расширение правила — «3-2-1-1-0»: одна копия должна быть неизменяемой (1), а тесты восстановления должны показывать ноль (0) ошибок.
Только при правильной архитектуре. Современная программа-вымогатель неделями находится в сети до шифрования рабочей среды: она находит систему резервного копирования, удаляет или портит существующие копии, а затем шифрует рабочую среду, и восстанавливаться становится не из чего. Поэтому учётные записи резервного копирования должны быть независимы от рабочего каталога, рабочего SSO и даже рабочей сети. Решение — хранилище WORM (write-once-read-many): S3 Object Lock в режиме Compliance, Wasabi Compliance, Veeam Hardened Repository, изолированная лента (air gap). На этих уровнях удаление математически невозможно даже с правами администратора: на весь срок хранения данные «заморожены». В нашей архитектуре у каждого клиента есть как минимум один уровень WORM, а сценарий восстановления после атаки вымогателя (playbook) подтверждается учениями.
Мы рекомендуем делать это не реже раза в три месяца, для критичных систем — раз в месяц, а в регулируемых средах — еженедельно в автоматическом режиме. Тестовое восстановление — единственное доказательство того, что ваша архитектура резервного копирования действительно работает; надписи «OK» в логе недостаточно. Полные учения включают восстановление в изолированную песочницу, запуск приложения, проверку целостности базы данных и контрольных сумм, а также сравнение измеренных RPO/RTO с целями из договора. Автоматические тесты после каждого резервного копирования создают виртуальную копию с помощью instant recovery, выполняют интеллектуальное сканирование и сообщают о результате. Для каждого клиента мы проводим и еженедельную автоматическую проверку, и ручные учения раз в три месяца; результаты хранятся в подписанном отчёте, который пригодится при аудите, страховании и продлении договора.
При правильной архитектуре — нет, при неправильной — крайне дорого. У стоимости три основные оси: хранение (за ГБ в месяц), исходящий трафик (скачивание при восстановлении) и вызовы API (плата за каждую файловую операцию). Наивный подход «каждый день полностью заливать всё в S3» может обходиться в десятки тысяч долларов в год. Правильный подход — многоуровневый: последние 14 дней, к которым часто обращаются, — в S3 Standard, последние 90 дней — в S3 Standard-IA, последний год — в S3 Glacier Instant, более старые данные — в Glacier Deep Archive. Для одних и тех же данных стоимость различается в 10–20 раз. С политиками жизненного цикла, сжатием, дедупликацией и стратегией incremental forever расходы типичного клиента на облачное резервное копирование составляют несколько сотен долларов в месяц. Знание своих сценариев восстановления — ключ к правильному расчёту: для того, кто восстанавливается раз в месяц, Glacier Deep может быть отличным вариантом, а для того, кто делает это 5 раз в день, — разорительным.
RPO (Recovery Point Objective) отвечает на вопрос «какую потерю данных мы готовы принять», а RTO (Recovery Time Objective) — на вопрос «как быстро мы должны снова заработать». Оба числа берутся из анализа влияния на бизнес: если система простаивает час или теряется день данных, какова реальная цена с точки зрения выручки, клиентов и регуляторных рисков? В e-commerce почасовая выручка обычно сжимает RTO до минут: для системы приёма заказов RTO в 1 час слишком велик. Для внутренней CRM разумным может быть RTO в 8 часов. Что касается RPO: сколько минут деловой активности вы можете потерять? Ежечасные снимки дают RPO в 60 минут, а репликация журнала транзакций сокращает его до секунд. Эти цели закрепляются в договоре и подтверждаются измерениями на каждых учениях: это не произвольные числа, а бизнес-решения.
Да, наша архитектура полностью соответствует GDPR, KVKK, ISO 27001 Annex A.12.3, SOC 2 CC9 и PCI-DSS 9.5/12.10. Это означает, что все резервные копии шифруются при хранении (AES-256) и при передаче (TLS 1.3); ключи хранятся в KMS (AWS KMS, Azure Key Vault, HSM) с авторизацией отдельно от системы резервного копирования; сроки хранения соответствуют требованиям закона, а по их истечении данные удаляются с подтверждением; для запросов на «право на забвение» предусмотрена процедура поиска в резервных копиях и выборочной анонимизации; место хранения данных (Турция/ЕС) можно выбрать; все обращения, восстановления и изменения конфигурации записываются в неизменяемый журнал аудита. В пакет подготовки к аудиту входят схемы архитектуры, документы с политиками, матрица RACI и последние отчёты об учениях, так что на любой вопрос аудитора уже есть готовый ответ.
Да, мы можем принять вашу текущую инсталляцию Veeam (или Rubrik, Cohesity, Commvault, Acronis) как есть: лицензия не меняется, оборудование остаётся прежним. В первую неделю мы проводим полный аудит: текущая доля успешных копий, дата последнего восстановления, политики хранения, состояние неизменяемости, модель доступа, управление ключами, мониторинг и оповещения. Всё документируем, а риски отмечаем красным, жёлтым и зелёным. В следующие 30 дней пересматриваем архитектуру и при необходимости добавляем новые уровни в режиме моста (старое и новое работают параллельно): данные не переносятся, добавляются новые цели резервного копирования. В конце третьего месяца проводим полные учения по восстановлению и фиксируем базовый уровень. У нас есть инженеры с сертификатами Veeam VMCE и Rubrik RCSA; менять поставщика не нужно: мы привносим правильную конфигурацию и операционную дисциплину.
На бесплатной 30-минутной консультации мы вместе оценим текущее состояние ваших резервных копий: цели RPO/RTO, пробелы в неизменяемости, дату последнего тестового восстановления и конкретные шаги на ближайшие 90 дней — всё это вы получите в виде письменного отчёта.
