Когда ты работаешь с 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, выбираем
drivegdriveS3 (например, Backblaze B2, Amazon S3 или Yandex Object Storage)
Тоже через
rclone configs3https://storage.yandexcloud.netСинхронизация данных: команды на каждый день
Обычная синхронизация каталога
/var/wwwrclone 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. Вот как я настроила:
- Создала новый remote типа , выбрав в качестве базы —
cryptgdrive:backups/secure - Указала пароль (можно сгенерировать безопасный)
- Копирую данные туда:
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
| Облако | Бесплатный объём | Поддержка Rclone | Подходит для бэкапов? | Скорость доступа | Комментарий |
|---|---|---|---|---|---|
| Google Drive | 15 ГБ | ✅ Полная | ✅ Отлично | 🔼 Быстрая | Идеальный вариант для начала |
| Dropbox | 2 ГБ | ✅ Частичная | ⚠ Только малые файлы | 🔽 Средняя | Урезанная функциональность |
| Yandex Disk | 10 ГБ | ✅ Через WebDAV | ✅ Нормально | 🔼 Хорошая | Нужно настроить вручную |
| Amazon S3 | Платно | ✅ Полная | ✅ Надёжно | 🚀 Высокая | Лучше для бизнеса и крупных проектов |
| Backblaze B2 | 10 ГБ | ✅ Полная | ✅ Отлично | 🔼 Умеренная | Очень выгодный тариф за терабайты |
| Mega.nz | 20 ГБ | ✅ Частичная | ⚠ Медленно | 🔽 Низкая | Есть ограничения по API |
Кейсы из моей практики
- 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 установлен
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
💡 Не используйте synccopy
Шаг 4: Перезапуск сервисов
После восстановления не забудьте перезапустить нужные сервисы:
sudo systemctl restart nginx sudo systemctl restart mysql
Проверьте работу сайта или приложения. Если всё работает — поздравляю, вы только что спасли свой проект!
Практический совет
Я храню резервные копии в формате
rsync + tar.gzrclone#!/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.
Ошибки, которые я допускала
- Восстанавливала в запущенную систему — и всё конфликтовало
- Удаляла старые логи и перезаписывала их, забывая про права доступа
- Один раз восстановила от другого сервера — и получила неожиданный shell
.bashrc
Так что — восстанавливайте аккуратно, тестируйте локально, если есть возможность, и не спешите.
Доверие — это взаимно
Оплачиваете 12 месяцев — получаете 13. Потому что нам важны долгосрочные отношения.