HestiaCP

Бэкапы Hestia Control Panel на Яндекс.Диск через Rclone и Restic

Опубликовано

admin

11.06.2026

Вкл. 10.06.2026

Бэкапы Hestia Control Panel 1.9.6 на Яндекс.Диск через Rclone и Restic

Вводная

В этой инструкции разберём настройку резервного копирования для Hestia Control Panel v1.9.6 на трёх серверах:

hs   — основной hosting-сервер
ns1  — DNS slave-сервер
ns2  — DNS slave-сервер

На всех трёх серверах есть пользователи Hestia, поэтому пользовательские бэкапы нужно делать не только на hs, но и на ns1 и ns2.

Задачи:

Не хранить тяжёлые пользовательские бэкапы локально на VPS.
Складывать пользовательские бэкапы в Яндекс.Диск.
Для каждого сервера сделать отдельную папку.
Отдельно сохранять ключи восстановления.
Отдельно сохранять системные конфиги панели и сервера.
Понять, что делать со старыми локальными бэкапами Hestia.

Итоговая структура на Яндекс.Диске:

backup/
  hs/
    users-restic/
    keys/
    system/
    legacy-local/

  ns1/
    users-restic/
    keys/
    system/
    legacy-local/

  ns2/
    users-restic/
    keys/
    system/
    legacy-local/

Расшифровка:

users-restic  — пользовательские бэкапы Hestia через Restic
keys          — ключи восстановления Restic и rclone.conf
system        — системные конфиги панели и сервера
legacy-local  — старые локальные tar-бэкапы, если их нужно временно перенести

Почему лучше использовать Restic, а не обычный tar-бэкап Hestia

Обычный бэкап Hestia через v-backup-user создаёт архив .tar локально, обычно в /backup. Только после этого архив можно отправлять на внешний storage.

Минус такого подхода: на VPS всё равно нужно свободное место под временный архив.

Restic работает иначе. Он делает инкрементальные бэкапы и хранит только изменения. Поэтому он лучше подходит для VPS, где мало свободного места.

Итоговая схема:

Hestia users → Restic → Rclone → Яндекс.Диск

Системные конфиги панели будем сохранять отдельно:

Hestia config / system config → tar.gz → Rclone → Яндекс.Диск

Минимальная политика хранения

Берём минимально нормальную схему:

7 daily
4 weekly
1 monthly

То есть:

7 ежедневных копий
4 еженедельные копии
1 ежемесячная копия

Три копии хранить не стоит. Если сайт был взломан неделю назад, база повредилась несколько дней назад или пользователь поздно заметил удалённую почту, трёх копий может не хватить.

Для системных архивов и ключей, так как они обычно маленькие, будем хранить последние 12 архивов.

Итого:

users-restic  — 7 daily, 4 weekly, 1 monthly
system        — 12 последних архивов
keys          — 12 последних архивов

Эта политика одинаковая для всех трёх серверов:

hs
ns1
ns2

Шаг 1. Подключаемся к серверу по SSH

Все команды выполняем от root.

sudo -i

Проверяем Hestia:

ls -la /usr/local/hestia

Можно также проверить версию:

cat /usr/local/hestia/conf/hestia.conf | grep VERSION

Шаг 2. Проверяем или устанавливаем Rclone

Rclone нужен для подключения к Яндекс.Диску.

Проверяем:

rclone version

Если Rclone не установлен:

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

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

rclone version

Эти действия нужно выполнить на каждом сервере:

hs
ns1
ns2

Шаг 3. Настраиваем Яндекс.Диск в Rclone

Настройку Яндекс.Диска нужно выполнить на каждом сервере отдельно:

hs
ns1
ns2

Все команды на сервере выполняем от root:

sudo -i

Запускаем настройку Rclone:

rclone config

Если Rclone ещё не настроен, появится меню:

No remotes found, make a new one?
n) New remote
s) Set configuration password
q) Quit config
n/s/q>

Выбираем новый remote:

Дальше вводим имя подключения. В инструкции будем использовать имя:

yadisk

Пример:

Enter name for new remote.
name> yadisk

Дальше Rclone покажет список хранилищ. Нужно выбрать:

Yandex Disk

Можно ввести не номер, а сразу тип:

Storage> yandex

Дальше появятся вопросы про OAuth Client ID и Secret. Их обычно оставляем пустыми:

Option client_id.
OAuth Client Id.
Leave blank normally.
Enter a value. Press Enter to leave empty.
client_id>

Нажимаем Enter.

Option client_secret.
OAuth Client Secret.
Leave blank normally.
Enter a value. Press Enter to leave empty.
client_secret>

Снова нажимаем Enter.

На вопрос про advanced config отвечаем n или просто нажимаем Enter:

Edit advanced config?
y) Yes
n) No (default)
y/n>

Дальше важный момент. Так как настройка идёт на VPS/server без браузера, на вопрос:

Use web browser to automatically authenticate rclone with remote?
y) Yes (default)
n) No
y/n>

нужно ответить:

После этого Rclone покажет примерно такой текст:

Option config_token.
For this to work, you will need rclone available on a machine that has
a web browser available.

Execute the following on the machine with the web browser:
        rclone authorize "yandex"

Then paste the result.
Enter a value.
config_token>

Это значит, что теперь нужно получить токен на своём компьютере, где есть браузер.

Получение config_token на Windows

На Windows нужно скачать Rclone с официального сайта:

https://rclone.org/downloads/

Скачиваем архив для Windows, распаковываем его, открываем папку с rclone.exe.

Дальше в этой папке открываем PowerShell или CMD.

В PowerShell выполняем:

.\rclone.exe authorize "yandex"

В CMD можно выполнить так же:

rclone.exe authorize "yandex"

После этого откроется браузер. Нужно войти в Яндекс и разрешить доступ Rclone к Яндекс.Диску.

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

{"access_token":"y0__XXXXXXXXXXXXXXXXXXXXXXXX","token_type":"bearer","refresh_token":"2:AAA:XXXXXXXXXXXXXXXXXXXXXXXX","expiry":"2027-06-10T23:51:29.438706926+03:00"}

Нужно скопировать всю строку целиком, включая фигурные скобки:

{ ... }

Получение config_token на Linux или macOS

На домашнем компьютере с Linux или macOS нужно установить Rclone.

Проверяем:

rclone version

Если Rclone установлен, запускаем:

rclone authorize "yandex"

Откроется браузер. Нужно войти в Яндекс и разрешить доступ.

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

{"access_token":"y0__XXXXXXXXXXXXXXXXXXXXXXXX","token_type":"bearer","refresh_token":"2:AAA:XXXXXXXXXXXXXXXXXXXXXXXX","expiry":"2027-06-10T23:51:29.438706926+03:00"}

Копируем всю JSON-строку целиком, включая { и }.

Вставляем config_token на сервере

Возвращаемся в SSH-консоль сервера, где Rclone ждёт ввод:

config_token>

Вставляем туда весь токен целиком:

{"access_token":"y0__XXXXXXXXXXXXXXXXXXXXXXXX","token_type":"bearer","refresh_token":"2:AAA:XXXXXXXXXXXXXXXXXXXXXXXX","expiry":"2027-06-10T23:51:29.438706926+03:00"}

Важно: в статье нельзя публиковать настоящий токен. В примере выше токен специально замаскирован.

После вставки Rclone покажет настройки remote и спросит, всё ли правильно:

y) Yes this is OK
e) Edit this remote
d) Delete this remote

Выбираем:

Затем выходим из настройки:

Проверяем подключение к Яндекс.Диску

На сервере выполняем:

rclone lsd yadisk:

Если команда показывает список папок Яндекс.Диска, значит подключение работает.

Можно сделать тестовую папку:

rclone mkdir yadisk:backup/test

Проверить:

rclone lsd yadisk:backup

Удалить тестовую папку:

rclone purge yadisk:backup/test

После этого можно создавать основную структуру папок для бэкапов.

Шаг 4. Создаём папки на Яндекс.Диске

На каждом сервере указываем свой SERVER_ID.

На сервере hs

SERVER_ID="hs"

rclone mkdir "yadisk:backup/${SERVER_ID}/users-restic"
rclone mkdir "yadisk:backup/${SERVER_ID}/keys"
rclone mkdir "yadisk:backup/${SERVER_ID}/system"
rclone mkdir "yadisk:backup/${SERVER_ID}/legacy-local"

rclone lsd "yadisk:backup/${SERVER_ID}"

На сервере ns1

SERVER_ID="ns1"

rclone mkdir "yadisk:backup/${SERVER_ID}/users-restic"
rclone mkdir "yadisk:backup/${SERVER_ID}/keys"
rclone mkdir "yadisk:backup/${SERVER_ID}/system"
rclone mkdir "yadisk:backup/${SERVER_ID}/legacy-local"

rclone lsd "yadisk:backup/${SERVER_ID}"

На сервере ns2

SERVER_ID="ns2"

rclone mkdir "yadisk:backup/${SERVER_ID}/users-restic"
rclone mkdir "yadisk:backup/${SERVER_ID}/keys"
rclone mkdir "yadisk:backup/${SERVER_ID}/system"
rclone mkdir "yadisk:backup/${SERVER_ID}/legacy-local"

rclone lsd "yadisk:backup/${SERVER_ID}"

Шаг 5. Тестируем запись в Яндекс.Диск

На каждом сервере выполняем тест.

Для hs:

SERVER_ID="hs"

Для ns1:

SERVER_ID="ns1"

Для ns2:

SERVER_ID="ns2"

Создаём тестовый файл:

echo "test from $(hostname) at $(date)" > /tmp/rclone-test.txt

Копируем его на Яндекс.Диск:

rclone copy /tmp/rclone-test.txt "yadisk:backup/${SERVER_ID}/system/"

Проверяем:

rclone lsf "yadisk:backup/${SERVER_ID}/system/"

Удаляем тестовый файл с Яндекс.Диска:

rclone deletefile "yadisk:backup/${SERVER_ID}/system/rclone-test.txt"

Удаляем локальный тестовый файл:

rm -f /tmp/rclone-test.txt

Шаг 6. Настраиваем Restic-бэкапы пользователей Hestia

Этот шаг выполняется на каждом сервере, потому что пользователи есть на всех трёх серверах.

На сервере hs

v-add-backup-host-restic 'rclone:yadisk:/backup/hs/users-restic/' '12' '7' '4' '1' '-1'

На сервере ns1

v-add-backup-host-restic 'rclone:yadisk:/backup/ns1/users-restic/' '12' '7' '4' '1' '-1'

На сервере ns2

v-add-backup-host-restic 'rclone:yadisk:/backup/ns2/users-restic/' '12' '7' '4' '1' '-1'

Что означают параметры:

rclone:yadisk:/backup/SERVER/users-restic/  — путь к Restic repository на Яндекс.Диске
12                                         — минимальное количество snapshots
7                                          — daily snapshots
4                                          — weekly snapshots
1                                          — monthly snapshots
-1                                         — yearly snapshots не храним

Шаг 7. Включаем incremental backups в пакетах Hestia

После настройки Restic repository нужно включить incremental backups для пользователей Hestia.

Важно понимать: глобальная настройка Restic в Hestia ещё не означает, что бэкапы пользователей начнут создаваться. У каждого пользователя должен быть включён параметр:

BACKUPS_INCREMENTAL='yes'

Обычно это включается через пакет пользователя.

В панели Hestia:

Packages → нужный пакет → Edit → Incremental Backups → Enable

Если на сервере несколько пакетов, включите incremental backups в каждом нужном пакете.

Например, если пользователи находятся в пакете default, включаем:

Packages → default → Edit → Incremental Backups → Enable → Save

Это нужно сделать на всех серверах:

hs
ns1
ns2

Проверяем, у каких пользователей включены incremental backups

После включения через панель проверьте пользователей через SSH:

for u in $(v-list-sys-users plain); do
  echo "===== $u ====="
  grep -E "^(PACKAGE|BACKUPS|BACKUPS_INCREMENTAL|SUSPENDED)=" /usr/local/hestia/data/users/$u/user.conf
done

У пользователей, которых нужно бэкапить через Restic, должно быть:

BACKUPS_INCREMENTAL='yes'
SUSPENDED='no'

Если у пользователя осталось:

BACKUPS_INCREMENTAL='no'

то Restic-бэкап для него не будет создаваться.

Что делать, если пользователь находится в пакете `system`

Иногда в Hestia есть пользователи, которые находятся в пакете:

PACKAGE='system'

С такими пользователями нужно быть осторожнее. Не стоит сразу переносить их в обычный пакет default, потому что пакет может влиять на лимиты, доступные функции, shell, DNS, mail, web, database и другие настройки пользователя.

Сначала проверьте, какие настройки у пакетов отличаются:

cat /usr/local/hestia/data/packages/system.pkg
cat /usr/local/hestia/data/packages/default.pkg

Если вы точно понимаете, что пользователь не служебный и его можно перевести в другой пакет, можно назначить ему пакет, где incremental backups уже включены.

Но более безопасный вариант — оставить пользователя в пакете system и включить incremental backup только для него вручную.

Пример для пользователя hs-ns:

cp /usr/local/hestia/data/users/hs-ns/user.conf \
   /usr/local/hestia/data/users/hs-ns/user.conf.bak.$(date +%F_%H-%M)

sed -i "s/BACKUPS_INCREMENTAL='no'/BACKUPS_INCREMENTAL='yes'/" \
  /usr/local/hestia/data/users/hs-ns/user.conf

grep BACKUPS_INCREMENTAL /usr/local/hestia/data/users/hs-ns/user.conf

Должно получиться:

BACKUPS_INCREMENTAL='yes'

Если таких пользователей несколько, сначала найдите их:

for u in $(v-list-sys-users plain); do
  grep -q "PACKAGE='system'" /usr/local/hestia/data/users/$u/user.conf && echo "$u"
done

Потом включайте BACKUPS_INCREMENTAL='yes' только тем пользователям, которых действительно нужно бэкапить.

Запускаем тестовый backup одного пользователя

После включения incremental backups запустите бэкап одного пользователя вручную:

v-backup-user-restic USERNAME yes

Пример:

v-backup-user-restic hs-ns yes

Проверьте лог:

tail -n 200 /usr/local/hestia/log/backup.log

Проверьте, появился ли snapshot:

v-list-user-backups-restic USERNAME

Пример:

v-list-user-backups-restic hs-ns

Запускаем backup всех пользователей

Когда проверили, что у нужных пользователей стоит:

BACKUPS_INCREMENTAL='yes'

запускаем общий backup:

v-backup-users-restic

Проверяем лог:

tail -n 200 /usr/local/hestia/log/backup.log

И проверяем Яндекс.Диск:

rclone lsd yadisk:backup/hs/users-restic

Для ns1:

rclone lsd yadisk:backup/ns1/users-restic

Для ns2:

rclone lsd yadisk:backup/ns2/users-restic

Если всё настроено правильно, внутри users-restic появятся отдельные папки пользователей.

Шаг 8. Запускаем первый пользовательский backup

На каждом сервере:

v-backup-users-restic

Или для одного пользователя:

v-backup-user-restic USERNAME

Пример:

v-backup-user-restic admin

Первый запуск может идти долго, потому что создаётся первый полный snapshot. Следующие запуски будут быстрее, так как Restic будет сохранять только изменения.

Шаг 9. Проверяем, что Restic-бэкапы появились на Яндекс.Диске

На hs

rclone lsf yadisk:backup/hs/users-restic/

На ns1

rclone lsf yadisk:backup/ns1/users-restic/

На ns2

rclone lsf yadisk:backup/ns2/users-restic/

Внутри Restic repository обычно будут папки:

config
data/
index/
keys/
locks/
snapshots/

Это нормально. Эти файлы нельзя редактировать вручную.

Проверить бэкапы конкретного пользователя:

v-list-user-backups-restic USERNAME

Пример:

v-list-user-backups-restic admin

Шаг 10. Сохраняем ключи восстановления

Это самый важный шаг.

Restic-бэкапы зашифрованы. Для восстановления нужны ключи. Hestia хранит ключ пользователя в файле:

/usr/local/hestia/data/users/USERNAME/restic.conf

Если потерять этот файл, восстановить данные из Restic-бэкапа будет невозможно.

Нужно отдельно сохранять:

/usr/local/hestia/data/users/*/restic.conf
/usr/local/hestia/conf/restic.conf
/root/.config/rclone/rclone.conf

Создаём скрипт:

nano /root/hestia-backup-keys.sh

Вставляем:

#!/bin/bash
set -euo pipefail

SERVER_ID="hs"
REMOTE_BASE="yadisk:backup/${SERVER_ID}/keys"
KEEP=12

DATE="$(date +%F_%H-%M-%S)"
TMP="$(mktemp -d)"
ARCHIVE="/root/${SERVER_ID}-keys-${DATE}.tgz"

mkdir -p "$TMP/keys"

if [ -f /root/.config/rclone/rclone.conf ]; then
  cp --parents /root/.config/rclone/rclone.conf "$TMP/keys/"
fi

if [ -f /usr/local/hestia/conf/restic.conf ]; then
  cp --parents /usr/local/hestia/conf/restic.conf "$TMP/keys/"
fi

if [ -d /usr/local/hestia/data/users ]; then
  find /usr/local/hestia/data/users -type f -name "restic.conf" -exec cp --parents {} "$TMP/keys/" \;
fi

tar -C "$TMP/keys" -czf "$ARCHIVE" .
chmod 600 "$ARCHIVE"

rclone mkdir "$REMOTE_BASE"
rclone copy "$ARCHIVE" "$REMOTE_BASE/"

prune_remote() {
  local remote="$1"
  local keep="$2"

  mapfile -t files < <(rclone lsf --files-only "$remote" | sort)
  local count="${#files[@]}"

  if (( count > keep )); then
    for ((i=0; i<count-keep; i++)); do
      rclone deletefile "${remote}/${files[$i]}" || true
    done
  fi
}

prune_remote "$REMOTE_BASE" "$KEEP"

rm -rf "$TMP"
rm -f "$ARCHIVE"

Важно: на каждом сервере нужно поменять SERVER_ID.

Для hs:

SERVER_ID="hs"

Для ns1:

SERVER_ID="ns1"

Для ns2:

SERVER_ID="ns2"

Выдаём права:

chmod 700 /root/hestia-backup-keys.sh

Запускаем:

/root/hestia-backup-keys.sh

Проверяем.

Для hs:

rclone lsf yadisk:backup/hs/keys/

Для ns1:

rclone lsf yadisk:backup/ns1/keys/

Для ns2:

rclone lsf yadisk:backup/ns2/keys/

Рекомендация: папку keys лучше дополнительно скачать себе на компьютер или продублировать в другое облако.

Шаг 11. Делаем системный бэкап панели и сервера

Пользовательские Restic-бэкапы сохраняют данные пользователей. Но отдельно полезно сохранять системные настройки панели и сервера.

Что сохраняем:

/etc/hestiacp
/usr/local/hestia/conf
/usr/local/hestia/data
/usr/local/hestia/ssl
/root/.config/rclone/rclone.conf
/etc/ssh
/etc/fail2ban
/etc/bind
/etc/nginx
/etc/apache2
/etc/php
/etc/mysql
/etc/exim4
/etc/dovecot

Не все папки будут существовать на каждом сервере. Скрипт будет архивировать только то, что есть.

Создаём скрипт:

nano /root/hestia-backup-system.sh

Вставляем:

#!/bin/bash
set -euo pipefail

SERVER_ID="hs"
REMOTE_BASE="yadisk:backup/${SERVER_ID}/system"
KEEP=12

DATE="$(date +%F_%H-%M-%S)"
ARCHIVE="/root/${SERVER_ID}-system-${DATE}.tgz"

PATHS=(
  /etc/hestiacp
  /usr/local/hestia/conf
  /usr/local/hestia/data
  /usr/local/hestia/ssl
  /root/.config/rclone/rclone.conf
  /etc/ssh
  /etc/fail2ban
  /etc/bind
  /etc/nginx
  /etc/apache2
  /etc/php
  /etc/mysql
  /etc/exim4
  /etc/dovecot
)

EXISTING=()

for p in "${PATHS[@]}"; do
  if [ -e "$p" ]; then
    EXISTING+=("$p")
  fi
done

if [ "${#EXISTING[@]}" -eq 0 ]; then
  echo "Nothing to backup"
  exit 1
fi

tar --ignore-failed-read -czf "$ARCHIVE" "${EXISTING[@]}"
chmod 600 "$ARCHIVE"

rclone mkdir "$REMOTE_BASE"
rclone copy "$ARCHIVE" "$REMOTE_BASE/"

prune_remote() {
  local remote="$1"
  local keep="$2"

  mapfile -t files < <(rclone lsf --files-only "$remote" | sort)
  local count="${#files[@]}"

  if (( count > keep )); then
    for ((i=0; i<count-keep; i++)); do
      rclone deletefile "${remote}/${files[$i]}" || true
    done
  fi
}

prune_remote "$REMOTE_BASE" "$KEEP"

rm -f "$ARCHIVE"

На каждом сервере меняем SERVER_ID.

Для hs:

SERVER_ID="hs"

Для ns1:

SERVER_ID="ns1"

Для ns2:

SERVER_ID="ns2"

Выдаём права:

chmod 700 /root/hestia-backup-system.sh

Запускаем:

/root/hestia-backup-system.sh

Проверяем.

Для hs:

rclone lsf yadisk:backup/hs/system/

Для ns1:

rclone lsf yadisk:backup/ns1/system/

Для ns2:

rclone lsf yadisk:backup/ns2/system/

Шаг 12. Добавляем cron для автоматического запуска

Cron на всех трёх серверах будет одинаковый по логике:

пользовательские Restic-бэкапы
ключи восстановления
системные конфиги

Создаём cron-файл:

nano /etc/cron.d/hestia-yadisk-backups

Вставляем:

SHELL=/bin/bash
PATH=/usr/local/hestia/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 2 * * * root /usr/local/hestia/bin/v-backup-users-restic >/var/log/hestia-restic-backup.log 2>&1
45 3 * * * root /root/hestia-backup-keys.sh >/var/log/hestia-keys-backup.log 2>&1
15 4 * * * root /root/hestia-backup-system.sh >/var/log/hestia-system-backup.log 2>&1

Что это значит:

02:15 — пользовательские бэкапы Restic
03:45 — бэкап ключей восстановления
04:15 — системный бэкап панели и сервера

Этот cron нужно добавить на каждый сервер:

hs
ns1
ns2

Проверяем файл:

cat /etc/cron.d/hestia-yadisk-backups

Шаг 13. Что делать со старыми локальными бэкапами Hestia

Локальные бэкапы Hestia обычно лежат в:

/backup

Сначала смотрим, сколько они занимают:

du -sh /backup

Смотрим список архивов:

find /backup -maxdepth 1 -type f -name "*.tar" -printf "%TY-%Tm-%Td %TH:%TM %s %p\n" | sort

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

hs
ns1
ns2

Важное правило перед удалением

Не удаляйте локальные бэкапы, пока не проверили, что:

Rclone подключен к Яндекс.Диску.
Restic-бэкап успешно создался.
Ключи восстановления сохранены в папку keys.
Системный бэкап сохранён в папку system.
Команда v-list-user-backups-restic USERNAME показывает snapshots.
Желательно — протестировано восстановление хотя бы одного тестового пользователя.

Вариант 1. Перенести старые локальные tar-бэкапы в Яндекс.Диск

Это самый безопасный вариант, если нужно освободить место на VPS, но старые архивы пока удалять не хочется.

На каждом сервере задаём свой SERVER_ID.

Для hs:

SERVER_ID="hs"

Для ns1:

SERVER_ID="ns1"

Для ns2:

SERVER_ID="ns2"

Создаём папку:

rclone mkdir "yadisk:backup/${SERVER_ID}/legacy-local"

Сначала делаем dry-run:

rclone move /backup "yadisk:backup/${SERVER_ID}/legacy-local" \
  --include "*.tar" \
  --include "*.log" \
  --dry-run

Если список выглядит правильно, запускаем реально:

rclone move /backup "yadisk:backup/${SERVER_ID}/legacy-local" \
  --include "*.tar" \
  --include "*.log" \
  --progress

Проверяем:

rclone lsf "yadisk:backup/${SERVER_ID}/legacy-local/"

Проверяем место на VPS:

du -sh /backup
df -h

Вариант 2. Удалить старые локальные tar-бэкапы

Удалять стоит только после проверки remote-бэкапов.

Сначала посмотреть:

find /backup -maxdepth 1 -type f -name "*.tar" -ls

Удалить tar-архивы:

find /backup -maxdepth 1 -type f -name "*.tar" -delete

Удалить старые backup-логи, если они не нужны:

find /backup -maxdepth 1 -type f -name "*.log" -delete

Проверить место:

df -h

Вариант 3. Оставить один последний локальный backup

Если на VPS есть немного места, можно оставить один последний локальный tar-бэкап как аварийную копию, а всё старое перенести или удалить.

Список архивов:

ls -1t /backup/*.tar 2>/dev/null

Удалить все, кроме самого нового:

ls -1t /backup/*.tar 2>/dev/null | tail -n +2 | xargs -r rm -f

На практике это хороший переходный вариант:

Restic уже работает
старые tar-бэкапы уже не копятся
один последний локальный tar ещё есть на всякий случай

Шаг 14. Как настроить локальные бэкапы после перехода на Restic

После проверки Restic можно уменьшить обычные локальные backups в пакетах Hestia.

Рекомендованный минимум:

Пользовательские данные — Restic на Яндекс.Диск
Локальные tar-бэкапы — 0 или 1 последний архив
Системные конфиги — отдельный system backup на Яндекс.Диск
Ключи — отдельный keys backup на Яндекс.Диск и ещё одна копия вне сервера

В панели Hestia:

Packages → нужный пакет → Edit

Для обычных backup copies можно поставить:

1 — на время проверки
0 — после полной проверки Restic

Практический порядок:

1. Настроить Rclone.
2. Настроить Restic.
3. Сделать первый Restic-бэкап.
4. Сохранить ключи.
5. Сделать system backup.
6. Проверить snapshots.
7. Оставить обычные локальные backups = 1.
8. Через несколько дней, если всё работает, поставить обычные локальные backups = 0.
9. Очистить или перенести старые файлы из /backup.

Важно: не отключайте все бэкапы сразу до проверки восстановления.

Шаг 15. Проверка восстановления

Бэкап без проверки восстановления — это не полноценный бэкап.

Проверить список Restic-бэкапов пользователя:

v-list-user-backups-restic USERNAME

Пример:

v-list-user-backups-restic admin

Восстановление пользователя из обычного tar-бэкапа:

v-restore-user USERNAME BACKUP_FILE.tar

Пример:

v-restore-user admin admin.2026-06-10_02-15-01.tar

Восстановление пользователя из Restic:

v-restore-user-full-restic USERNAME SNAPSHOT KEY

Где:

USERNAME  — имя пользователя Hestia
SNAPSHOT  — ID snapshot
KEY       — ключ восстановления из restic.conf

Также есть частичное восстановление:

v-restore-user-restic USERNAME SNAPSHOT

Перед реальной аварией желательно протестировать восстановление на отдельном тестовом сервере или хотя бы на тестовом пользователе.

Шаг 16. Проверка логов

Проверить логи:

cat /var/log/hestia-restic-backup.log
cat /var/log/hestia-keys-backup.log
cat /var/log/hestia-system-backup.log

Проверить cron:

grep CRON /var/log/syslog | tail -n 50

Если используется systemd:

journalctl -u cron --since today

Проверить место на диске:

df -h
du -sh /backup

Проверить данные на Яндекс.Диске:

rclone lsd yadisk:backup
rclone lsd yadisk:backup/hs
rclone lsd yadisk:backup/ns1
rclone lsd yadisk:backup/ns2

Проверить пользовательские Restic-бэкапы:

rclone lsf yadisk:backup/hs/users-restic/
rclone lsf yadisk:backup/ns1/users-restic/
rclone lsf yadisk:backup/ns2/users-restic/

Проверить ключи:

rclone lsf yadisk:backup/hs/keys/
rclone lsf yadisk:backup/ns1/keys/
rclone lsf yadisk:backup/ns2/keys/

Проверить системные архивы:

rclone lsf yadisk:backup/hs/system/
rclone lsf yadisk:backup/ns1/system/
rclone lsf yadisk:backup/ns2/system/

Итоговая схема

После настройки получится такая структура:

backup/
  hs/
    users-restic/
    keys/
    system/
    legacy-local/

  ns1/
    users-restic/
    keys/
    system/
    legacy-local/

  ns2/
    users-restic/
    keys/
    system/
    legacy-local/

На каждом сервере выполняются три задачи:

1. v-backup-users-restic
2. hestia-backup-keys.sh
3. hestia-backup-system.sh

Минимальная политика хранения:

Пользовательские Restic-бэкапы:
  7 daily
  4 weekly
  1 monthly

System archives:
  12 последних архивов

Keys archives:
  12 последних архивов

Локальные бэкапы:

На этапе настройки:
  оставить 1 последний локальный tar-бэкап

После проверки Restic:
  перенести старые tar-бэкапы в Яндекс.Диск или удалить

На постоянной основе:
  обычные локальные backups = 0 или 1
  основной backup = Restic на Яндекс.Диск

Самое важное:

Не потерять restic.conf.
Без ключа восстановления Restic-бэкапы невозможно восстановить.

Поэтому папки:

backup/hs/keys/
backup/ns1/keys/
backup/ns2/keys/

лучше дополнительно скачать себе на компьютер или продублировать в другое облако.

Blog

Бэкапы Hestia Control Panel 1.9.6 на Яндекс.Диск через Rclone и Restic

Вводная

Почему лучше использовать Restic, а не обычный tar-бэкап Hestia

Минимальная политика хранения

Шаг 1. Подключаемся к серверу по SSH

Шаг 2. Проверяем или устанавливаем Rclone

Шаг 3. Настраиваем Яндекс.Диск в Rclone

Получение config_token на Windows

Получение config_token на Linux или macOS

Вставляем config_token на сервере

Проверяем подключение к Яндекс.Диску

Шаг 4. Создаём папки на Яндекс.Диске

На сервере hs

На сервере ns1

На сервере ns2

Шаг 5. Тестируем запись в Яндекс.Диск

Шаг 6. Настраиваем Restic-бэкапы пользователей Hestia

На сервере hs

На сервере ns1

На сервере ns2

Шаг 7. Включаем incremental backups в пакетах Hestia

Проверяем, у каких пользователей включены incremental backups

Что делать, если пользователь находится в пакете system

Запускаем тестовый backup одного пользователя

Запускаем backup всех пользователей

Шаг 8. Запускаем первый пользовательский backup

Шаг 9. Проверяем, что Restic-бэкапы появились на Яндекс.Диске

На hs

На ns1

На ns2

Шаг 10. Сохраняем ключи восстановления

Шаг 11. Делаем системный бэкап панели и сервера

Шаг 12. Добавляем cron для автоматического запуска

Шаг 13. Что делать со старыми локальными бэкапами Hestia

Важное правило перед удалением

Вариант 1. Перенести старые локальные tar-бэкапы в Яндекс.Диск

Вариант 2. Удалить старые локальные tar-бэкапы

Вариант 3. Оставить один последний локальный backup

Шаг 14. Как настроить локальные бэкапы после перехода на Restic

Шаг 15. Проверка восстановления

Шаг 16. Проверка логов

Итоговая схема

Добавить комментарий Отменить ответ

Что делать, если пользователь находится в пакете `system`