Облачное резервное копирование через Rclone и облака (S3, GDrive)

Когда ты работаешь с VPS и на нём крутится хоть что-то важное — будь то сайт, база данных, pet-проект или вообще клиентские данные — ты рано или поздно приходишь к осознанию: резервные копии не просто важны, они критичны. И вот я в один момент подумала — «а что, если мой сервер упадёт завтра?» Не дай бог, конечно. Но ведь может. И вот тогда я начала разбираться в бэкапах — и пришла к Rclone.

Почему именно Rclone?

Потому что он:

• умеет работать почти со всеми облаками (Google Drive, S3, Dropbox, Yandex.Disk, Mega, даже FTP и WebDAV),
• консольный, лёгкий, ставится в пару строк,
• умеет шифровать файлы на лету и синхронизировать каталоги в одну или обе стороны,
• и просто… работает. Без магии и танцев с бубном.

Я протестировала много вариантов — и GUI-программы, и rsync со своими скриптами, но именно rclone sync в связке с Google Drive и S3 оказался самым надёжным решением. А ещё — с минимальными затратами.

Установка Rclone на VPS

В моём случае это Ubuntu 22.04:

curl https://rclone.org/install.sh | sudo bash

После установки можно проверить версию:

rclone version

Всё, готово.

Настройка доступа к облаку: Google Drive и S3

Google Drive

Запускаем интерактивный конфигуратор:

rclone config

Создаём новый remote, выбираем drive, авторизуемся в браузере (да, даже с сервера это можно сделать через копирование ссылки в локальный браузер), задаём имя (например, gdrive), и всё.

S3 (например, Backblaze B2, Amazon S3 или Yandex Object Storage)

Тоже через rclone config, но выбираем s3, вводим ключ и секрет, регион, endpoint (если используете не Amazon, например, https://storage.yandexcloud.net), и сохраняем.

Синхронизация данных: команды на каждый день

Обычная синхронизация каталога /var/www с облаком:

rclone sync /var/www gdrive:backups/www --progress

Если используешь S3:

rclone sync /var/www s3:mybucket/backups/www --progress

Я всегда добавляю --progress — люблю видеть, что именно сейчас копируется.

Расписание и автоматизация через Cron

В crontab добавляем задачу, чтобы делать бэкап каждый день в 3 ночи:

0 3 * * * /usr/bin/rclone sync /var/www gdrive:backups/www --log-file=/var/log/rclone.log

Логи тоже полезны — пару раз мне помогали понять, почему что-то не скопировалось (спойлер: я забыла про chmod и права на файлы).

Пример: резервное копирование баз данных

Если вы, как и я, используете PostgreSQL или MySQL, нужно сначала сделать дамп:

pg_dump mydb > /tmp/mydb.sql
rclone copy /tmp/mydb.sql gdrive:backups/db

Аналогично и с mysqldump.

Я храню только 3 последних дампа — остальное очищаю через скрипт, чтобы не переполнить хранилище. Хотя в GDrive можно и разгуляться — 15 ГБ бесплатно.

Шифрование: безопасные бэкапы — спокойная жизнь

Rclone поддерживает crypt. Вот как я настроила:

1. Создала новый remote типа crypt, выбрав в качестве базы — gdrive:backups/secure
2. Указала пароль (можно сгенерировать безопасный)
3. Копирую данные туда:

rclone copy /etc/letsencrypt cryptremote:etc/

Теперь даже если кто-то получит доступ к облаку — ничего не расшифрует без пароля.

Что ещё можно сделать с Rclone?

• Смонтировать облако как диск:

rclone mount gdrive: ~/mnt/gdrive

• Проверить отличия между локальным и облачным:

rclone check /var/www gdrive:backups/www

• Сравнить, сколько места занято:

rclone size gdrive:backups

• Лимит скорости, если боишься перегрузить сеть:

rclone sync /var/www gdrive:backups/www --bwlimit 5M

Пример моего сценария (простой bash-скрипт)

#!/bin/bash
DATE=$(date +%F)
mkdir -p /tmp/backups
pg_dump mydb > /tmp/backups/mydb-$DATE.sql
tar czf /tmp/backups/etc-$DATE.tar.gz /etc
rclone copy /tmp/backups gdrive:backups/$(hostname)/$DATE --log-file=/var/log/rclone_backup.log
rm -rf /tmp/backups

И этот скрипт крутится в cron’е. Мне не нужно думать — просто проверяю раз в неделю лог, что всё прошло.

Rclone — это та самая палочка-выручалочка, которая даёт тебе спокойствие: данные сохранены, резервные копии есть, доступ есть откуда угодно, и всё это бесплатно (если использовать Google Drive или Yandex Disk).

Уже было несколько случаев, когда что-то на VPS ломалось — и благодаря бэкапу через Rclone я восстанавливала всё за полчаса. Лучше один раз настроить, чем потом жалеть.

Отлично! Вот продолжение — таблица сравнения облачных хранилищ для Rclone + мини-кейсы для большей полезности и “человечности” статьи:

Таблица: с какими облаками лучше всего использовать Rclone

Кейсы из моей практики

• Google Drive для сайтов: использую для регулярных бэкапов сайтов на WordPress. Синхронизация — раз в день, отдельно выгружаю папку /var/www и базу.
• S3 (Yandex Cloud) для клиентских данных: на проектах, где есть чувствительная информация, использую шифрование и заливаю на S3. Там можно гибко настраивать права доступа и ретеншн.
• Backblaze — для архива: туда складываю всё, что не хочется потерять: старые проекты, фотографии, даже логи. 1 ТБ за пару баксов — отличная альтернатива внешнему жёсткому диску.
• Yandex Disk для быстрых драфтов: когда делаю тестовые сервера или прототипы, удобно сохранять дампы туда — не нужно платить, и всё под рукой.

Восстановление VPS из резервной копии с помощью Rclone: пошаговое руководство

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

Что нужно, чтобы восстановиться?

Прежде всего, у вас должен быть:

• Доступ к VPS (даже если новый, “чистый” после сбоя)
• Установленный rclone (настраивается по инструкции из предыдущей статьи)
• Доступ к облаку (S3, GDrive и т. п.), где лежит ваша резервная копия
• Знание структуры резервной директории (например, rclone remote:backups/myserver-2025-07-01/)

Шаг 1: Проверяем, что rclone установлен

Если вы только что подняли VPS после сбоя — начнём с установки:

sudo apt update && sudo apt install rclone -y

И сразу подключаем нужное облако (если ещё не подключали):

rclone config

Шаг 2: Просматриваем содержимое архива

Прежде чем что-либо восстанавливать, полезно убедиться, что резерв есть и он целый:

rclone ls remote:backups/myserver-2025-07-01/

Если видите знакомые файлы и директории — всё хорошо. А если не видите — проверьте дату или подключение к облаку.

Шаг 3: Восстанавливаем файлы

Теперь самое главное — перенести всё обратно на VPS. Лучше начинать с базовых конфигураций, а уже потом переносить большие массивы данных.

Например, восстановим /etc/nginx/:

sudo rclone sync remote:backups/myserver-2025-07-01/etc/nginx/ /etc/nginx/

Или базу данных:

sudo rclone copy remote:backups/myserver-2025-07-01/var/lib/mysql/ /var/lib/mysql/ --copy-links

💡 Не используйте sync, если не уверены — он может удалить несоответствующие файлы на стороне VPS. Лучше copy для начала.

Шаг 4: Перезапуск сервисов

После восстановления не забудьте перезапустить нужные сервисы:

sudo systemctl restart nginx
sudo systemctl restart mysql

Проверьте работу сайта или приложения. Если всё работает — поздравляю, вы только что спасли свой проект!

Практический совет

Я храню резервные копии в формате rsync + tar.gz и выгружаю их через rclone в GDrive. Вот мой скрипт восстановления для конфигов Nginx:

#!/bin/bash
rclone copy gdrive:backups/nginx.tar.gz /tmp/
cd /etc/nginx && sudo tar -xzf /tmp/nginx.tar.gz
sudo systemctl restart nginx

И такие скрипты у меня для всего: баз данных, docker, сайтов и даже crontab.

Ошибки, которые я допускала

• Восстанавливала в запущенную систему — и всё конфликтовало
• Удаляла старые логи и перезаписывала их, забывая про права доступа
• Один раз восстановила .bashrc от другого сервера — и получила неожиданный shell

Так что — восстанавливайте аккуратно, тестируйте локально, если есть возможность, и не спешите.