Автоматизация бэкапа на Яндекс.Диск и Google Drive через rclone: готовые скрипты для DevOps | AdminWiki
AdminWiki

Автоматизация бэкапа на Яндекс.Диск и Google Drive через rclone: готовые скрипты для DevOps

16 мая 2026 16 мин. чтения
Содержание статьи

Ручное резервное копирование - это риск потерять данные из-за человеческого фактора и трата времени на рутину. Автоматизация процесса с помощью rclone решает обе проблемы, предоставляя единый интерфейс для работы с десятками облачных хранилищ, включая Яндекс.Диск и Google Drive. Эта статья содержит готовое решение: проверенные на практике скрипты, конфигурации и инструкции по настройке безопасного автоматизированного пайплайна для выгрузки SQL-дампов, логов и медиаконтента. Вы получите не просто теорию, а рабочий инструмент, который можно внедрить в течение часа.

Содержание

  • Быстрый старт за 5 минут
  • Почему rclone - оптимальный инструмент для облачных бэкапов
  • Подготовка: получаем токены API для Яндекс.Диск и Google Drive
  • Базовая настройка rclone: создаем конфигурацию для облаков
  • Готовые сценарии для типовых задач DevOps
  • Пишем скрипт для автоматического резервного копирования
  • Повышение безопасности: шифрование данных перед отправкой в облако
  • Автоматизация: добавляем скрипт в cron и мониторим выполнение
  • Особенности, ограничения и решение проблем
  • Частые вопросы (FAQ)

Быстрый старт за 5 минут

Если вы опытный администратор и хотите сразу проверить работоспособность связки rclone + облако, выполните эту сокращенную последовательность. Детальные пояснения и настройка безопасности — в следующих разделах.

  1. Установите rclone: curl https://rclone.org/install.sh | sudo bash
  2. Получите OAuth-токен для Яндекс.Диска (инструкция ниже) или настройте доступ к Google Drive API.
  3. Настройте remote: rclone config → создайте новый (например, yandex_backup) типа yandex или drive.
  4. Проверьте подключение: rclone lsd yandex_backup: (должен показать список папок).
  5. Скопируйте тестовый файл: echo "test" > /tmp/test.txt && rclone copy /tmp/test.txt yandex_backup:/backups
  6. Убедитесь в успехе: rclone ls yandex_backup:/backups

Если эти шаги выполнены успешно, инфраструктура готова к автоматизации. Переходите к написанию скриптов и настройке мониторинга.

Почему rclone - оптимальный инструмент для облачных бэкапов

Выбор инструмента для автоматизации резервного копирования определяет надежность и удобство всего процесса. Rclone выигрывает у альтернатив по нескольким ключевым параметрам, критически важным для DevOps-инженеров и системных администраторов.

В отличие от встроенных клиентов облачных сервисов, rclone предлагает единый синтаксис команд для работы с разными хранилищами. Это позволяет стандартизировать скрипты резервного копирования. По сравнению со связкой rsync+ssh, rclone изначально поддерживает протоколы облачных API, что исключает необходимость настройки промежуточных серверов.

Главные преимущества rclone для задач из описания статьи:

  • Единый интерфейс для разных облаков. Конфигурация и команды для Яндекс.Диска и Google Drive идентичны, что упрощает поддержку.
  • Встроенная поддержка сквозного шифрования. Данные можно шифровать на стороне клиента перед отправкой в облако, что критично для конфиденциальной информации.
  • Надежность передачи. Механизмы повторных попыток, проверки контрольных сумм и докачки прерванных операций.
  • Детальное логирование. Возможность вести структурированные логи для аудита и мониторинга успешности операций.
  • Широкие возможности автоматизации. Интеграция с cron, systemd и скриптами на Bash или Python.

Этот набор функций делает rclone оптимальным выбором для создания автоматизированного пайплайна, который не требует постоянного внимания, но гарантирует сохранность данных.

Подготовка: получаем токены API для Яндекс.Диск и Google Drive

