Резервное копирование на дешёвом VPS-сервере

Мы уже рассказывали, как можно использовать ультрадешёвый VPS за 130 рублей в месяц. На самом деле 512 МБ оперативной памяти вполне достаточно для нормальной работы Linux (без GUI) и множества приложений, таких как VPN, веб-хостинг, некоторые игровые серверы, а также для резервного копирования файлов.

Конечно, в интернете куча облачных хостингов, но всё-таки приватные файлы спокойнее хранить на личном сервере, который полностью под нашим контролем.

Правда, минимальная конфигурация на RUVDS включает в себя диск всего на 10 ГБ, из которых пару гигабайт займёт система, так что это не оптимальный вариант для полноценного бэкапа. В таком случае к VPS можно подключить дополнительное хранилище по ₽500 рублей за терабайт.

Если минимальный сервер с 0,5 ГБ RAM без услуги «Большой Диск» стоит ₽130 в месяц (₽104 при оплате за год), то сервер с диском на 1 ТБ идёт уже с 1 ГБ памяти и стоит ₽1005 в месяц, на 2 ТБ — ₽1505 и так далее. Максимально в конфигураторе можно заказать основной диск на 600 ГБ и дополнительный диск на 18 ТБ.



Специально для организации хранилища данных на RUVDS предлагается услуга «Облачное хранилище», где изначально подобраны три оптимальные конфигурации для VPS с облачным хранилищем или файл-сервером. Цена на эти три специальных тарифа обозначена на несколько рублей выше, чем если выбрать аналогичный сервер в конфигураторе (на скриншоте вверху).



Вполне годным вариантом будет выбрать в конфигураторе сервер, аналогичный тарифу «СХД Старт», но за ₽1005: это операционная система Linux, процессор Xeon 2 ГГц (1 ядро), оперативная память 1 ГБ, системный диск HDD на 20 ГБ и дополнительный диск на 1 ТБ (услуга «Большой Диск»), статичный IP-адрес. Трафик неограниченный и бесплатный.

Из дистрибутивов выберем Debian 12. Можно заметить, что на старших тарифах линейки «Облачное хранилище» по умолчанию предлагается установить не Linux, а Windows. Наверное, выбор ОС не имеет принципиального значения для файлового хранилища, если нет задачи экспериментировать с продвинутыми файловыми системами типа ZFS (она пока не портирована под Windows).

После оплаты заказа начинается автоматическая установка ОС.



Установка занимает несколько минут — и сервер готов к использованию. На почту приходит IP-адрес, логин и пароль для доступа по SSH.

Приступим к установке резервного хранилища. В качестве инструмента существует много вариантов, в том числе BorgBackup, bup, CAFS, dedupfs, LBFS, restic, Tahoe-LAFS, tarsnap, Venti, zsync и casync.

Среди них есть и более популярные программы: restic, BorgBackup или rsync, проверенные и надёжные. С другой стороны, есть новые экспериментальные инструменты вроде casync, которые тоже интересно посмотреть, хотя их неудобно использовать на практике.

Итак, подключаемся к серверу через SSH-клиент PuTTY. В клиенте указываем IP-адрес сервера, логин и пароль. Проверим конфигурацию системы:



Процессор и память в порядке.


Жёсткий диск тоже соответствует спецификациям.

▍ Установка restic

Итак, можно приступать к установке системы резервного копирования на сервер (Debian 12) и клиент (Windows 10). Согласно инструкции по установке restic на бэкенд, пакет можно установить из официального репозитория:

$ apt-get install restic

На клиенте под Windows всё немного сложнее, потому что сначала придётся установить консольный инсталлятор Scoop. Это делается с помощью команд PowerShell:

> Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
> Invoke-RestMethod -Uri https://get.scoop.sh | Invoke-Expression

А уже из него ставится restic:

scoop install restic

В терминологии restic хранилище бэкапов называется «репозиторий». Но перед тем как создать (инициализировать) репозиторий, нужно создать инстанс SFTP-сервера или REST-сервера. Второй вариант эффективнее, потому что коммуникация осуществляется по HTTP/HTTPS через REST API, а не по SSH, а сам сервер доступен по ссылкам rest: вроде таких: rest:http://user:passw@194.87.74.115:8000/ (как в нашем случае).

Для инициализации репозитория на сервере запускаем команду restic init -r /dir с указанием директории:


Это можно сделать в удалённом режиме с клиента по HTTP:

$ restic -r rest:http://root:1passw@194.87.74.115:8000/dir/ init

В документации написано, что локальный и удалённый доступ возможны даже одновременно.

В дальнейшем создание резервных копий (снапшотов) на клиенте производится командой restic backup:

$ restic -r /папка_репозитория backup /исходная_папка

Проверим уровень сжатия и скорость работы, сделав снапшот папки /docs с документами объёмом около 1 ГБ (файлы .pdf, .rtf, .odt, .jpg и др.). Точный размер папки на диске — 1 024 214 289 байт. Файлы хранятся в несжатом виде, то есть в нативных форматах. Архивируем папку /docs в репозиторий /docs2:

