Proxmox Backup Server без 24/7: включение и сон по расписанию

[keeper]

Решил вынести Proxmox Backup Server на отдельную машину. Поскольку держать её включённой 24/7 не вижу смысла, реализовал у себя автоматическое включение и перевод сервера в сон по расписанию (cron) для экономии электроэнергии.

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

Настройка Proxmox Backup Server

Включение Wake-on-LAN в BIOS

Первым делом необходимо настроить BIOS. Он продолжает работать даже при выключенном компьютере (пока тот подключён к сети электропитания), в отличие от операционной системы.

1. Зайдите в BIOS, используя клавишу, подходящую для вашей материнской платы (чаще всего Del, Esc, F2, F12).

2. Найдите параметр, связанный с Wake-on-LAN. Обычно он расположен во вкладке Power, Power Management или Electropower.

3. Установите значение Enabled (или Automatic).

4. Сохраните настройки и перезагрузитесь (обычно клавиша F10).

Настройка WoL в системе PBS

Далее настраиваем сам Proxmox Backup Server через терминал.

Устанавливаем утилиту:

sudo apt install ethtool -y

Определяем сетевой интерфейс:

ip addr

Найдите интерфейс с локальным IP-адресом (например, 192.168.x.x или 10.10.x.x) и запишите:

• имя сетевого устройства (например, eno1)

• MAC-адрес

Проверяем поддержку Wake-on-LAN:

sudo ethtool eno1

Найдите строку Supports Wake-on. Если в ней присутствует буква g, значит WoL поддерживается.

Включаем WoL:

sudo ethtool -s eno1 wol g

Чтобы WoL включался автоматически при старте системы, отредактируйте конфигурацию сети:

sudo nano /etc/network/interfaces

В конец блока интерфейса (iface eth0 inet или аналогичного) добавьте:

post-up /usr/sbin/ethtool -s eno1 wol g

Сохранитесь и выйдите из редактора.

Для принудительного перевода сервера в спящий режим используйте:

systemctl suspend

Настройка Proxmox Virtual Environment

На сервере с Proxmox VE устанавливаем утилиту для пробуждения PBS:

apt install wakeonlan

Пробуждаем сервер с бэкапами командой:

wakeonlan xx:xx:xx:xx:xx:xx

(вместо x подставьте MAC-адрес PBS)

Если сервер включился — поздравляю, WoL работает корректно.

Настройка cron

На Proxmox Backup Server

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

00 12 * * * systemctl suspend

Каждый день в 12:00 сервер будет уходить в спящий режим (если он включён).

На Proxmox VE

Добавляем задание для пробуждения PBS:

45 23 * * 7 wakeonlan xx:xx:xx:xx:xx:xx

Команда будет пробуждать сервер каждое воскресенье в 23:45.

Все бэкапы и обслуживание настраиваем в интервале с 00:00 до 12:00.

У меня уже несколько бэкапов работают по такой схеме — полёт нормальный.

Не претендую на истину в последней инстанции, но для новичков, думаю, подойдёт.
Если у кого есть идеи или улучшения — пишите, будет интересно обсудить.

[KRom]

В целом, рабочий вариант, от меня сердечко.
Но я бы добавил от себя несколько НО

1. С китайскими миниками все сложно, но в нормальных BIOS есть функционал включения и выключения по расписанию, можно начать с поиска такой опции, а если не находится, то идти в сторону wake on lan
2. Выкючение я бы не делал прям так жестко, можно попробовать по таймеру периодически проверять наличие активных сессий и выключать только при отсутствии оных
3. Я вынес PBS в виртуалку (а потом в LXC контейнер) на самом NAS, чтобы он зря не работал 24/7, бэкапирование идет не только в PBS, поэтому сервер работает уже не просто так
4. Я бы рассматривал подобный режим работы только для холодных бэкапов, я пока только двигаюсь в этом направлении, для рабочей версии PBS сомнительно, если честно.
5. Спящий режим в течение 6.5 дней подряд опасно в пане того, что при отсутствии ИБП, да и с ним тоже, полное выключение с физическим отключением от системы питания даст выше надежность, нежели режим, в котором в оперативке хранится текущее состояние и при потере питания ОС спасибо не скажет, а для выключения (в случае отключения питания) сервер надо сначала разбудить, а потом отправить в полноценное завершение работы

Вот мой суточный график нагрузки пула с бэкапами (но у меня недавно было несколько эпапов оптимизации: последний + недавно произошла полная очистка бэкапов PBS, поэтому их у меня не так много сейчас и нагрузка тоже не высокая), несколько месяцев назад этабы были значительно шире, вплоть до пересечения (когда следующий этап начинается до того, как закончился предыдущий)

И более детально:

Тут видно, что есть относительно спокойные участки, а именно с 12 до 18 и после 18 до 00

• В 00:00 и 02:00 запланированы бэкапы приожений и конфигураций
• В 4:00 бэкапируются виртуалки и контейнеры
• В 6:00 запускается сборщик мусора
• В 9:00 запускается проверка
• Каждые 6 часов запускается бэкапирование компьютера (00, 06, 12, 18 часов) (добавил смещение 30 минут)

В целом, если раз в неделю деать резервные копии, то нет смысла 6.5 дней простаивать, но у меня максимальное время между резервными копиями составляет 24 часа, минимальное 6 часов и я планирую сократить время до 3х часов для некоторых типов резервных копий.
Если полное копирование виртуалки раз в сутки в целом, является промышленным стандартом, то в БД активно именяющимися файлами это время обычно сокращается, поэтому сами сервисы думаю бэкапировать раз в 12 часов, а рабочий компьютер сократить до 3 часов, еще больше приблизив к подходу TimeMachine.

Может у Вас неделя и не играет роли, а у меня было такое, что приходилось восстанавливать файлы, измененные несколько часов назад, а с почтовым сервером не успел сдерать РК и пришлось настраивать с нуля. Даже в рамках хомлабы мне было бы неприятно настраивать с понедельника по пятницу какой-то сервис или виртуалку, а потом в субботу/воскресенье потерять все изменения за неделю.

Как уже писал в начале, я рассматриваю вариант поднятия холодного бэкапа из блока 1 правила 3-2-1 с еженедельным сбросом туда текущего состояния без исторических данных (либо с историческими, но прямо древних-древних) и не с спящим режимом

[ala-a-din]

У меня возникает как я считаю вполне логичные вопросы:

• зачем нужен PBS если бекапы все равно создаются силами PVE? Просто чтобы скопировать в него?
• Какова надежность PBS если он крутится в том же PVE? А если еще и к PBS прокинут через костыли один единственный диск на котором все, включая бекапы то чему будет равна надежность этой системы бекапирования? Я думаю нулевой.
• Чем не устраивает сообщество бекапы которые так же создаются в PVE но складировать их на отдельный диск?
• Или так - лижбы было? Или я чего-то не понимаю или я что что-то не так делаю, когда подключил в PVE отдельный диск на который PVE по расписанию или вручную сохраняет нужные мне бекапы?

[KRom]

@ala-a-din

зачем нужен PBS если бекапы все равно создаются силами PVE? Просто чтобы скопировать в него?

PBS это не бэкапилка, а продвинутое сетевое хранилище

@ala-a-din

Какова надежность PBS если он крутится в том же PVE? А если еще и к PBS прокинут через костыли один единственный диск на котором все, включая бекапы то чему будет равна надежность этой системы бекапирования? Я думаю нулевой.

Есть такой момент, надежность не очень высокая, но никто не запрещает бэкапировать и резервировать сам PBS, вообще установка его внутрь PVE это от бедности, а не архитектурное решение, изначально Proxmox рекомендуют его ставит на голоже железо

@ala-a-din

Чем не устраивает сообщество бекапы которые так же создаются в PVE но складировать их на отдельный диск?

Всем, особенно если PVE используется в формате кластера, а не единичного инстанса

@ala-a-din

Или так - лижбы было? Или я чего-то не понимаю или я что что-то не так делаю, когда подключил в PVE отдельный диск на который PVE по расписанию или вручную сохраняет нужные мне бекапы?

Ну и далее развернуто по функционалу PBS

1. Он хранит резервные копии не в формате единого файла, а в виде кучи маленьких файлов, за счет этого реализуется самостоятельная дедубликация
   У меня сейчас добавились новые хосты и фактор дедубликации упал с 18 до 16, думаю, что через недели 2 опять вернется к исходному значению
   
   
2. Резервные копии LXC контейнеров можно просматривать прямо в веб интерфейсе, можно скачать отдельный файл или папку оттуда
   
   
3. Имеется ролевая модель
   
   
4. Можно к снимку подгрузить доп. файлы, например, лог бэкапирования или его конфиг
   
   
5. Можно примонтировать резервную копию для легкого доступа к файлам

root@krom-pc:~# mkdir snapshot
root@krom-pc:~# proxmox-backup-client  mount --repository $PBS_REPOSITORY --ns=hosts host/krom-pc/2026-01-25T15:30:01Z etc.mpxar.didx snapshot
FUSE library version: 3.17.2
root@krom-pc:~# ls snapshot
 GNUstep                         conky                  emacs           hp                            libvirt                             nfs.conf         pulse              shadowsocks-libev       tmpfiles.d
 ImageMagick-6                   console-setup          environment     idmapd.conf                   lighttpd                            nfs.conf.d       python3            shells                  ts.conf
 ImageMagick-7                   containerd             environment.d   ifplugd                       locale.conf                         nftables.conf    python3.11         signon-ui               ubuntu-advantage

6. PBS поддерживает несколько типов проверок для инкрементальных бэкапов
   Тут мы видим, что метаданные по бэкапу весят 218МБ, а итоговый виртуальный снимок почти 72 ГБ, при этом, у нас поверх еще и дедупликация накладывается
   Клиент скачивает данные по предыдущему бэкапу и сравнивает их с текущим состоянием, отправяет только измененные файлы
   
   
7. PBS не просто хранит резервные копии, но и еще их верифицирует по расписанию
   тут у нас создана была новая резервная копия, которая еще не была проверена + если после последней верификации прошло больше месяца, то копия еще раз верифицируется
   
   
8. PBS ведет статистику использования места, задач и т.д. пытается предсказать время, когда закончится место при текущем прогрессе использования
   
   
9. В PBS есть push/pull задачи для синхронизации хранилища, например, можно пересылать резервные копии в другой город для сохранности
   
   
10. Можно использовать s3 в качестве хранилища
    
    
11. Имеется централизованное управление количеством резервных копий вне зависимости от источника
    
    
    
    
    
12. Имеется proxmox-backup-client, который позволяет бэкапировать не только виртуалки, но и просто файлы на линукс машинах (у меня комп бэкапируется так каждые 6 часов)
    Лог бэкапа домашнего компа

Starting backup: [hosts]:host/krom-pc/2026-03-11T09:30:02Z    
Client name: krom-pc    
Starting backup protocol: Wed Mar 11 12:30:02 2026    
Downloading previous manifest (Wed Mar 11 06:30:01 2026)    
Upload directory '/home/krom' to 'client@pbs@10.110.10.130:8007:backups' as home.mpxar.didx    
Using previous index as metadata reference for 'home.mpxar.didx'    
Change detection summary:
 - 1186626 total files (1532 hardlinks)
 - 1042476 unchanged, reusable files with 65.751 GiB data
 - 142618 changed or non-reusable files with 5.163 GiB data
 - 958.058 MiB padding in 2336 partially reused chunks
home.ppxar: reused 66.687 GiB from previous snapshot for unchanged files (32365 chunks)
home.ppxar: had to backup 1.696 GiB of 71.85 GiB (compressed 952.553 MiB) in 36.04 s (average 48.176 MiB/s)
home.ppxar: backup was done incrementally, reused 70.154 GiB (97.6%)
home.mpxar: had to backup 216.133 MiB of 217.965 MiB (compressed 46.507 MiB) in 36.11 s (average 5.986 MiB/s)
home.mpxar: backup was done incrementally, reused 1.832 MiB (0.8%)
Upload directory '/etc' to 'client@pbs@10.110.10.130:8007:backups' as etc.mpxar.didx    
Using previous index as metadata reference for 'etc.mpxar.didx'    
Change detection summary:
 - 2379 total files (0 hardlinks)
 - 1091 unchanged, reusable files with 3.661 MiB data
 - 1288 changed or non-reusable files with 4.309 MiB data
 - 234.937 KiB padding in 3 partially reused chunks
etc.mpxar: had to backup 629.484 KiB of 629.484 KiB (compressed 131.071 KiB) in 0.09 s (average 6.574 MiB/s)
etc.ppxar: reused 3.89 MiB from previous snapshot for unchanged files (4 chunks)
etc.ppxar: had to backup 3.309 MiB of 8.199 MiB (compressed 880.481 KiB) in 0.10 s (average 32.575 MiB/s)
etc.ppxar: backup was done incrementally, reused 4.89 MiB (59.6%)
Upload config file '/root/pbs_backup_settings' to 'client@pbs@10.110.10.130:8007:backups' as pbs_backup.conf.blob    
Duration: 36.53s    
End Time: Wed Mar 11 12:30:38 2026    

13. Можно настраивать ограничения по сетевому трафику (например, снижать интенсивность определенных хостов или клиентов)
    
    
14. Может работать со съемными дисками
    
    
15. Показывает самые долгие задачи за последние 30 дней и те, которые выполняются в данный момент времени
    
    

Итого

Даже на 1 ноде есть выигрыш за счет дедубликации, при использовании кластера или множества клиентов имеем существенный профит

Я отказался в итоге от borg bckup полностью и у меня сейчас PBS используется для бэкапирования

1. виртуалок и контейнеров PVE
2. данных docker-compose сервисов
3. конфигов самих PVE нод
4. одноплатников (недавно очень сильно помогло, когда после обновления ОС одноплатник перестал загружаться)
5. домашнего комьютера в режиме почти time-machine

[ala-a-din]

А яблоко он сможет бекапить?

У меня просто одна нода: 5 LXC и 2 VM, и вот надо оно мне это, вроде ж не дата цент у меня. PVE раз в сутки набекапил все на отдельный диск и хорошо.

В общем функционал у PBS впечатляющий, осталось понять и принять решение, а надо оно мне.

[KRom]

@ala-a-din

А яблоко он сможет бекапить?

форум говорит, что нет, но яблоко замечательно бэкапится самостоятельно на самбу посети.

[ala-a-din]

Почитал, посмотрел, еще раз почитал и в общем установил PBS в LXC на основной машине, на их сайте все расписано. Подкинул в этот LXC все тот же отдельный HDD, немножко пришлось поприседать правда с этим, но тем не менее все настроил. Создал первый бекап. Наблюдаю. Спасибо, что дали первые пояснения что это и зачем оно.