Авторизация через API - первый и самый важный этап. От правильности его выполнения зависит безопасность и работоспособность всей системы. Ниже приведены пошаговые инструкции для каждого сервиса.

Общее правило безопасности: никогда не храните токены и секреты в открытом виде в скриптах или конфигурационных файлах, которые могут попасть в системы контроля версий. Используйте переменные среды или специализированные хранилища секретов.

Настройка доступа к API Яндекс.Диска

Яндекс использует протокол OAuth 2.0 для авторизации приложений. Для работы с API Диска вам потребуется создать OAuth-приложение в Яндекс ID.

  1. Перейдите в Яндекс OAuth и нажмите «Зарегистрировать новое приложение».
  2. Укажите название приложения (например, «Rclone Backup»), выберите платформы «Веб-сервисы».
  3. В поле «Права» обязательно отметьте «Доступ к информации о диске» и «Доступ к папке приложения на Диске». Для полного доступа к загрузке и управлению файлами также может потребоваться право «Доступ к Яндекс.Диску».
  4. После создания приложения вы получите ID приложения (Client ID) и Пароль (Client Secret). Запишите их.
  5. Для получения токена пользователя сформируйте URL для авторизации:
    https://oauth.yandex.ru/authorize?response_type=token&client_id=ВАШ_CLIENT_ID
  6. Перейдите по этому URL в браузере, авторизуйтесь под нужной учетной записью Яндекса и разрешите доступ приложению. В результате вы будете перенаправлены на страницу, в URL которой будет параметр access_token=.... Это ваш токен.

Пример команды rclone для начальной конфигурации с этим токеном (токен вводится на следующем шаге):

rclone config
> n (новый remote)
name> yandex_backup
type> yandex
client_id> (оставьте пустым, если используете токен напрямую)
client_secret> (оставьте пустым)
Edit advanced config? n
Use auto config? n
Если у вас есть токен, выберите вариант ввода токена напрямую и вставьте его.

Настройка доступа к API Google Drive

Процесс настройки в Google Cloud Console состоит из нескольких этапов, но он стандартизирован.

  1. Создайте новый проект или выберите существующий в Google Cloud Console.
  2. В меню «APIs & Services» перейдите в «Library», найдите и включите «Google Drive API».
  3. В разделе «Credentials» создайте новые учетные данные (Create Credentials) типа «OAuth 2.0 Client ID».
  4. Тип приложения выберите «Desktop app» или «Other» (для скриптов, запускаемых из терминала).
  5. После создания вы сможете скачать файл client_secret_XXXXX.json. Сохраните его в безопасном месте на сервере.
  6. При первой конфигурации rclone запросит авторизацию в браузере. Если сервер headless, используйте флаг --auth-no-open-browser и скопируйте ссылку для авторизации на локальный компьютер.

Важное предупреждение: бесплатное использование Google Drive API имеет суточные лимиты на количество запросов (примерно 10 000 операций в день для проекта по умолчанию). Для интенсивных операций с большим количеством файлов это может стать ограничением.

Базовая настройка rclone: создаем конфигурацию для облаков

Конфигурация rclone хранится в файле ~/.config/rclone/rclone.conf. Для безопасности рекомендуется использовать переменные среды для хранения токенов.

Запустите интерактивную настройку командой rclone config и последовательно создайте два удаленных хранилища (remotes) - для Яндекс.Диска и Google Drive. В процессе вам нужно будет ввести полученные на предыдущем шаге данные.

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

[yandex_backup]
type = yandex
token = {"access_token":"${RCLONE_YANDEX_TOKEN}","token_type":"bearer","expiry":"2026-12-31T23:59:59Z"}

[gdrive_backup]
type = drive
client_id = ${RCLONE_GDRIVE_CLIENT_ID}
client_secret = ${RCLONE_GDRIVE_CLIENT_SECRET}
token = ${RCLONE_GDRIVE_TOKEN}

Перед использованием экспортируйте переменные в оболочке или в скрипте:

