+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Статус резервного копирования S3, Proxmox Backup Server

p-user

Guest

30.08.2025 20:12:00

Я вижу, что у многих возникают проблемы с опцией резервного копирования на S3. Очевидно, что на форумах обычно публикуют неудачные истории. Так что, насколько хорошо это вообще работает, есть ли какие-то подводные камни? Я собираюсь скоро использовать такой тип резервного копирования. Хотелось бы использовать европейское хранилище (живу в Нидерландах), есть какие-нибудь рекомендации? Я думал о Hetzner. К тому же, лучше сначала делать бэкап на локальный диск, а потом синхронизировать с S3 удалённо (если это возможно)? Ещё слышал, что для S3 нужен локальный кэш — можете что-нибудь посоветовать по этому поводу? Зависит ли это от максимального размера файла для передачи? С уважением, Альберт

p-user

Guest

15.09.2025 08:12:00

Я использую это уже две недели, с подключением S3 к Tuxis daDup в качестве хранилища на моём pbs:
- Работает, но только для виртуальных машин размером не больше 32 ГБ, бэкапы ВМ на 64 ГБ падают.
- Сбойные бэкапы доходят до 100%, потом задачи резервного копирования на pve-узле завершаются с ошибкой, pbs зависает, и веб-интерфейс становится недоступным.
- Использование backup-proxmox-client работает, даже с включённым шифрованием, но опять же только для бэкапов до 32 ГБ (см. выше).
- Восстановление работает. Если бэкап сделан успешно, его можно успешно восстановить.
- Проверка после бэкапа (опция) — плохая идея, так как верификация занимает слишком много времени.
- Очистка мусора на S3-хранилище работает нормально. Мне пришлось её запускать после неудачных больших бэкапов — благодаря ей освободилось место.
- Использование кеша нормально до 60 ГБ максимум. Рекомендуется отдельный раздел или диск. Но сменить диск кеша, если он выйдет из строя, не так просто. Возможно, придётся очистить S3-хранилище и начать всё с нуля, чтобы избавиться от ошибок при запуске кеша на пустом новом диске. Требуется процедура для замены диска кеша.
- Синхронизация локального хранилища с S3 на том же pbs пока не работает (я буду разбираться). Нужно ли при настройке синхронизации использовать реальный IP pbs или можно localhost? Попытка синхронизироваться под root@pam не удаётся: он видит «удалённое» хранилище и namespaces, но при самой синхронизации падает из-за отсутствия прав доступа.

Я понимаю, что это технологическая превью-версия, и сейчас её нужно воспринимать именно так — она ещё нестабильна. О проблеме зависания, о которой я упомянул, пишут и другие пользователи. Надеюсь, скоро выйдут исправления.

С уважением, Альберт

p-user

Guest

16.09.2025 21:20:00

Я запустил две задачи: резервное копирование клиента объемом 140 ГБ и резервную копию виртуальной машины с Windows 11 размером 64 ГБ — одновременно. Резервная копия Windows 11 достигла 100%, и дальше — тишина. Система не зависла, но прогресс остановился. Более того, резервное копирование клиента тоже больше не развивается. Вот последний вывод клиента резервного копирования, как видите, дальше ничего не сохраняется:

обработано 50.504 ГиБ за 14 мин, загружено 50.347 ГиБ
обработано 53.766 ГиБ за 15 мин, загружено 53.598 ГиБ
обработано 57.187 ГиБ за 16 мин, загружено 57.008 ГиБ
обработано 60.259 ГиБ за 17 мин, загружено 60.086 ГиБ
обработано 63.095 ГиБ за 18 мин, загружено 62.912 ГиБ
обработано 66.685 ГиБ за 19 мин, загружено 66.512 ГиБ
обработано 69.986 ГиБ за 20 мин, загружено 69.815 ГиБ
обработано 73.421 ГиБ за 21 мин, загружено 73.25 ГиБ
обработано 75.701 ГиБ за 22 мин, загружено 75.311 ГиБ
обработано 75.701 ГиБ за 23 мин, загружено 75.311 ГиБ
обработано 75.701 ГиБ за 24 мин, загружено 75.311 ГиБ
обработано 75.701 ГиБ за 25 мин, загружено 75.311 ГиБ
обработано 75.701 ГиБ за 26 мин, загружено 75.311 ГиБ

