Дата актуализации:

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

Зачем нужен архив сайта?

Понимание целей архивации определяет выбор инструментов. Основные сценарии:

• Юридическое значение: Фиксация условий оферт, политик конфиденциальности, цен и контента на конкретную дату для судебных споров (например, защита интеллектуальной собственности или споры с контрагентами).
• SEO и аналитика: Восстановление удаленных страниц, анализ истории изменений структуры сайта, поиск битых ссылок и восстановление потерянного трафика.
• Аварийное восстановление (Disaster Recovery): Быстрый откат к рабочей версии после взлома, ошибки разработчика или сбоя CMS.
• Историческая память: Сохранение культурного наследия, старых версий дизайна, контента для музеев, библиотек или корпоративных хроник.
• Тестирование и разработка: Сравнение версий кода и контента (A/B тесты, регрессионное тестирование).

Стратегия 1: Публичные веб-архивы (Внешнее архивирование)

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

Wayback Machine (Internet Archive)

Крупнейший в мире архив (web.archive.org).

Ручное сохранение (Save Page Now)

1. Перейдите на web.archive.org/save.
2. Введите URL страницы;
3. Нажмите SAVE PAGE.

Автоматизация через API

Для регулярного архивирования списка URL используйте API Internet Archive.

# Пример curl запроса для сохранения
curl -X POST "https://web.archive.org/save/https://example.com/page" 
 -H "Authorization: LOW :"

Примечание: Ключи API (Access Key / Secret Key) выдаются после регистрации на сайте Archive.org. В примере выше они замаскированы как *.

Особенности и ограничения:

• Не архивирует контент за авторизацией (личные кабинеты, админки).
• Ограничение по размеру файла и глубине сканирования.
• Robots.txt: Если ваш robots.txt запрещает сканирование ia_archiver, Wayback Machine не сохранит страницу. Для принудительного сохранения через «Save Page Now» это ограничение часто игнорируется, но для краулера — нет.

Archive.today (archive.ph / archive.is)

Альтернатива, лучше работающая с JavaScript и сложными верстками. Сохраняет «как видит пользователь» (рендеренный DOM).

• API неофициальное, но есть простые GET-запросы: https://archive.ph/submit/?url=URL.
• Не подчиняется robots.txt.
• Хорош для сохранения новостных статей, постов в соцсетях, динамических страниц.

Специализированные сервисы (Perma.cc, WebCite)

Ориентированы на академические и юридические цитирования. Дают гарантию сохранения (Perma.cc — библиотека Гарвардского права). Требуют регистрации организации.

Стратегия 2: Локальное и корпоративное архивирование (Внутреннее)

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

Wget / WARC — стандарт де-факто

Формат WARC (Web ARChive) — это ISO стандарт (ISO 28500) для хранения веб-ресурсов. Включает HTTP-заголовки, ответы сервера, метаданные.

Пример команды для полного зеркала:

wget --mirror 
 --convert-links 
 --adjust-extension 
 --page-requisites 
 --no-parent 
 --warc-file="backup_$(date +%F)" 
 --warc-cdx 
 --user-agent="CorporateArchiver/1.0 (contact: @.ru)" 
 --wait=1 
 --random-wait 
 "https://internal-site;*"

Разбор параметров:

• --warc-file — имя файла архива (без расширения, добавится .warc.gz).
• --warc-cdx, создает индексный файл CDX для быстрого поиска по архиву.
• --user-agent — обязательно указывайте контактные данные (замаскированы как *), чтобы админы сайта могли связаться при нагрузке.
• --wait / --random-wait — вежливая задержка, чтобы не положить сервер.

Webrecorder / Browsertrix (Архивирование «как в браузере»)

Современные инструменты на базе headless Chrome (Puppeteer/Playwright). Идеальны для SPA, сайтов с тяжелым JS, авторизацией, бесконечным скроллингом.

Архитектура Browsertrix (Docker):

# docker-compose.yml (упрощенно)
services:
 browsertrix-crawler:
 image: webrecorder/browsertrix-crawler:latest
 volumes:
 ‒ ./collections:/collections
 environment:
 ⎻ URL=https://target-site.*
 ‒ COLLECTION=monthly_snapshot
 ‒ WORKERS=2

Результат — коллекция WARC-файлов, которую можно просматривать через ReplayWeb.page (локально или в браузере).

ArchiveBox — Самостоятельный «Wayback Machine»

Open-source решение (Python/Node) с веб-интерфейсом. Поддерживает множество источников: закладки браузера, Pocket, Pinboard, RSS, списки URL, историю Chrome.

Быстрый старт (Docker):

docker run -d 
 -v $PWD/data:/data 
 -e USE_COLOR=1 
 -e MEDIA_TIMEOUT=3600 
 -p 8000:8000 
 archivebox/archivebox

После запуска доступен по http://localhost:8000. Добавляйте URL через UI или CLI: archivebox add "https://example.com".

Фичи: Скриншоты, PDF, DOM dump, WARC, Git-хранилище, полнотекстовый поиск.

SingleFile / Monolith — для отдельных страниц

• SingleFile (расширение браузера / CLI Node.js) — лучшее качество рендера.
• Monolith (Rust CLI) — быстрый, статический бинарник.

# Monolith пример

Стратегия 3: Архивирование баз данных и CMS (Backend)