export RCLONE_YANDEX_TOKEN="ваш_токен_яндекса"
export RCLONE_GDRIVE_CLIENT_ID="ваш_client_id"
# ... и так далее

Проверьте подключение к каждому хранилищу командой просмотра корневой директории:

rclone lsd yandex_backup:
rclone lsd gdrive_backup:

Успешное выполнение команд выведет список папок в корне вашего облачного диска, что подтвердит правильность настройки.

Готовые сценарии для типовых задач DevOps

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

Сценарий 1: Резервное копирование Docker volumes

Этот скрипт останавливает указанные контейнеры, создает архив их volumes, а затем перезапускает контейнеры. Используйте с осторожностью на production-сервисах, планируя выполнение в период минимальной нагрузки.

#!/bin/bash
# backup_docker_volumes.sh
set -euo pipefail

BACKUP_NAME="docker-volumes-$(date +%Y%m%d)"
LOCAL_DIR="/tmp/docker_backup"
REMOTE="yandex_backup:/backups/docker"
CONTAINERS=("app_db" "app_redis") # Контейнеры, volumes которых нужно скопировать
VOLUME_PREFIX="/var/lib/docker/volumes"

mkdir -p "$LOCAL_DIR"

for CONTAINER in "${CONTAINERS[@]}"; do
    echo "Остановка контейнера $CONTAINER..."
    docker stop "$CONTAINER"
    VOLUME_NAME=$(docker inspect "$CONTAINER" --format='{{range .Mounts}}{{if eq .Type "volume"}}{{.Name}}{{end}}{{end}}')
    if [ -n "$VOLUME_NAME" ]; then
        ARCHIVE="$LOCAL_DIR/$BACKUP_NAME-$VOLUME_NAME.tar.gz"
        echo "Архивирование volume: $VOLUME_NAME"
        tar -czf "$ARCHIVE" -C "$VOLUME_PREFIX" "$VOLUME_NAME"
    fi
    echo "Запуск контейнера $CONTAINER..."
    docker start "$CONTAINER"
done

rclone copy "$LOCAL_DIR/" "$REMOTE/" --transfers 2 --log-level INFO
rm -rf "$LOCAL_DIR"
echo "Бэкап Docker volumes завершен."

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

Transferred:   1.234 GiB / 1.234 GiB, 100%, 45.123 MiB/s, ETA 0s
Checks:                 0 / 0, -
Transferred:            2 / 2, 100%
Elapsed time:        2m45.2s

Сценарий 2: Выгрузка и ротация логов Nginx/Apache

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

#!/bin/bash
# backup_rotate_logs.sh
set -euo pipefail

LOG_DIR="/var/log/nginx"
BACKUP_NAME="logs-$(date +%Y%m%d)"
LOCAL_ARCHIVE="/tmp/$BACKUP_NAME.tar.gz"
REMOTE="gdrive_backup:/backups/logs"
RETENTION_DAYS=30 # Удалять локальные архивы старше 30 дней

# Архивируем все логи, кроме сегодняшнего access.log
find "$LOG_DIR" -name "*.log*" -mtime +0 -type f | tar -czf "$LOCAL_ARCHIVE" -T -

# Выгружаем в облако
rclone copy "$LOCAL_ARCHIVE" "$REMOTE/"

# Очищаем старые логи (оставляем только сегодняшние)
find "$LOG_DIR" -name "*.log" -mtime +0 -exec truncate -s 0 {} \;

# Удаляем локальные архивы старше RETENTION_DAYS
find "/tmp" -name "logs-*.tar.gz" -mtime +$RETENTION_DAYS -delete

Сценарий 3: Резервное копирование PostgreSQL (полный дамп и ротация)

Важное уточнение: pg_dump не поддерживает истинно инкрементальные дампы — каждый запуск создаёт полный снимок базы. Флаг --reference-snapshot предназначен для согласованности параллельных дампов (-j), а не для инкремента. Поэтому для баз небольшого и среднего размера применяют полный дамп в custom-формате (-Fc) с последующей ротацией, а для больших баз переходят на непрерывное архивирование WAL.