restic -r /docs2 --verbose backup /docs

Как видим, restic за 45 секунд отсканировал архив размером 976 МиБ на предмет новых или изменённых файлов — и записал в репозиторий снапшот размером 843 МиБ. Здесь особенно радует скорость работы.

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


На этот раз процедура заняла меньше секунды.

Эти снапшоты можно сразу отправлять на REST-сервер, просто указав его rest: URL вместо локальной папки. Инкрементальные бэкапы даже на удалённый сервер происходят практически мгновенно.

Более подробно о настройке REST-сервера для резервного копирования (с автоматическим бэкапом) можно почитать в статье на Хабре.

Добавим, что REST-сервер можно запустить на VPS в докер-контейнере. Возможно, это самый простой способ его использования, потому что он не требует отдельной установки зависимостей (Go 1.18+) и сборки из исходников с помощью официального компилятора Go. Просто скачиваем и запускаем контейнер:

$ docker pull restic/rest-server:latest
$ docker run -p 8000:8000 -v /my/data:/data --name rest_server restic/rest-server

Аутентификация включена по умолчанию, для её отключения нужно изменить переменную DISABLE_AUTHENTICATION на любое значение.

По сравнению с бэкендом SFTP, бэкенд REST показывает лучшую производительность, особенно если отказаться от дополнительного шифрования и использовать простой HTTP-транспорт (дело в том, что restic и так шифрует все отправляемые данные, поэтому использование HTTPS нужно скорее для аутентификации).

Но даже при использовании HTTPS-транспорта протокол REST работает быстрее SFTP из-за некоторых неэффективностей последнего. Например, там всё обязательно передаётся фиксированными блоками по 32 КБ, а сервер должен подтверждать каждый пакет (то есть добавляется задержка на ожидание подтверждения).

Одна из важных функций безопасности REST-сервера — работа в режиме append-only, когда бэкапы доступны только для чтения. Это не позволит злоумышленнику легко удалить файлы, если он получит удалённый доступ к VPS.

REST-сервер — очень простая и маленькая программа на Go, которая работает на сервере практически любой конфигурации, даже на устройствах низкого класса типа Raspberry Pi. В нашем случае это означает, что он комфортно себя чувствует в минимальной конфигурации VPS даже за ₽130 в месяц.

И последнее преимущество REST — это возможность доступа из-за корпоративного файрвола, где из протоколов разрешён только HTTP/HTTPS.

▍ Экспериментальная утилита casync

Программа casync, сокращённо от «синхронизация с адресацией по контенту» (Content Addressable Data Synchronize), использует базовый алгоритм rsync с блоками переменного размера, но с определёнными изменениями, чтобы оптимизировать дедупликацию. Главная оптимизация — удаление границ файлов перед разбивкой на блоки. Это означает, что маленькие файлы объединяются с близкими похожими файлами, а большие файлы разбиваются на части. Таким образом, система находит дубликаты за пределами границ файлов и каталогов. Поэтому можно уменьшить размер инкрементальных обновлений и вообще размер всего репозитория.

Поскольку эта программа разработана позже restic (в 2017 году) и представляет собой усовершенствованные алгоритмы сжатия и дедупликации, она работает с лучшим коэффициентом сжатия.

Для установки casync нужно сначала установить инструменты сборки и компилятор Meson. На сервере это делается следующими командами:

$ apt install build-essential
$ apt install meson ninja-build

Meson — это мультиплатформенный компилятор под все платформы.

Под Windows рекомендуется воспользоваться тулчейном Visual Studio, куда ходит компилятор, а потом скачать установочный файл Meson. При выборе рабочей нагрузки Visual Studio нужно указать «Разработка классических приложений на С++».



Но в целом casync пока считается экспериментальной разработкой, так что для постоянного использования лучше выбрать более надёжные инструменты, как тот же restic или rsync.

▍ rsync

Rsync — старая и популярная программа для синхронизации файлов, которая также используется для резервного копирования.

Под Windows можно установить набор утилит Cygwin, куда входит и rsync.

Бинарники rsync под разные дистрибутивы Linux лежат здесь, исходники на Github.

На основе rsync сделано несколько удобных инструментов для резервного копирования, обычно это своего рода «оболочки», которые специализируются именно на бэкапах, такие как BackupPC.

▍ Выводы

В целом кажется, что для резервного копирования на VPS лучше всего подходит restic через REST-сервер. Его можно использовать не только для бэкапа отдельной системы, но и автоматизировать бэкап-хранилище для тысяч виртуальных машин. Он также поддерживает работу с облачными провайдерами.

Впрочем, здесь много нюансов, так что в разных ситуациях более удобными могут быть и другие инструменты. См. также сравнительное тестирование на Хабре Benji Backup, Borg Backup и Restic. Например, Borg Backup выигрывает по коэффициенту сжатия бэкапов, а Restic по скорости всех операций.

Telegram-канал со скидками, розыгрышами призов и новостями IT 💻