Резервные копии персональных данных: как хранить бэкапы по 152-ФЗ

Резервная копия — это те же персональные данные, только продублированные. Закон 152-ФЗ не делает исключений для бэкапов: они должны храниться на территории России, быть защищены не хуже основной базы и удаляться по тем же правилам, что и оригинал. Забыть об этом — частая ошибка бизнеса, которая всплывает при проверках или запросах на удаление данных.

Разве бэкап — это не просто техническая копия, а не «настоящие» персональные данные?

С точки зрения закона разницы нет. Если в резервной копии есть имена, телефоны, адреса или другая информация, по которой можно идентифицировать человека, — это персональные данные, и на них распространяются все требования 152-ФЗ. Неважно, лежит копия на основном сервере, в архиве или на внешнем накопителе в сейфе бухгалтерии.

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

Можно ли хранить бэкап с персональными данными за границей, если основной сервер в России?

Нет, если речь о первичном сборе и хранении данных граждан РФ — требование локализации (закон, дополнивший 152-ФЗ и вступивший в силу с 1 сентября 2015 года) распространяется и на резервные копии. Это широко известный факт: именно с этой даты компании обязаны хранить и обрабатывать персональные данные россиян на серверах, физически расположенных в России, даже если параллельно ведётся обработка за рубежом.

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

Нужно ли шифровать резервные копии, если сервер и так защищён?

Да, и это отдельный уровень защиты. Даже если основной сервер надёжно изолирован, бэкап часто копируется на другой носитель, передаётся по сети или хранится в отдельном хранилище — а значит, у него своя зона риска. Шифрование резервной копии защищает данные, даже если носитель физически украден или попадёт не в те руки.

• Шифровать стоит как сам файл бэкапа, так и канал передачи данных при копировании.
• Ключи шифрования нужно хранить отдельно от самих копий — иначе смысл защиты теряется.
• Доступ к расшифровке должен быть у ограниченного круга сотрудников, а не у всей IT-команды.

Сколько времени можно держать старые резервные копии?

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

Разумный подход — прописать во внутренних документах чёткий цикл жизни бэкапов: например, ежедневные копии хранятся неделю, еженедельные — месяц, а после истечения срока автоматически заменяются новыми или удаляются. Это должно быть зафиксировано в политике обработки персональных данных компании.

Что делать с бэкапами, если человек попросил удалить свои данные?

Это один из самых сложных практических вопросов. Удалить запись из основной базы легко, но она может остаться в десятке резервных копий, сделанных за последние месяцы. Полностью «вычистить» человека из всех архивов задним числом технически сложно и не всегда нужно — регуляторная практика исходит из того, что удаление из бэкапов допустимо провести в разумный срок, по мере естественной ротации копий.

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

Кто отвечает за бэкапы — компания или хостинг-провайдер?

Ответственность за соблюдение 152-ФЗ всегда лежит на операторе персональных данных, то есть на самой компании, которая эти данные собирает. Хостинг-провайдер выступает обработчиком и обязан обеспечить техническую защиту по договору, но юридически именно бизнес отвечает перед Роскомнадзором и субъектами данных за то, где и как хранятся резервные копии.

Поэтому в договоре с провайдером важно прямо прописать порядок резервного копирования: где физически хранятся копии, кто имеет к ним доступ, как долго они живут и как уничтожаются. Устные договорённости или размытые формулировки в тарифе — это риск, который в итоге ложится на компанию, а не на хостинг.

Как правильно уничтожать резервные копии, срок которых истёк?

Просто удалить файл — недостаточно, если речь о серьёзных объёмах персональных данных: при обычном удалении информация часто остаётся на носителе и теоретически может быть восстановлена. Для надёжного уничтожения используют программные средства безвозвратного стирания данных или физическое уничтожение носителей, если копия хранилась на отдельном диске.

Факт уничтожения желательно фиксировать документально — актом или журналом, особенно если компания подпадает под повышенные требования к защите (например, работает с большими объёмами данных или чувствительными категориями). Это пригодится, если придёт проверка и потребуется подтвердить, что старые бэкапы действительно удалены, а не просто забыты на архивном сервере.

Как упростить соблюдение всех этих требований на практике?

Вручную контролировать шифрование, сроки хранения, локализацию и уничтожение десятков резервных копий сложно, особенно небольшой команде. Платформа «Клауд АйСи» помогает решить эту задачу комплексно: серверы и хранилища для резервного копирования размещаются в российских дата-центрах, что закрывает вопрос локализации, а настройки шифрования и политики ротации бэкапов можно задать один раз и не возвращаться к ним при каждой проверке. Это снимает с бизнеса часть технической и юридической нагрузки, оставляя контроль над данными, но без ручного управления каждой копией.