#!/bin/bash
# backup_postgres.sh
set -euo pipefail

DB_NAME="myapp"
BACKUP_DIR="/var/backups/postgres"
REMOTE="yandex_backup:/backups/postgres"

mkdir -p "$BACKUP_DIR"
BACKUP_FILE="$BACKUP_DIR/$DB_NAME-$(date +%Y%m%d).dump"

# pg_dump всегда создаёт полный дамп в custom-формате
pg_dump -Fc "$DB_NAME" -f "$BACKUP_FILE"

# Выгрузка в облако
rclone copy "$BACKUP_FILE" "$REMOTE/" --progress

# Ротация: удаляем локальные дампы старше 7 дней
find "$BACKUP_DIR" -name "*.dump" -mtime +7 -delete

Для баз объёмом в сотни гигабайт ежедневный полный дамп неэффективен. В этом случае используйте WAL-архивирование (например, pgBackRest или barman) — пошаговый разбор сценария восстановления есть в статье «Восстановление PostgreSQL после сбоя в проде».

Пишем скрипт для автоматического резервного копирования

Сердце автоматизации - это скрипт, который архивирует данные и передает их в облако. Ниже приведен готовый Bash-скрипт с подробными комментариями, который решает задачу резервного копирования директории с логами и базы данных MySQL/MariaDB.

Ключевые команды rclone в скрипте: copy, sync, проверка

Понимание разницы между основными командами rclone критически важно для предотвращения потери данных.

  • rclone copy - копирует файлы из источника в назначение, пропуская уже существующие идентичные файлы (определяется по размеру и дате изменения или хешу). Это безопасная команда для инкрементального добавления новых бэкапов. Она никогда не удаляет файлы в назначении.
  • rclone sync - синхронизирует содержимое источника и назначения, делая их идентичными. Это означает, что файлы, существующие в назначении, но отсутствующие в источнике, будут удалены. Используйте эту команду с крайней осторожностью, только если вам нужно точное зеркало. Для бэкапов почти всегда предпочтительнее copy.

Полезные флаги для повышения надежности и производительности:

  • --transfers 4 - количество параллельных файловых передач.
  • --checkers 8 - количество параллельных проверок файлов.
  • --retries 3 - количество повторных попыток при сбое.
  • --low-level-retries 10 - повторные попытки на низком уровне при неудачном запросе API.
  • --progress - отображение прогресса в реальном времени (полезно для ручного запуска).

Обработка ошибок и логирование: делаем скрипт надежным

Промышленный скрипт должен не просто выполнять задачу, но и сообщать о проблемах. Используйте директиву set -euo pipefail в начале скрипта. Она обеспечивает выход при любой ошибке, использование неопределенных переменных и учитывает ошибки в конвейерах (pipes).

Логирование в отдельный файл с датой позволяет вести историю операций. Флаг rclone --log-file=/var/log/rclone/backup-$(date +%Y%m%d).log --log-level INFO записывает детальный лог. Настройте ротацию логов с помощью logrotate.

Реализуйте простой механизм уведомлений. В примере ниже используется отправка статуса в syslog, что интегрируется с большинством систем мониторинга. Альтернативно можно добавить отправку через curl к API Telegram, Slack или по электронной почте.

#!/bin/bash
# backup_script.sh
# Полный скрипт автоматического резервного копирования с rclone

# Безопасный режим: выход при ошибках, проверка необъявленных переменных
set -euo pipefail

# --- Конфигурация ---
BACKUP_NAME="server-backup-$(date +%Y%m%d)"
LOCAL_BACKUP_DIR="/tmp/backups"
REMOTE_STORAGE="yandex_backup:/backups" # Или gdrive_backup:/backups
LOG_FILE="/var/log/rclone/backup-$(date +%Y%m%d).log"

# Директории и БД для бэкапа
BACKUP_SOURCES=("/var/log/nginx" "/opt/app/data")
MYSQL_DATABASES=("app_db" "wiki_db")
MYSQL_USER="backup_user"
MYSQL_PASSWORD="secure_password" # Лучше хранить в .my.cnf или переменной среды

