Нотариус хранит сканы и реестры: архив, который не уедет за границу

MAATRIX

У нотариуса архив — это не резервная копия на всякий случай, а рабочий инструмент и одновременно предмет ответственности: сканы удостоверяемых документов, реестр нотариальных действий, переписка с заявителями, иногда — записи видеофиксации. Когда весь этот массив лежит в чьём-то публичном облаке, вы, как правило, точно не знаете, в каком дата-центре и в какой стране физически находится диск с вашими файлами сегодня — и где он окажется завтра после очередной миграции провайдера. Для нотариальной практики это неприятная неопределённость. Ниже — как выстроить архив на сервере в конкретной, выбранной вами локации, с понятной структурой хранения, резервным копированием и контролем доступа.

Публичное облако: где именно ваши сканы, вы не узнаете

Разберём это чуть подробнее, потому что тезис "с облаком не всё равно" звучит абстрактно, пока не увидишь механику.

Публичные облачные хранилища (объектные хранилища крупных провайдеров, SaaS-сервисы документооборота, "бесплатный" диск, который где-то подключили для удобства) обычно:

• реплицируют данные между несколькими дата-центрами автоматически, без вашего участия в выборе;
• используют субподрядчиков и партнёрскую инфраструктуру, которая может меняться без уведомления клиента;
• по договору оставляют за собой право переносить данные между регионами — это стандартная строчка в пользовательском соглашении, которую мало кто читает;
• физически размещают "региональный" дата-центр не обязательно там, где вы думаете — географическое название региона в консоли провайдера не всегда буквально совпадает с адресом стойки.

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

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

Альтернатива — сервер в известной вам локации

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

Разница принципиальная:

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

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

Как устроить архив: структура хранения сканов и реестров

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

Рабочая схема каталогов, проверенная на практике для документо-ориентированных архивов:

/srv/archive/
├── registry/                  # реестр нотариальных действий
│   ├── 2026/
│   │   ├── 2026-08.csv        # выгрузка реестра за месяц
│   │   └── 2026-08-index.json # индекс для быстрого поиска
├── cases/                      # сканы по делам/действиям
│   ├── 2026/
│   │   ├── 2026-08-14_ivanov_dover/
│   │   │   ├── original.pdf
│   │   │   ├── scan_001.tiff
│   │   │   ├── scan_002.tiff
│   │   │   └── metadata.json
│   │   └── ...
├── correspondence/             # переписка с заявителями
└── README.md                   # описание структуры для преемника/помощника

Несколько практических принципов, которые упрощают жизнь через годы:

• Дата в имени папки — ГГГГ-ММ-ДД_фамилия_тип-действия. Сортировка по имени сразу даёт хронологию, без отдельной СУБД.
• metadata.json рядом с каждым делом — минимум полей: дата, тип нотариального действия, номер в реестре, кто из сотрудников оформлял. Это не замена официальному реестру, а быстрый локальный индекс для поиска.
• Сканы — в исходном разрешении, дополнительно можно хранить сжатую PDF-версию для быстрого просмотра, чтобы не перекачивать TIFF на 40 МБ ради проверки одной страницы.
• Готовые дела — в режим "только чтение". После завершения оформления можно снять права записи на уровне файловой системы:

# после завершения дела — защита от случайного изменения
chmod -R a-w /srv/archive/cases/2026/2026-08-14_ivanov_dover/
chattr +i /srv/archive/cases/2026/2026-08-14_ivanov_dover/*.pdf

Флаг +i (immutable) в ext4/xfs не даёт менять или удалять файл даже пользователю root без явного снятия атрибута — простой, но действенный барьер против случайной правки или удаления завершённого дела.

Для дисковой подсистемы разумный минимум — зеркало (RAID1 или программный mdadm-массив) на самом сервере, чтобы отказ одного диска не означал потерю архива в моменте, до восстановления из резервной копии. Это отдельный уровень защиты, не заменяющий бэкапы, а дополняющий их.

Резервные копии и шифрование: копия — тоже данные, не только оригинал

Архив на одном сервере без резервных копий — это не архив, а точка единого отказа. Правило простое: если документ существует только в одном месте, его не существует.

Для регулярного резервного копирования удобен BorgBackup — он умеет дедупликацию (повторяющиеся сканы не занимают место дважды) и шифрование на лету. Базовая настройка:

# инициализация зашифрованного репозитория для бэкапов
borg init --encryption=repokey-blake2 /mnt/backup/archive-repo

# ежедневный бэкап архива с меткой даты
borg create --stats --progress \
  /mnt/backup/archive-repo::archive-{now:%Y-%m-%d} \
  /srv/archive/

# хранить дневные копии за неделю, недельные за месяц, месячные за год
borg prune --keep-daily=7 --keep-weekly=4 --keep-monthly=12 \
  /mnt/backup/archive-repo

Эти три команды удобно оформить в единый скрипт и повесить на cron:

# /etc/cron.d/archive-backup
0 3 * * * root /usr/local/bin/backup-archive.sh >> /var/log/archive-backup.log 2>&1

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

Диск с архивом на самом сервере стоит шифровать (LUKS для Linux) — это защищает данные в случае физического изъятия или кражи носителя, а не только от сетевых атак:

# создание зашифрованного раздела под архив
cryptsetup luksFormat /dev/sdb1
cryptsetup luksOpen /dev/sdb1 archive_crypt
mkfs.ext4 /dev/mapper/archive_crypt
mount /dev/mapper/archive_crypt /srv/archive

Ключ шифрования — отдельная зона ответственности: если он утрачен, зашифрованные данные восстановить нельзя в принципе. Храните ключевую фразу или keyfile отдельно от сервера — в менеджере паролей или в сейфе, но не в текстовом файле рядом с самим архивом.

Кто и когда заходил в архив: контроль доступа и журнал

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

Доступ по SSH-ключам, без паролей. Пароли перебираются, ключи — нет. В /etc/ssh/sshd_config:

PasswordAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

Отдельная учётная запись на каждого сотрудника, у кого есть доступ к серверу — не общий логин "notary", а именные ivanova, petrov. Тогда журнал входов (last, /var/log/auth.log) реально показывает, кто заходил, а не просто факт входа.

Логирование обращений к файлам архива. Простой вариант без сложных SIEM-систем — auditd:

apt install auditd
auditctl -w /srv/archive/ -p rwxa -k archive_access
# посмотреть, кто и когда трогал архив
ausearch -k archive_access | aureport -f -i

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

Fail2ban против перебора на внешний SSH-порт или веб-интерфейс, если он есть:

apt install fail2ban
systemctl enable --now fail2ban

Стандартной конфигурации достаточно для базовой защиты от автоматического перебора паролей и подключений.

Переезд, рост, преемственность — что происходит с архивом со временем

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

Рост объёма. Сканы в высоком разрешении и видеофиксация быстро съедают место. Заложите запас — заказывайте диск с запасом минимум в два-три раза больше текущего объёма архива, чтобы не переезжать на новый сервер каждый год. Расширение диска на арендованном сервере обычно проще, чем миграция всей структуры каталогов и прав доступа на новую машину.

Смена оборудования у провайдера. Если провайдер меняет физическое оборудование или дата-центр, ваш выбор локации при заказе — это то, что фиксируется в договоре и по факту размещения, а не то, что молча "плывёт" само по себе, как в публичном облаке. Уточняйте у провайдера при заказе конкретный дата-центр и регион — это тот самый пункт определённости, ради которого всё затевалось.

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

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

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

Частые вопросы