А вот часть из резервной копии виртуальной машины:

Веб-интерфейс по-прежнему работает, при проверке статуса резервного копирования ВМ он показывает «выполняется»:

Если посмотреть в Task Viewer на PBS, видно, что чанки не добавляются — вот последний фрагмент, и новых данных нет:

Chris

Guest

15.09.2025 11:21:00

Скорее всего, у вас таймаут из-за проблем с задержками в сети. Исправление уже внесено в git и будет включено в версию proxmox-backup 4.0.15. https://git.proxmox.com/?p=proxmox.git;a=commit;h=1c33b8bcdab1e0415084e058670d149b1015143e Также сейчас разрабатывается общая реализация ограничения скорости, подробности здесь: https://lore.proxmox.com/pbs-devel/20250828102604.463662-1-c.ebner@proxmox.com/T/ Исправление в git, которое войдёт в версию proxmox-backup 4.0.15, смотрите тут: https://git.proxmox.com/?p=proxmox-backup.git;a=commit;h=dbaa4b6992e504007c0ce9b26c34c6f52f996dac Думаю, проблема с таймаутом запросов такая же, как и выше. Можно перевести хранилище в офлайн-режим обслуживания, потом вручную изменить путь в конфиге хранилища. После этого отключить режим обслуживания и сделать обновление s3. Так работает без проблем, можно использовать либо локальную синхронизацию pull job, либо настроить PBS как отдельный удалённый сервер через localhost.

p-user Guest	#5 0 15.09.2025 11:59:00 Спасибо! Отличная новость. Я никогда не думал поставить хранилище данных в режим обслуживания, но теперь попробую. Простое решение! С уважением, Альберт

p-user

Guest

16.09.2025 09:21:00

Привет, Крис! Я попробовал, но пока это не совсем то, что должно быть:

- Перевёл S3 хранилище в режим обслуживания
- Отредактировал /etc/proxmox-backup/datastores.cfg для нового (пустого) кэша в /cache
- Создал пустую папку /cache/.chunks (понадобилась именно .chunks, потому что без неё была ошибка)
- Зашёл в содержимое S3 хранилища и под кнопкой «Ещё» нашёл опцию обновления (возможно, лучше сделать это отдельной кнопкой «Перезагрузить»)
- Вынул S3 хранилище из обслуживания, зашёл в содержимое — получил такую ошибку:

- Сделал обновление S3, сработало, но после перезагрузки получил другую ошибку:

- Проверил папку /cache/.chunks — никаких файлов там нет
- Поставил права и владельца, как у оригинального кэша: chmod 755 /cache, chmod 750 /cache/.chunks, chown -R backup:backup /cache
- Ошибки пропали, могу делать обновление S3, но содержимое S3 хранилища остаётся пустым, даже после перезагрузки
- Проверил /cache/.chunks — всё ещё пусто

Наверное, я что-то упускаю.

С уважением, Альберт

P.S. Обратная процедура (возврат к оригинальному кэшу) работает отлично. За исключением одного (пустого) пространства имён, которое просто исчезает после процедуры.

Chris

Guest

16.09.2025 09:43:00

https://forum.proxmox.com/attachments/error2-png.90665/ https://forum.proxmox.com/attachments/error1-png.90666/

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

Что показывает лог задачи обновления s3? Есть ли ошибки? Чанки будут загружаться только по запросу, так что неудивительно, что их сейчас нет, однако файлы пространства имён резервной копии, группы и снимка должны быть загружены.

p-user

Guest

16.09.2025 10:26:00

Понимаю, что сами чанки будут загружаться по запросу — это кеш. Команда обновления показывает файлы для получения, но в новый кеш они не попадают. Я не вижу ни неймспейсов, ни данных. Нужно ли что-то перезапускать, чтобы подхватить новый кеш? Возможно, команда обновления всё ещё использует исходное расположение. Попробую снова, на этот раз перезагрузить pbs, чтобы подхватить новый кеш.

Окей, мне ещё нужно создать директорию ns, так что структура такая:

root@pbs:/# ls -laR /cache
.:
всего 12
drwxr-xr-x 3 root root 4096 16 сен 09:57 .
drwx------ 7 root root 4096 16 сен 09:57 ..
drwxr-xr-x 4 backup backup 4096 16 сен 09:57 cache