# --- Инициализация ---
mkdir -p "$LOCAL_BACKUP_DIR"
mkdir -p "$(dirname "$LOG_FILE")"
echo "$(date) - Начало резервного копирования $BACKUP_NAME" | tee -a "$LOG_FILE"

# --- Создание бэкапа баз данных ---
for DB in "${MYSQL_DATABASES[@]}"; do
    DUMP_FILE="$LOCAL_BACKUP_DIR/$BACKUP_NAME-$DB.sql.gz"
    echo "$(date) - Дамп базы данных: $DB" | tee -a "$LOG_FILE"
    mysqldump --single-transaction --quick -u"$MYSQL_USER" -p"$MYSQL_PASSWORD" "$DB" | gzip > "$DUMP_FILE"
    if [ ${PIPESTATUS[0]} -ne 0 ]; then
        echo "$(date) - ОШИБКА: Не удалось создать дамп базы $DB" | tee -a "$LOG_FILE"
        logger -p local0.err "Rclone backup failed: MySQL dump error for $DB"
        exit 1
    fi
done

# --- Архивирование директорий ---
for SOURCE_DIR in "${BACKUP_SOURCES[@]}"; do
    DIR_NAME=$(basename "$SOURCE_DIR")
    ARCHIVE_FILE="$LOCAL_BACKUP_DIR/$BACKUP_NAME-$DIR_NAME.tar.gz"
    echo "$(date) - Архивирование: $SOURCE_DIR" | tee -a "$LOG_FILE"
    tar -czf "$ARCHIVE_FILE" -C "$(dirname "$SOURCE_DIR")" "$DIR_NAME" 2>> "$LOG_FILE"
    if [ $? -ne 0 ]; then
        echo "$(date) - ОШИБКА: Не удалось заархивировать $SOURCE_DIR" | tee -a "$LOG_FILE"
        logger -p local0.err "Rclone backup failed: tar error for $SOURCE_DIR"
        exit 1
    fi
done

# --- Выгрузка в облако через rclone ---
echo "$(date) - Начало выгрузки в $REMOTE_STORAGE" | tee -a "$LOG_FILE"
rclone copy "$LOCAL_BACKUP_DIR/" "$REMOTE_STORAGE/" \
    --transfers 4 \
    --checkers 8 \
    --retries 3 \
    --low-level-retries 10 \
    --progress \
    --log-file "$LOG_FILE" \
    --log-level INFO \
    --stats 30s

RCLONE_EXIT_CODE=$?
if [ $RCLONE_EXIT_CODE -eq 0 ]; then
    echo "$(date) - УСПЕХ: Выгрузка завершена" | tee -a "$LOG_FILE"
    logger -p local0.info "Rclone backup completed successfully: $BACKUP_NAME"
else
    echo "$(date) - ОШИБКА: Rclone завершился с кодом $RCLONE_EXIT_CODE" | tee -a "$LOG_FILE"
    logger -p local0.err "Rclone backup failed with code $RCLONE_EXIT_CODE"
    exit $RCLONE_EXIT_CODE
fi

# --- Очистка локальных временных файлов (опционально) ---
# rm -rf "$LOCAL_BACKUP_DIR"/*

echo "$(date) - Резервное копирование завершено" | tee -a "$LOG_FILE"

Повышение безопасности: шифрование данных перед отправкой в облако

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

Шифрование происходит на вашем сервере перед отправкой. В облако попадают уже зашифрованные файлы с нечитаемыми именами. Для дешифрования необходим ключ, который хранится только у вас.

Создайте зашифрованный remote поверх существующего (например, поверх gdrive_backup):

rclone config
> n
name> gdrive_encrypted
type> crypt
remote> gdrive_backup:/encrypted_backups
Enter configuration for the crypt remote.
Choose your encryption password (ваш_сильный_пароль).
Choose your salt password (другая_сильная_соль_или_оставьте_пусто).

В конфигурационном файле появится новая секция:

[gdrive_encrypted]
type = crypt
remote = gdrive_backup:/encrypted_backups
password = ENCRYPTED_PASS_HASH
password2 = ENCRYPTED_SALT_HASH

Используйте этот новый remote (gdrive_encrypted:) в скрипте вместо обычного. Все файлы, скопированные туда, будут автоматически зашифрованы.

Критически важное предупреждение: Пароль и соль (salt) - это ключи для шифрования. Их потеря означает безвозвратную потерю всех зашифрованных данных. Храните их в надежном месте, например, в менеджере паролей, и убедитесь, что они включены в ваш план аварийного восстановления.

Автоматизация: добавляем скрипт в cron и мониторим выполнение

Чтобы скрипт выполнялся регулярно без вашего участия, добавьте его в планировщик задач cron. Откройте crontab для пользователя, от которого будет запускаться бэкап (обычно root или выделенный пользователь backup):

crontab -e

Добавьте строку для ежедневного запуска в 2:00 ночи:

# Ежедневное резервное копирование в 2:00
0 2 * * * /bin/bash /путь/к/скрипту/backup_script.sh >> /var/log/backup-cron.log 2>&1

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

Мониторинг выполнения и проверка свежести бэкапов

Мониторинг выполнения обязателен. Простой способ - проверять свежесть файлов в облаке. Ниже приведен скрипт на Python, который проверяет, создавался ли сегодня файл бэкапа, и отправляет уведомление в Telegram в случае проблемы.

#!/usr/bin/env python3
# check_backup_freshness.py
import subprocess
import json
from datetime import datetime, timedelta
import requests

REMOTE = "yandex_backup:/backups"
BACKUP_PREFIX = "server-backup-"
TELEGRAM_BOT_TOKEN = "YOUR_BOT_TOKEN"
TELEGRAM_CHAT_ID = "YOUR_CHAT_ID"

# Получаем список файлов с помощью rclone lsl (длинный список с модификацией)
cmd = ["rclone", "lsl", REMOTE]
result = subprocess.run(cmd, capture_output=True, text=True)

if result.returncode != 0:
    message = f"❌ Ошибка выполнения rclone lsl: {result.stderr}"
else:
    today = datetime.now().date()
    found_today = False
    for line in result.stdout.strip().split('\n'):
        parts = line.split()
        if len(parts) >= 4 and BACKUP_PREFIX in parts[3]:
            # parts[0] - размер, parts[1] - дата модификации (timestamp)
            mod_time = datetime.fromtimestamp(int(parts[1]))
            if mod_time.date() == today:
                found_today = True
                break

    if not found_today:
        message = f"⚠️ Бэкап за {today} не найден в {REMOTE}!"
    else:
        message = f"✅ Бэкап за {today} успешно создан."
        print(message)
        exit(0)

# Отправка уведомления в Telegram
if TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID:
    url = f"https://api.telegram.org/bot{TELEGRAM_BOT_TOKEN}/sendMessage"
    payload = {"chat_id": TELEGRAM_CHAT_ID, "text": message}
    requests.post(url, json=payload)

print(message)

Для интеграции в Prometheus/Grafana можно создать простой экспортер, который проверяет наличие свежего бэкапа и выставляет метрику (например, backup_freshness_timestamp). Также можно интегрировать логи rclone в вашу систему мониторинга, такую как Zabbix или Prometheus, с помощью парсера логов. Подробнее о настройке мониторинга читайте в нашей статье «Мониторинг и алертинг распределенных систем».

Особенности, ограничения и решение проблем

Даже правильно настроенный пайплайн рано или поздно сталкивается с лимитами облачных API и ошибками авторизации. Ниже — типовые проблемы, их причины и рабочие способы диагностики и обхода.

Ошибки 403 и 429: превышение квот облачных API

Google Drive и Яндекс.Диск ограничивают количество запросов к API. При интенсивной работе с множеством мелких файлов вы можете получить ответы 403 rateLimitExceeded или 429 Too Many Requests. Для проекта Google Cloud по умолчанию действует лимит порядка 10 000 запросов в сутки — этого хватает не всегда.

