rclone bisync: безопасная двухсторонняя синхронизация медиа

Двухсторонняя синхронизация медиа — типичная задача для проектов, где файлы могут появляться и меняться на нескольких сторонах одновременно: на веб‑сервере (или NAS), в бэкенд‑процессах и в облачном хранилище S3. Инструмент rclone bisync решает её прозрачно и быстро, но требует дисциплины: нужно понимать модель изменений, поддержку контрольных сумм, «конфликты», особенности S3 и как их обойти без потерь.

Зачем именно bisync, а не обычный sync

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

Ключевая ценность bisync — не «мгновенная синхронизация», а аккуратная фиксация изменений и безопасный разбор противоречий: кто и что изменил, что удалить, что переместить и что считать конфликтом.

Модель безопасности: что может пойти не так

Прежде чем крутить флаги, важно понимать риски:

• Конфликты изменений: один и тот же файл был изменён на обеих сторонах между циклами bisync. Нужно заранее определить политику поведения в таких случаях.
• Переименования и перемещения: если трекер не «увидел» rename, операция распознается как «удаление + создание», что может вызвать лавину ненужных перекачек и удалений.
• Задержки на S3: eventual consistency в некоторых сценариях может кратковременно скрывать свежие изменения. Нужно компенсировать это настройками и расписанием.
• Контрольные суммы: на S3 ETag не всегда равен MD5 (многосоставная загрузка), поэтому «сверка по checksum» не универсальна.
• Часы и временные метки: если время на серверах «плывёт», сравнение по modtime даст ложные срабатывания.
• Массовые удаления: одна ошибка в фильтрах — и bisync готов честно удалить «лишнее». Нужны предохранители.

Подготовка окружения

Запускать синхронизацию удобнее на отдельном хосте, где не мешают прод‑нагрузки и можно гибко настраивать планировщик. Для этого отлично подходит VDS: изолированная среда, свои ресурсы и полноценные права для системных служб.

1) Установка и базовая проверка rclone

Установите rclone из пакета вашей ОС или официального бинарника. Проверьте версию и базовую работоспособность:

rclone version
rclone help

2) Настройка удалённого хранилища (пример с S3)

Добавьте удалённый endpoint (провайдер S3, регион, ключи доступа) через интерактивный конфиг. Пользователь, от имени которого будет работать bisync, должен иметь права только на нужный бакет/префикс (принцип минимально необходимых прав).

rclone config
rclone ls s3media:media

Где s3media:media — созданный remote и префикс с медиа. Убедитесь, что список файлов открывается без ошибок. Если требуется сквозное шифрование и аккуратная работа с ключами, посмотрите разбор в статье rclone crypt: шифрование и управление ключами.

3) Хранение секретов и доступов

• Дайте файлу ~/.config/rclone/rclone.conf права только на чтение владельцу (например, 600).
• Используйте отдельного системного пользователя для синхронизации.
• Если возможно, включите версионирование объекта в бакете (это пригодится для откатов).

Первый безопасный запуск bisync

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

# Проверяем, что будет сделано, без реальных изменений
rclone bisync /srv/media s3media:media --resync --dry-run --workdir /var/lib/rclone-bisync --log-level INFO

# Инициализирующий прогон (без --dry-run) после проверки плана
rclone bisync /srv/media s3media:media --resync --workdir /var/lib/rclone-bisync --log-level INFO

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Защита от потерь: предохранители и бэкапы

Лимит удалений

Никогда не запускайте двухстороннюю синхронизацию без защиты от массового удаления. Установите лимит:

rclone bisync /srv/media s3media:media --max-delete 5% --log-level INFO

Если bisync решит удалить больше 5% файлов, операция прервётся. Подберите порог под свой объём изменений.

Стратегия «сначала сохраняем, потом синхронизируем»

Для медиа особенно разумно хранить копии изменённых/удалённых версий. Это даёт возможность отката и расследования конфликтов.

rclone bisync /srv/media s3media:media --backup-dir s3media:backup/$(date +%F) --suffix -bisync

--backup-dir перемещает «теряемые» версии туда, вместо безвозвратного удаления. --suffix добавит суффикс к конфликтным/заменяемым копиям. Благодаря этому любой конфликт или неудачное обновление можно позже разобрать и восстановить нужный файл.

Работа с конфликтами изменений

Конфликт возникает, когда один и тот же путь был изменён по обе стороны между циклами. Безопасная практика для медиа — сохранять обе версии: публиковать самую свежую по времени, а вторую класть в --backup-dir с понятным суффиксом. Так вы не потеряете данные и сможете провести ручную экспертизу.

Практические советы:

• Держите короткий интервал запусков bisync (например, каждые 5–10 минут), чтобы уменьшить окно конфликтов.
• Разруливайте конфликты вне «горячего» пути: храните обе версии и уведомляйте ответственных.
• Избегайте case‑only переименований и in‑place правок метаданных; лучше выпускать версии с новыми именами.

Особенности S3 и больших медиа

• Eventual consistency: листинг или чтение только что записанного объекта может отставать. Компенсируйте это интервалами между крупными пачками изменений и более редкими контрольными циклами с повышенным логированием.
• Контрольные суммы: ETag не всегда MD5. Для сравнения используйте size и modtime, не включайте слепо --checksum без уверенности.
• Переименования: включайте отслеживание переименований при необходимости, например --track-renames. Подбирайте стратегию под вашу среду (modtime или размер), учитывая особенности S3.
• Большие файлы: настройте multipart и параллелизм.

rclone bisync /srv/media s3media:media --transfers 8 --checkers 16 --s3-chunk-size 32M --s3-upload-concurrency 4 --fast-list

Подробнее о подборе chunk‑размеров и параллелизма читайте в материале тюнинг multipart для rclone и S3.

Метаданные времени, часовые пояса и «грязные» изменения

Сравнение по времени изменения (modtime) чувствительно к рассинхронизации часов. На всех хостах синхронизации включите NTP/chrony. Если файловая система даёт точность штампа в 1 секунду, учитывайте это допуском (например, через --modify-window, если вы используете сравнение по времени).

Типичный кейс: неизменившийся по содержимому файл получил новый modtime из‑за перекомпрессии или обновлённого EXIF. Это не ошибка, но приведёт к лишней перекачке. Если допустимо, внедрите политику версионирования имён и избегайте перезаписи in‑place.

Фильтры: исключаем мусор и кэш

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

rclone bisync /srv/media s3media:media --exclude "cache/**" --exclude "**/*.tmp"

Документируйте правила включения/исключения, чтобы команда понимала, почему что‑то не попало в S3 или, наоборот, было удалено.

Проверка целостности после синка

Периодически выполняйте верификацию после циклов bisync: это помогает поймать «ползучие» проблемы раньше пользователей.

# Сверка после синка, без изменений
rclone check /srv/media s3media:media --size-only --one-way --log-level NOTICE

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

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

# /etc/systemd/system/rclone-bisync-media.service
[Unit]
Description=Rclone bisync media
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=media
Group=media
ExecStart=/usr/bin/rclone bisync /srv/media s3media:media --max-delete 5% --backup-dir s3media:backup/$(date +%%F) --suffix -bisync --transfers 8 --checkers 16 --fast-list --workdir /var/lib/rclone-bisync --log-level INFO --log-file /var/log/rclone-bisync-media.log
Nice=10
IOSchedulingClass=best-effort
IOSchedulingPriority=7
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=true

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/rclone-bisync-media.timer
[Unit]
Description=Run rclone bisync media periodically

[Timer]  
AccuracySec=1min
Persistent=true

[Install]
WantedBy=timers.target

Запустите таймер и проверьте логи:

systemctl daemon-reload
systemctl enable --now rclone-bisync-media.timer
journalctl -u rclone-bisync-media.service -f

Хорошая практика — не запускать новый цикл, если предыдущий ещё идёт. systemd по умолчанию не стартует сервис повторно, пока предыдущий «oneshot» не завершится; при необходимости используйте systemd-локи или внешние файлы‑замки.

Если вместо синхронизации вам нужен прозрачный доступ к бакету как к файловой системе для приложений, почитайте альтернативный подход в заметке монтаж S3 как директории через rclone/rclone mount.

Типовые рецепты для медиа

1) Безопасная начальная публикация архива

Когда у вас есть «мастер» каталог с медиа и пустой префикс в S3, начните с однонаправленного copy (не sync), затем инициализируйте bisync:

rclone copy /srv/media s3media:media --transfers 8 --checkers 16 --fast-list
rclone bisync /srv/media s3media:media --resync

Так вы избежите случайного удаления на старте из‑за пустой стороны.

2) Детектор аномалий

Включите дневные отчёты по количеству изменений, скорости и удалений. Если при обычном трафике у вас 100–200 изменений в день, а сегодня система пытается удалить 10 000, таймер с --max-delete остановит операцию, а уведомление оповестит о проблеме.

3) Переименования и массовые реорганизации

Если вы планируете переезд структуры каталогов (например, смена схемы year/month для изображений), выполните его на одной стороне и дайте bisync корректно «увидеть» изменения. В период миграции — чаще запускать цикл и внимательно отслеживать лог. Это снизит объём повторных загрузок и исключит ненужные удаления.

Производительность и ресурсные лимиты

• Балансируйте параллелизм: --transfers и --checkers увеличивают скорость, но могут перегрузить IO и сеть.
• Подстраивайте чанк и конкуренцию: для S3 пропишите разумные --s3-chunk-size и --s3-upload-concurrency, чтобы не раздувать память и не упираться в лимиты.
• Ограничивайте полосу: если на хосте крутится прод, используйте --bwlimit в рабочие часы.

Откат и восстановление

• Держите последние циклы изменений в --backup-dir с разнесением по датам.
• Если бакет с включённым версионированием, восстановление делается точечно, без полных перекачек.
• Для массового отката проще всего выполнить одноразовый направленный copy из бэкап‑префикса в рабочее дерево.

Чек‑лист перед продуктивным запуском

• Синхронизируйте часы на всех участниках (NTP/chrony).
• Определите и задокументируйте политику конфликтов: сохраняем обе версии; где храним; кто и как разбирает.
• Включите --max-delete и используйте --backup-dir.
• Отфильтруйте временные файлы через --exclude.
• Сделайте первый цикл с --dry-run и внимательно изучите план.
• Настройте логирование и мониторинг (алерты по неуспешному exit‑коду).
• Опишите регламент миграций структуры каталогов и крупных пачек изменений.

Распространённые «грабли» и как их обойти

• Case‑only переименования (например, IMG_001.jpg → img_001.jpg): на некоторых файловых системах это разные имена, а на других — коллизия. Избегайте таких переименований, нормализуйте имена заранее.
• Нестабильные метаданные (EXIF и прочее): приводят к частым перезаписям без видимой пользы. Закрепите процесс обработки изображений.
• Случайные массовые удаления: держите --max-delete, «сухой» прогон на ключевых изменениях и бэкап‑каталог.
• Смена провайдера S3 или региона: тестируйте checksum, поведение листинга и границы multipart на стенде, прогоните несколько bisync‑циклов до переключения.

Итог

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