/cache:
всего 16
drwxr-xr-x 4 backup backup 4096 16 сен 09:57 .
drwxr-xr-x 3 root root 4096 16 сен 09:57 ..
drwxr-x--- 2 backup backup 4096 16 сен 09:57 .chunks
drwxr-xr-x 2 backup backup 4096 16 сен 09:57 ns

/cache/.chunks:
всего 8
drwxr-x--- 2 backup backup 4096 16 сен 09:57 .
drwxr-xr-x 4 backup backup 4096 16 сен 09:57 ..

/cache/ns:
всего 8
drwxr-xr-x 2 backup backup 4096 16 сен 09:57 .
drwxr-xr-x 4 backup backup 4096 16 сен 09:57 ..

Где backup — это мой пользователь backup.

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

Что касается неймспейса, который пропал (как я уже говорил), я ещё не делал туда бэкап, так что, скорее всего, его просто нет в S3 бакете — это объяснимо.

Пару рекомендаций/пожеланий:
- Сделать кнопку «Обновить содержимое из S3 бакета» отдельной, например «S3 Refresh» или как-то так, а не прятать её в разделе «Ещё» — так будет понятнее.
- Кнопку кеша — чтобы можно было видеть локацию, очищать кеш, инициализировать кеш (то есть создавать структуру директорий) — это было бы удобно. Можно этот функционал тоже спрятать под кнопку «Ещё».

Впрочем, процедура, описанная выше, работает отлично.

Спасибо за помощь.
С уважением, Альберт

Chris

Guest

16.09.2025 14:57:00

Доступна версия proxmox-backup-server 4.0.15-1 в репозитории pbs-test. Рекомендуется проверить, решают ли включённые исправления вашу проблему, спасибо. Чтобы активировать тестовый репозиторий, смотрите https://pbs.proxmox.com/docs/installation.html#proxmox-backup-test-repository

p-user Guest	#10 0 16.09.2025 17:14:00 Привет, Крис, сегодня вечером попробую. С уважением, Альберт

p-user

Guest

#11

16.09.2025 21:33:00

К вашему сведению, я запутался и думал, что веб-интерфейс всё ещё работает, только когда я свернул окно просмотра задач и попытался открыть его снова, веб-интерфейс перестал отвечать. Также, как только я перезагрузил PBS, клиент Proxmox Backup (который всё ещё работал, но без прогресса) завершился с ошибкой. Похоже, где-то завис процесс.

p-user

Guest

#12

16.09.2025 21:49:00

В общем, я только что сделал один бэкап виртуальной машины pve (Windows 11, 64 ГБ), и он зависает на 100%, так что то, что у меня одновременно шли два бэкапа (один виртуалки и один через backup-client), вообще ничего не изменило.

p-user

Guest

#13

17.09.2025 09:32:00

Ладно, частично признаю свою неправоту. Сегодня утром столкнулся с проблемой резервного копирования в S3-хранилище, но смог её исправить с помощью S3 Refresh*). Тогда решил попробовать снова с proxmox-backup-client, копировал смонтированные smb-шары: одна была 47 ГБ, другая — 130 ГБ. И что вы думаете? Всё прошло успешно. Успех! Потом сделал бэкап своей 64-гигабайтной Windows 11 виртуальной машины: сначала на локальное хранилище — без проблем. Потом на S3 — там, конечно, куча сообщений о том, что чанки уже в кэше, что и ожидалось. Однако этот бэкап снова завис после достижения 100% и заблокировал веб-интерфейс pbs. Короче, тестовая версия репозитория отлично работает для резервных копий через backup-client, но не для бэкапов pve vm. Надеюсь, будет полезно. С уважением, Альберт.

*) Я сделал скрипт, который монтирует smb-шару, а потом запускает бэкап. Для одного шары сработало, для другой выдало ошибку "proxmox backup client Error: fetching owner failed" — настройки доступа были в порядке, так что не смог понять причину. В итоге воспользовался S3 Refresh, и это помогло. Полагаю, остались хвосты от предыдущих неудач.

Chris

Guest

#14

18.09.2025 10:01:00