Что делать:

  • Ограничьте скорость запросов флагами --tpslimit 1 и --tpslimit-burst 1.
  • Архивируйте множество мелких файлов в один .tar.gz перед отправкой — это радикально снижает число обращений к API.
  • Не запускайте несколько rclone-задач одновременно, чтобы не исчерпать квоту за короткое время.
  • Если лимита стабильно не хватает, запросите увеличение квоты в Google Cloud Console.

Истёкшие и недействительные OAuth-токены

Симптом: команды падают с 401 Unauthorized или сообщением invalid_grant. OAuth-токены обновляемые, но refresh-токен может быть отозван — например, после смены пароля или ручного отзыва доступа к приложению. Проверьте авторизацию командой rclone config reconnect yandex_backup: и при необходимости пройдите её заново. Напоминаем: токены нельзя коммитить в репозиторий — храните их в переменных среды или менеджере секретов.

Конфликты имён и дубликаты файлов

rclone сравнивает файлы по размеру и дате изменения (или по хешу с флагом --checksum). Если два разных файла имеют одинаковое имя в одной папке назначения, второй перезапишет первый при выгрузке. Для датированных бэкапов проблема редкость, но для ротации логов — реальна. Избегайте шаблонов имён без суффикса даты и используйте уникальные префиксы, как в примерах выше (server-backup-, logs-, docker-volumes-).

Диагностика: как читать логи rclone

Для разбора инцидента поднимите уровень логирования до DEBUG:

rclone copy /tmp/backups/ yandex_backup:/backups/ --log-level DEBUG --log-file /var/log/rclone/debug.log

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

  • rclone lsl yandex_backup:/backups — список файлов с размерами и датами модификации, помогает убедиться, что свежий бэкап действительно доехал.
  • rclone about yandex_backup: — занятое и свободное место в облаке (поддерживается не всеми провайдерами).
  • rclone check /tmp/backups yandex_backup:/backups — сверка источника и назначения по хешам.

Важное предупреждение: никогда не используйте rclone sync для папки с бэкапами, если источник может оказаться пустым или неполным. Один неудачный запуск с пустой исходной директорией удалит все копии в облаке. Для резервного копирования предназначен rclone copy, а от случайного удаления защищают версионирование бакета и Object Lock.

Частые вопросы (FAQ)

Почему rclone лучше альтернатив для облачных бэкапов?

Rclone предоставляет единый интерфейс для десятков облачных хранилищ, встроенное клиентское шифрование, надежные механизмы повторных попыток и детальное логирование. Это позволяет стандартизировать скрипты резервного копирования и минимизировать риски потери данных.

Как избежать ошибки 429 «Too Many Requests» при работе с Google Drive?

Используйте флаг --tpslimit 1 в командах rclone для ограничения количества запросов в секунду. Архивируйте множество мелких файлов в один .tar.gz перед отправкой. При необходимости увеличьте квоты API в Google Cloud Console.

Как проверить, что бэкап выполняется успешно и данные доходят в облако?

Используйте команду rclone lsl remote:папка для просмотра списка файлов с датами модификации. Настройте скрипт мониторинга (например, на Python), который проверяет свежесть последнего бэкапа и отправляет уведомления в Telegram или Slack в случае проблем.

Как ротировать бэкапы в облаке?

Встроенного управления сроком хранения у rclone нет — используйте дату в имени файла и команду rclone delete с фильтром по возрасту, например rclone delete yandex_backup:/backups --min-age 30d. Дополнительно включите версионирование бакета и придерживайтесь стратегии 3-2-1.

Что делать, если потерян пароль от crypt-remote?

Ключи шифрования хранятся только в вашем rclone.conf, в облаке их нет. Если пароль или salt утеряны, расшифровать данные невозможно — останется пересоздать remote и загрузить копии заново. Поэтому храните пароль в менеджере секретов и дублируйте его в оффлайн-копии.

Поделиться: