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

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

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

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

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

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

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

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

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

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

Приступим к установке резервного хранилища. В качестве инструмента существует много вариантов, в том числе BorgBackup ^[6], bup ^[7], CAFS ^[8], dedupfs ^[9], LBFS ^[10], restic ^[11], Tahoe-LAFS ^[12], tarsnap ^[13], Venti ^[14], zsync ^[15] и casync ^[16].

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

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

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

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

▍ Установка restic

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

$ apt-get install restic

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

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

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

scoop install restic

В терминологии restic хранилище бэкапов называется «репозиторий». Но перед тем как создать (инициализировать) репозиторий, нужно создать инстанс SFTP-сервера ^[22] или REST-сервера ^[23]. Второй вариант эффективнее, потому что коммуникация осуществляется по HTTP/HTTPS через REST API ^[24], а не по 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-сервера для резервного копирования (с автоматическим бэкапом) можно почитать в статье на Хабре ^[25].

Добавим, что REST-сервер можно запустить на VPS ^[3] в докер-контейнере. Возможно, это самый простой способ его использования, потому что он не требует отдельной установки зависимостей (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 ^[3].

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

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

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

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

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

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

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

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

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

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

▍ rsync

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

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

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

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

▍ Выводы

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

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