Не могли бы вы поделиться: конфигурацией виртуальной машины, конкретно для этой VM, используя команду qm config <VMID> --current; журналом задачи резервного копирования как на PBS, так и на хосте PVE; системным журналом systemd хоста PBS за период полного резервного копирования, командой journalctl --since <DATETIME> --until <DATETIME> > journal.txt. Выполняются ли другие задачи во время резервного копирования? Например, очистка (prune), сборка мусора (gc) и т.д.? Только что успешно сделал резервную копию виртуальной машины с Windows 11 и диском 150 ГБ, так что здесь могут влиять и другие факторы.

p-user

Guest

#15

18.09.2025 10:38:00

Привет, Крис! Вот запрошенная информация, конфигурация:

root@pve1:~# qm config 103 --current
agent: 1
bios: ovmf
boot: order=scsi0;ide0;net0
cores: 2
cpu: x86-64-v2-AES
efidisk0: Storage_NFS:103/vm-103-disk-2.qcow2,efitype=4m,pre-enrolled-keys=1,size=528K
ide0: none,media=cdrom
lock: backup
machine: pc-q35-8.1
memory: 8192
meta: creation-qemu=8.1.5,ctime=1716035235
name: Windows11
net0: virtio=BC:24:11:C4:CC:93,bridge=vmbr0,firewall=1
numa: 0
ostype: win11
scsi0: Storage_NFS:103/vm-103-disk-3.qcow2,discard=on,iothread=1,size=64G
scsihw: virtio-scsi-single
smbios1: uuid=8231ea81-9d77-40e4-bb26-d3be1e1c7723
sockets: 1
tpmstate0: Storage_NFS:103/vm-103-disk-1.raw,size=4M,version=v2.0
vga: virtio
vmgenid: 3c399401-fec8-4d8f-b7d3-6942bc680005

Логи на pbs:

root@pbs:~# journalctl --since "30 min ago" > journal.txt
Sep 18 09:49:45 pbs proxmox-backup-proxy[874]: rrd journal успешно зафиксирован (33 файла за 0.009 секунды)
Sep 18 10:12:28 pbs sshd-session[12006]: Accepted password for root from 192.168.2.110 port 58217 ssh2
Sep 18 10:12:28 pbs sshd-session[12006]: pam_unix(sshd:session): сессия открыта для пользователя root(uid=0) пользователем root(uid=0)
Sep 18 10:12:28 pbs systemd-logind[682]: Новая сессия 2 пользователя root.
Sep 18 10:12:28 pbs systemd[1]: Создан срез user-0.slice - пользовательский срез UID 0.
Sep 18 10:12:28 pbs systemd[1]: Запуск user-runtime-dir@0.service - каталог временного выполнения пользователя /run/user/0...
Sep 18 10:12:28 pbs systemd[1]: Завершён user-runtime-dir@0.service - каталог временного выполнения пользователя /run/user/0.
Sep 18 10:12:28 pbs systemd[1]: Запуск user@0.service - менеджер пользователей с UID 0...
Sep 18 10:12:28 pbs (systemd)[12012]: pam_unix(systemd-user:session): сессия открыта для пользователя root(uid=0) пользователем root(uid=0)
Sep 18 10:12:28 pbs systemd-logind[682]: Новая сессия 3 пользователя root.
Sep 18 10:12:28 pbs systemd[12012]: Запланировано задание запуска для стандартной цели default.target.
Sep 18 10:12:28 pbs systemd[12012]: Создан срез app.slice - срез приложений пользователя.
Sep 18 10:12:28 pbs systemd[12012]: Достигнута цель paths.target - пути.
Sep 18 10:12:28 pbs systemd[12012]: Достигнута цель timers.target - таймеры.
Sep 18 10:12:28 pbs systemd[12012]: Ожидание dirmngr.socket - демон управления сетевыми сертификатами GnuPG.
Sep 18 10:12:28 pbs systemd[12012]: Ожидание gpg-agent-browser.socket - криптографический агент GnuPG и кэш паролей (доступ для браузеров).
Sep 18 10:12:28 pbs systemd[12012]: Ожидание gpg-agent-extra.socket - криптографический агент GnuPG и кэш паролей (ограниченный).
Sep 18 10:12:28 pbs systemd[12012]: Запуск gpg-agent-ssh.socket - криптографический агент GnuPG (эмулятор ssh-agent)...
Sep 18 10:12:28 pbs systemd[12012]: Запуск gpg-agent.socket - криптографический агент GnuPG и кэш паролей...
Sep 18 10:12:28 pbs systemd[12012]: Ожидание keyboxd.socket - служба управления открытыми ключами GnuPG.
Sep 18 10:12:28 pbs systemd[12012]: Запуск ssh-agent.socket - сокет агента OpenSSH...
Sep 18 10:12:28 pbs systemd[12012]: Ожидание gpg-agent.socket - криптографический агент GnuPG и кэш паролей.
Sep 18 10:12:28 pbs systemd[12012]: Ожидание ssh-agent.socket - сокет агента OpenSSH.
Sep 18 10:12:28 pbs systemd[12012]: Ожидание gpg-agent-ssh.socket - криптографический агент GnuPG (эмулятор ssh-agent).
Sep 18 10:12:28 pbs systemd[12012]: Достигнута цель sockets.target - сокеты.
Sep 18 10:12:28 pbs systemd[12012]: Достигнута цель basic.target - базовая система.
Sep 18 10:12:28 pbs systemd[12012]: Достигнута цель default.target - основная цель пользователя.
Sep 18 10:12:28 pbs systemd[12012]: Запуск завершён за 182 мс.
Sep 18 10:12:28 pbs systemd[1]: Запущен user@0.service - менеджер пользователя с UID 0.
Sep 18 10:12:28 pbs systemd[1]: Запущена сессия session-2.scope - сессия 2 пользователя root.