Фронтенд-архив не спасет, если утеряна БД. Нужен отдельный слой бэкапа.

Логические бэкапы (SQL Dumps)

# MySQL / MariaDB
mysqldump -u * -p* --single-transaction --routines --triggers --all-databases | gzip > "db_backup_$(date +%F_%H-%M).sql.gz"

pg_dumpall -U * | gzip > "pg_backup_$(date +%F).sql.gz"

Точечное восстановление (PITR)

Для продакшн-БД используйте WAL-G (PostgreSQL), Percona XtraBackup (MySQL) или нативные инструменты (pg_basebackup). Позволяют откатиться на любую секунду.

Версионирование контента внутри CMS

• WordPress: Плагины WP Revisions Control, Simple History, бэкап через UpdraftPlus / WPvivid в S3/Google Drive.
• Bitrix / Drupal / Joomla: Встроенные модули версионирования + экспорт контента в XML/JSON.
• Headless CMS (Strapi, Contentful, Sanity): Используйте вебхуки на изменение контента для отправки снепшотов в объектное хранилище (S3, MinIO).

Инфраструктура хранения: Куда класть архивы?

Правило 3-2-1: 3 копии, на 2 разных носителях, 1 копия off-site (в другом ДЦ/облаке).

Автоматизация и CI/CD пайплайн

Архивация должна быть не разовым действием, а процессом. Интегрируйте в GitLab CI / GitHub Actions / Jenkins.

Пример .gitlab-ci.yml (Job архивации продакшена раз в сутки):

stages:
 ⎻ archive

archive_prod:
 stage: archive
 image: webrecorder/browsertrix-crawler:latest
 only:
 ⎻ schedules # Запуск только по расписанию (cron)
 variables:
 URL: "https://prod..ru"
 COLLECTION: "prod_daily_$(date +%Y-%m-%d)"
 script:
 ⎻ /app/crawl.sh
 # Загрузка в S3 (MinIO client)
 ⎻ mc alias set myminio https://s3..ru $ACCESS_KEY $SECRET_KEY
 ‒ mc mirror /collections myminio/archives/prod/
 tags:
 ‒ docker-runner

Переменные $ACCESS_KEY, $SECRET_KEY хранятся в CI/CD Variables (замаскированы в логах как *).

Правовые и организационные аспекты

Авторское право и Robots.txt

Архивирование чужого контента для личных нужд (исследование, доказательства в суде) в РФ обычно покрывается ст. 1274 ГК РФ (свободное использование в информационных целях) или ст. 1273 (цитирование). Но коммерческое использование архива чужого сайта — риск. Для своих сайтов — добавьте в robots.txt разрешение для архиваторов:

User-agent: ia_archiver
Allow: /

User-agent: archive.org_bot
Allow: /

Персональные данные (152-ФЗ / GDPR)

Архив — это копия БД. Если в ней есть ПДн, архив подпадает под требования закона: шифрование в покое (AES-256), контроль доступа, журналы доступа, возможность удаления по запросу субъекта (Право на забвение). Совет: Архивируйте обезличенные данные или храните ключи шифрования отдельно от архива.

Целостность и верификация

Регулярно проверяйте, что архив читается.

• Контрольные суммы (SHA-256) для каждого WARC/дамп файла. Храните манифест (manifest.txt) отдельно.
• Тестовое восстановление: раз в квартал поднимайте тестовый стенд из архива.
• Индексация: используйте cdx-toolkit или Elasticsearch/OpenSearch над CDX-индексами для поиска по архиву.

Чек-лист: Готовность архива к инциденту

1. [ ] Настроено ежедневное/почасовое создание WARC-снимков критичных разделов (через Browsertrix/ArchiveBox).
2. [ ] Настроен бэкап БД с PITR (Point-in-Time Recovery).
3. [ ] Архивы реплицируются в S3 (холодное хранилище) с политикой.lifecycle (хранение 7 лет / бессрочно).
4. [ ] Включено версионирование бакета S3 (защита от случайного удаления/шифровальщиков).
5. [ ] Проведено тестовое восстановление сайта из архива за последний квартал (RTO/RPO зафиксированы).
6. [ ] Доступ к архивам разграничен по ролям (RBAC): Security, Legal, DevOps, Auditors.
7. [ ] Ведутся логи доступа к архивам (SIEM интеграция).
8. [ ] Документирована процедура предоставления архива в суд/роскомнадзор/налоговую (цепочка сохранности).

Настройка архива для сайта — это не про «бэкап файлов», а про построение системы доказательств и восстановления. Комбинируйте подходы: публичные архивы (Wayback/Archive.today) для публичных страниц и SEO, собственные WARC-краулеры (Browsertrix/ArchiveBox) для сложного фронтенда и интранетов, и надежные бэкапы БД/кода в S3 с WORM-защитой для ядра бизнеса.

Начните с малого: настройте ежедневный краул главной страницы и ключевых лендингов в ArchiveBox на отдельном сервере, настройте выгрузку в S3. Постепенно охватите весь периметр. Помните: архив, из которого нельзя восстановить данные за 15 минут, это не архив, а мусорка.

Статья подготовлена на основе актуальных практик DevOps, Digital Preservation и требований российского законодательства на 2026 год. Контакты администраторов и ключи доступа в примерах кода заменены на * в целях безопасности.