Огромные архивы клиента: ratarmount экономит 3 часа администратору

К нам обратилась торговая компания на 28 рабочих мест из ЦАО — у юриста потерялся подписанный договор за прошлый сентябрь, нужно срочно вытащить из бэкапа 1С. Бэкап — 410 GB tar.gz на нашем удалённом FTP-сервере. Раньше такая задача занимала 2,5-3 часа: качать 410 гиг по интернет-каналу, ждать 50 минут распаковки, искать файл в дереве. С ratarmount я закрыл задачу за 12 минут. Этот материал — кейс плюс полный гайд для администраторов, у которых регулярно бывают такие задачи.

С чего всё началось: пятница, 17:30, юрист в панике

Финдир торговой компании написал мне в Telegram в пятницу вечером: «Срочно нужен договор с поставщиком химии от 24 сентября 2025, у юриста на компе пропал, в 1С нет вложения. Можно из бэкапа достать?». Договор — это PDF на 142 KB. Бэкап файлового сервера за 24 сентября 2025 — это 410-гигабайтный TAR в gzip-сжатии, лежит на нашем Veeam ESXi (адрес 37.228.92.55, FTP-учётка клиентская).

Раньше у меня было два пути:

• Скачать архив целиком на стенд и распаковать. По домашнему интернет-каналу 100 Мбит — это 410×8/100 = 32,8 минуты на скачивание, плюс gzip распаковывается со скоростью около 100 МБ/с на CPU = ещё 70 минут, итого минут 100-120 чистого времени плюс место на диске под архив и его распаковку (820 GB).
• Скачать архив на серверу клиента и там распаковать. Быстрее по сети, но всё равно 50+ минут распаковки, плюс на боевом сервере держать 820 GB временных файлов — некрасиво.

Я выбрал третий путь — ratarmount, и закрыл задачу за 12 минут. Привожу полный лог действий.

Что такое ratarmount по простому

ratarmount — это python-утилита, которая делает с TAR-архивом то же, что Linux делает с любой файловой системой: монтирует его как директорию. Через FUSE (Filesystem in Userspace). Когда вы заходите в эту директорию, ratarmount по запросу читает только нужные блоки архива, без распаковки целиком.

Аналогия для не-админов

Представьте полный шкаф с 5000 папок документов. Чтобы найти один договор, можно вытащить все папки на стол (распаковка) — займёт два часа. А можно завести каталожную карточку (SQLite-индекс) и ходить за каждой папкой адресно: «папка номер 4738, нижняя полка, левая половина». Каталожная карточка нужна один раз; дальше доступ к любой папке — 10 секунд. Вот ratarmount — это каталожная карточка для архивов.

Что внутри технически

Когда вы первый раз монтируете 410-гигабайтный архив, ratarmount проходит его последовательно (это занимает 60-120 секунд для 400 GB tar.gz при чтении с быстрого FTP) и записывает в SQLite-файл рядом с архивом метаданные: каждый файл, его offset в архиве, размер, права, mtime. Этот SQLite-индекс называется archive.tar.gz.metadata.sqlite3. Дальше при любых обращениях ratarmount читает SQLite, ищет нужный файл, делает seek на нужный байт архива и читает оттуда блоком.

Как я сделал кейс: пошаговый лог

Шаг 1. Подготовка

На моём ноутбуке Ubuntu 24.04, я заранее установил ratarmount однажды и забыл:

# Установка через pipx (изолированный virtualenv)
sudo apt install pipx fuse3
pipx install ratarmount

# Альтернативно через pip напрямую
pip install --user ratarmount

# Проверка версии
ratarmount --version
# 0.15.x на май 2026

Ratarmount требует Python 3.8+ и FUSE. На современных Ubuntu/Debian/RHEL это есть из коробки.

Шаг 2. Монтирую с удалённого FTP напрямую

Я не качаю архив локально. Использую встроенную поддержку SFTP в ratarmount через rclone. Сначала настраиваю rclone-конфигурацию:

# Настройка rclone для нашего Veeam FTP
rclone config
# выбираю sftp, имя itfreshftp,
# хост 37.228.92.55, юзер trade-corp-backup,
# пароль из ~/.itfresh/secrets

# Проверка, что виден архив
rclone ls itfreshftp:/backup/2025-09/
# 440123456789 db_backup_2025-09-24.tar.gz

Дальше монтирую:

mkdir -p /tmp/restore-2025-09
ratarmount \
  --recursive \
  --index-file ~/.cache/ratarmount/db_backup_2025-09-24.idx \
  rclone://itfreshftp/backup/2025-09/db_backup_2025-09-24.tar.gz \
  /tmp/restore-2025-09

Первое монтирование заняло у меня 92 секунды — ratarmount протянул архив через FTP-канал, чтобы построить индекс. Индекс получился весом 14 МБ, локально на ноутбуке.

Шаг 3. Нахожу файл

Дальше ищу договор стандартными средствами:

# Через ripgrep по дереву (точное название документа известно)
fd -t f "Договор.*Химпром.*sept" /tmp/restore-2025-09/ 2>/dev/null

# Через fzf если название не помню точно
fd -t f "Договор" /tmp/restore-2025-09/ | fzf

# Через find если по дате модификации
find /tmp/restore-2025-09/var/data/contracts/2025-09/ \
  -newer /tmp/restore-2025-09/var/data/contracts/2025-09/marker_22 \
  ! -newer /tmp/restore-2025-09/var/data/contracts/2025-09/marker_25

Нашёл за 8 секунд — путь /tmp/restore-2025-09/var/data/contracts/2025-09/Dogovor-Himprom-2025-09-24.pdf.

Шаг 4. Копирую файл наружу

mkdir -p ~/restored-files
cp /tmp/restore-2025-09/var/data/contracts/2025-09/Dogovor-Himprom-2025-09-24.pdf \
   ~/restored-files/

ls -la ~/restored-files/
# -rw-r--r-- 1 sem sem 142340 Sep 24  2025 Dogovor-Himprom-2025-09-24.pdf
sha256sum ~/restored-files/Dogovor-Himprom-2025-09-24.pdf

Скачались только 142 KB — те самые байты файла из архива на FTP. Ни 410 GB, ни 100 MB лишних блоков. Это магия seek+read внутри tar+gzip — ratarmount умеет позиционироваться внутри сжатого потока.

Шаг 5. Размонтирую и убираю за собой

fusermount -u /tmp/restore-2025-09
rm -rf /tmp/restore-2025-09

# Индекс оставляю в кеше — пригодится в следующий раз
ls -la ~/.cache/ratarmount/
# -rw-r--r-- 1 sem sem 14782464 May  3 18:42 db_backup_2025-09-24.idx

Итог: 12 минут от начала до отправки PDF финдиру. Из них 92 секунды на индексирование, 8 секунд на поиск, остальное — переписка в Telegram и загрузка в защищённый канал.

Кейс №2: восстановление почтового сервера юрфирмы

Похожая история была у юрфирмы 35 РМ месяц назад. Их секретарь случайно удалила в Outlook 230 писем за 2 апреля. Мы держим бэкап IMAP-стора на postfix/dovecot в виде ежедневных tar-архивов. Размер бэкапа — 87 GB (там полугодовая переписка 35 человек). Восстановление через ratarmount:

# На сервере клиента
mkdir -p /mnt/mail-restore-20260402

ratarmount \
  --recursive \
  /backup/mail/2026-04-02/dovecot-mailstore.tar.zst \
  /mnt/mail-restore-20260402

# Только письма секретаря Ивановой за 2 апреля
fd -t f -e msg . \
  /mnt/mail-restore-20260402/ivanova/Inbox/cur/ \
  --changed-after 2026-04-02 \
  --changed-before 2026-04-03 \
  | wc -l
# 230

# Копирую обратно в почтовый стор (после остановки dovecot)
systemctl stop dovecot
rsync -av \
  /mnt/mail-restore-20260402/ivanova/Inbox/cur/ \
  /var/mail/dovecot/ivanova/Inbox/cur/

# Возвращаю права
chown -R dovecot:dovecot /var/mail/dovecot/ivanova
systemctl start dovecot

# Размонтирую
fusermount -u /mnt/mail-restore-20260402

Время восстановления: 8 минут. Через распаковку всего архива было бы 25-30 минут плюс 174 GB временного места на диске сервера (87 GB архив + 87 GB распакованного).

Поддерживаемые форматы и backend'ы

Архивы

ratarmount работает с TAR (включая gzip, bzip2, xz, zstd), ZIP, RAR (через unrar), 7z, SquashFS. На моём опыте лучше всего работает с .tar.gz и .tar.zst — у них есть стриминговый seek. С плоским .tar тоже хорошо. С .zip большие архивы индексируются медленнее, но потом доступ быстрый.

Удалённые источники

Через rclone: SFTP, FTP, HTTP/WebDAV, S3 (любой), Dropbox, Google Drive, Yandex Disk. У нас в ITfresh ratarmount работает с S3-совместимым хранилищем нашего поставщика и с собственным FTP на 37.228.92.55.

# Пример — монтирование архива с Yandex Disk через rclone
rclone config  # sets up yandex remote
ratarmount rclone://yandex:archives/big.tar.gz /mnt/yd
ls /mnt/yd
# Только запрашиваемые блоки скачиваются с Я.Диска

Union mount: несколько архивов как один

Полезно, когда у клиента бэкапы инкрементальные — каждый день отдельный архив, и нужно «как было на 15-е число». Ratarmount умеет накладывать архивы один на другой как union mount:

ratarmount \
  /backup/full-2026-04-01.tar.gz \
  /backup/incr-2026-04-02.tar.gz \
  /backup/incr-2026-04-03.tar.gz \
  ...
  /backup/incr-2026-04-15.tar.gz \
  /mnt/state-2026-04-15

В точке монтирования будет состояние файловой системы на 15 апреля, восстановленное из инкрементов. У нас на одном клиенте бэкапы 1С идут в таком формате — full раз в неделю, incr ежедневно.

Что мы у себя автоматизировали

Чтобы не думать каждый раз про опции и пути, у меня в ансибле есть скрипт itfresh-restore для каждого клиента:

#!/usr/bin/env bash
# /usr/local/bin/itfresh-restore
# Использование: itfresh-restore <client> <date> [glob_pattern]

set -euo pipefail

CLIENT="${1:?client name}"
DATE="${2:?YYYY-MM-DD}"
PATTERN="${3:-*}"

ARCHIVE_PATH="/backup/${CLIENT}/${DATE}/db.tar.zst"
MOUNT_POINT="/mnt/restore-${CLIENT}-${DATE}"
INDEX_FILE="/var/cache/ratarmount/${CLIENT}-${DATE}.idx"

echo "[*] Mounting ${ARCHIVE_PATH} ..."
mkdir -p "${MOUNT_POINT}"
ratarmount \
  --recursive \
  --index-file "${INDEX_FILE}" \
  "rclone://itfreshftp${ARCHIVE_PATH}" \
  "${MOUNT_POINT}"

echo "[*] Searching for ${PATTERN} ..."
fd -t f -p "${PATTERN}" "${MOUNT_POINT}" | head -50

echo "[*] Mount point ready: ${MOUNT_POINT}"
echo "[*] After done, run: fusermount -u ${MOUNT_POINT}"

Любой инженер дежурной смены теперь делает itfresh-restore trade-corp 2025-09-24 'Dogovor-Himprom*' и через 90 секунд получает готовый mount-point с файлом.

Контр-нарратив: «зачем извращаться, есть же tar -xf»

На профильных форумах часто видишь совет «не выпендривайтесь, распакуйте архив и работайте». Это работает на маленьких бэкапах. На корпоративных больших архивах это убивает время и место.

Один мой коллега из соседней компании всегда распаковывает любой бэкап целиком. Но у него же терабайтное хранилище на сервере мониторинга и 10G-канал внутри. У клиентов МСБ ни того, ни другого. Сервер бэкапов на Veeam ESXi у нас на 14 TB, но у клиентов на их собственных серверах места обычно только под их же продакшен. Вытаскивать 410 GB на боевой сервер — это риск нечайно положить продакшен.

Ещё аргумент против ratarmount у консерваторов: «вот напоретесь, что архив сломан, и никто не узнает». В моей практике за полтора года активного использования ни разу не было такого. ratarmount валидирует TAR на лету, и если файл повреждён — скажет об этом сразу. Это даже надёжнее, чем tar -xf, который иногда продолжает распаковывать поверх ошибок.

Подводные камни, на которые мы наступили

Проблема 1. Индекс пропал — повторное долгое индексирование

В первый месяц использования я не сохранял .metadata-индексы рядом с архивами, и при каждом новом монтировании ratarmount строил их заново. На 410 GB это 90 секунд. Решение: в ансибл-задаче бэкапа добавил cp .metadata.sqlite3 ${ARCHIVE_PATH}.metadata.sqlite3 сразу после создания индекса. Теперь при повторном монтировании это считанные секунды.

Проблема 2. SquashFS внутри TAR — рекурсия

У одного клиента бэкапы 1С — это TAR-архив, внутри которого SquashFS-образ 1С-сервера. Без флага --recursive ratarmount показывает SquashFS как один большой файл. С --recursive монтирует и его внутрь — получается архив-в-архиве, прозрачно. Запомните этот флаг, мы про него забывали раз пять.

Проблема 3. Большие ZIP с RAR-сжатием

В одном бэкапе мы получили ZIP, внутри которого был RAR (странный формат от старой версии WinRAR). Ratarmount его прочитал, но индексирование заняло 14 минут вместо ожидаемых 2. Так что для производительности храните бэкапы в .tar.zst или .tar.gz — это самые предсказуемые форматы.

Проблема 4. Права после копирования

Когда восстанавливаешь файлы из архива, через ratarmount они приходят с правами и владельцем как в TAR. Если копируете обратно в продакшен, нужно явно проставлять chown/chmod после rsync. Один раз я этого не сделал, и dovecot месяц жаловался на «permission denied» в логах из-за чужого uid у восстановленных писем.

Где мы экономим деньги клиента благодаря ratarmount

Привожу честный замер по клиентам за прошедший год:

Кейс                                            Без ratarmount   С ratarmount
1 PDF из бэкапа 1С (торговая комп.)             3 ч              12 мин
230 писем (юрфирма)                             45 мин           8 мин
конфиг nginx из бэкапа сервера (юрфирма)        20 мин           3 мин
3 файла Excel из бэкапа файлсервера (произв.)   1,5 ч            6 мин
полная копия БД для разраб. стенда              отдельная задача (использовали tar -xf, ratarmount тут не нужен)

В среднем за месяц у нас 4-6 запросов «достань файл из бэкапа» от клиентов. Без ratarmount это 12-20 часов работы инженеров суммарно. С ratarmount — 1-2 часа. Это 16-19 часов в месяц чистой экономии — примерно 60-70 тысяч рублей по нашему тарифу.

FAQ: что чаще всего спрашивают клиенты

Что такое ratarmount и зачем он на сервере клиента?

ratarmount — это утилита, которая монтирует TAR-архив как обычную директорию через FUSE, без распаковки. На большом архиве (например, 410-гигабайтный бэкап 1С торговой компании) распаковка занимает 3 часа и требует двойного объёма свободного места на диске. ratarmount строит SQLite-индекс архива за 90 секунд и дальше дает прозрачный доступ к любому файлу внутри. На сервере клиента это значит, что админ за 2 минуты вытаскивает один потерянный документ из недельного бэкапа, не разворачивая весь архив.

Чем ratarmount лучше архитектурно, чем archivemount?

archivemount при каждом обращении к файлу проходит архив с начала, потому что не строит индекс. На архиве 1 GB это терпимо, на 100+ GB он умирает. ratarmount строит SQLite-индекс на первом обращении (один раз за всё время существования архива, индекс кешируется в .metadata) и дальше доступ — это lookup в индексе плюс seek+read в архиве. Поэтому ratarmount работает на терабайтных архивах за секунды, а archivemount — нет. Это та же разница, что между Excel и SQL: одно для 100 строк, другое для миллиона.

Можно ли использовать ratarmount для бэкапов на удалённом FTP?

Да, и это для нас главная фишка. ratarmount умеет читать архивы с FTP, SFTP, HTTP, S3, Dropbox и Google Drive через rclone. У клиентов мы храним сжатые tar-архивы 1С на удалённом FTP-сервере (наш Veeam ESXi на 37.228.92.55). Сисадмин клиента монтирует с FTP напрямую: ratarmount sftp://itfreshftp/backup/2026-04/db.tar.gz /mnt/restore — и работает с архивом, как с локальной директорией. Скачивается только то, к чему обращаются.

Какие подводные камни мы знаем у ratarmount?

Три. Первый — архив должен быть в режиме read-only, никаких правок. Второй — для очень больших ZIP (старого формата) индексирование медленнее, чем для TAR. Третий — после первичного индексирования нужно сохранить .metadata-файл рядом с архивом, иначе при повторном монтировании ratarmount будет индексировать заново. Мы у себя автоматически складываем .metadata-файлы рядом с tar.gz и в бэкап-задании отдельно их копируем — это +1 минута экономии на каждом восстановлении.

Когда я как сисадмин клиента не должен использовать ratarmount?

Когда задача — полное восстановление сервера 1С на новое железо после катастрофы. Здесь нет смысла монтировать архив через FUSE, нужно разворачивать tar -xf на новый диск как привычно. ratarmount даёт выигрыш в сценариях, где из большого архива нужны 1-50 файлов, не весь архив целиком. Например, юрист попросил «достань мне договор с контрагентом X из бэкапа за прошлый сентябрь» — здесь ratarmount экономит часы. Также не использую на ZIP с шифрованием от SecureZip, у ratarmount по моему опыту с такими бывают проблемы.

Итог

ratarmount — нишевая, но критически полезная утилита для аутсорсера, у которого клиенты постоянно теряют файлы и просят достать из бэкапа. На 410 GB архив один файл вытаскивается за 12 минут вместо 3 часов. Связка с rclone позволяет работать прямо с FTP-сервера без скачивания. Мы у себя в ITfresh за год сэкономили клиентам 200+ часов инженерной работы и заметно подняли скорость отклика на запросы «срочно нужен документ».