Что касается логов на pbs бэкапа: так как система зависает, я не могу их скачать. Скриншот покажет лишь куски, а потом всё останавливается, других сообщений не видно. Приходится перезагружать pbs, чтобы вернуть контроль. Других задач не запущено. Если у тебя есть ещё файлы для проверки — дай знать.

Пробовал Ubuntu VM с диском 64 ГБ — сработало нормально, значит проблема скорее в бэкапе Windows 11 64 ГБ VM. Просто мысль: может, маленький TPM-диск тут проблема?

p-user

Guest

#16

18.09.2025 21:14:00

Хорошо, Крис, я немного продвинулся дальше:
- Windows 11 виртуальная машина — единственная из моих вм с EFI-диском.
- У Windows 11 вм есть ещё TPM-диск.

Итак, я склонировал Windows 11 вм на новую машину, удалил TPM-диск и запустил резервное копирование на S3-датастор — и вот, работает! Потом я снова добавил TPM-диск к этой вм, и резервное копирование всё равно прошло успешно.

Затем я снова склонировал Windows 11 вм на ещё одну новую машину, ничего не удалял, просто попробовал резервное копирование — и оно тоже сработало. Теперь я сделал бэкап оригинальной Windows 11 вм, и, о чудо, он тоже работает.

Короче, что бы это ни было, похоже, теперь всё нормально (хотя сегодня утром не работало). Почему — понятия не имею. Обычно я бы сказал «надеюсь, это поможет», но сейчас как-то не очень уместно.

С уважением, Альберт

Chris

Guest

#17

19.09.2025 08:48:00

Что-то ещё изменилось на исходной виртуальной машине? Диски всё ещё резервируются в том же порядке? Возможно, просто немного изменился порядок доступа или тайминги, и из-за этого зависание больше не происходит. Спасибо за тестирование и то, что поделились результатами!

p-user

Guest

#18

19.09.2025 08:54:00

Привет, Крис, нет, с виртуальной машиной ничего не менялось. Единственное, что изменилось на pve-ноды — это вчерашнее обновление, кажется, там тоже обновился qemu, но это вряд ли связано с проблемой. Поскольку это (незарегистрированная) Windows 11, просто для теста, я её удалю и восстановлю из локального бэкапа (который всегда работал без проблем), чтобы проверить, смогу ли сохранить его на S3-хранилище. Совсем не понимаю, почему вдруг всё заработало, но рад, что наконец-то всё пошло. С уважением, Альберт. P.S. После официального выхода обновлений pbs (то есть не в тестовом режиме) я могу отключить тестовый репозиторий и спокойно использовать обычные обновления?

Chris Guest	#19 0 19.09.2025 09:01:00 Да, достаточно просто отключить репозиторий pbs-test.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры