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

Фиона... Как успехи с вымогательством у Backup?, Proxmox Backup Server

tcabernoch

Guest

27.04.2024 06:13:00

Извиняюсь за беспокойство. Очень много людей ждут эту функцию. Не подкинешь нам хоть какие-нибудь крошки?

--------------------------------------------------------------------------

Смотрите здесь: https://lists.proxmox.com/pipermail/pve-devel/2024-January/061470.html

Когда начинается резервное копирование ВМ, QEMU устанавливает фильтр «copy-before-write» на свой блочный уровень. Этот фильтр гарантирует, что при новых записях гостевой системы старые данные, необходимые для резервной копии, сначала отправляются на резервный носитель. Запись гостя приостанавливается, пока эта операция не завершится, поэтому ввод-вывод гостя для секторов, которые ещё не были сохранены, будет ограничен скоростью резервного носителя. При использовании backup fleecing такие старые данные сначала кэшируются в fleece-образе, а не отправляются напрямую на резервный носитель. Это может улучшить производительность ввода-вывода гостя и даже предотвратить зависания в некоторых случаях, но требует больше места для хранения.

GTA_doum Guest	#2 0 05.03.2025 16:43:00 Как прошли испытания? Стоит ли активировать эту функцию для всех резервных копий?

tcabernoch

Guest

06.03.2025 18:40:00

В то время это был своего рода релиз 0.0 для Proxmox. Фиона говорит, что fleecing — это часть спецификации qm. Так что это их реализация этого процесса. Честно говоря, тогда это было не очень здорово. Но теперь стало лучше. В какой-то степени. Первая версия fleecing решала самую насущную проблему — во время бэкапов ВМ становились нерабочими. С включённым fleecing ситуация стала лучше. Но там было две критические ошибки, которые вместе дали неприятный эффект.

Первая ошибка заключалась в том, что если ZFS-система не успевала ответить на команду удаления кеш-файла fleecing за 5 мс, файл оставался на месте. В последней версии это исправили.

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

Я слышал, что разрабатываются более продуманные методы управления мусором, но, видимо, там идут споры о том, как лучше с ним поступать.

Пока что бэкапы всё ещё падают, если натыкаются на мусор после прошлых сбоев. Так что на данный момент придется убирать его вручную.

guruevi

Guest

08.03.2025 13:45:00

Что касается второго, то такое тоже случается, если резервное копирование прерывается посреди процесса (сбой, проблемы с сервером и т.д.). Есть ли команда, чтобы гарантировать сброс кеша fleecing на диск, или как безопасно удалить/удалить висящий диск?

tcabernoch

Guest

08.03.2025 17:32:00

Хех. Висящий диск. Мне нравится. Да. Всё, что приводит к сбою резервного копирования и неправильной очистке, вызывает оставление файла кеша fleecing на месте. Последующие бэкапы будут падать, пока вы это не исправите. Исправление — занятие неприятное.

Часть 1
Виртуальная машина блокирует файл кеша, пока вы либо не перезагрузите VM, либо (странно, но это работает) не переименуете файл. Так что перезапустите проблемную VM или напишите скрипт.

Часть 2
Если вы не переименовали файл, он привязан к VM, и удалить его через GUI datastore не получится. Ещё его не увидите на странице конфигурации VM. Откройте консоль, выполните zfs list… найдите имя. Там будет что-то про fleecing. Затем выполните zfs destroy thefleecingthing.

ihr

Guest

14.05.2025 17:56:00

Привет! Хочу оставить свой отзыв, надеюсь, он будет полезен и другим. У меня включен fleecing, а в разделе General режим резервного копирования стоит на "stop". Вот что, как я понимаю, происходит при создании бэкапа виртуальных машин:

1. ВМ выключается
2. Включается fleecing, то есть новые записи идут во временное хранилище
3. Запускается резервное копирование с хранилища ВМ
4. ВМ запускается одновременно с процессом резервного копирования

В моём случае и хранилище ВМ, и бэкап лежат на одном и том же NFS-сервере, который отделён от сервера с Proxmox. Это важный момент — сервер Proxmox и сервер хранения находятся в отдельной физической сети. Эта сеть работает через 10G-коммутатор (управляемый коммутатор Cisco).

Скорость резервного копирования ограничена 30 Мбит/с. Время, на которое останавливается ВМ (и сервис), сократилось всего до нескольких секунд (10–20 секунд). Но иногда (случайно) ВМ не запускается корректно из-за сбоев в сети, и её приходится перезапускать вручную.

Я всё ещё не знаю, можно ли как-то отложить процесс бэкапа, чтобы дать ВМ время нормально стартануть, а потом уже резервное копирование использовало всю доступную полосу пропускания, когда сервер полностью поднялся.

Надеюсь, этот отзыв кому-то поможет. Всего хорошего, Игнасио.

guruevi

Guest

14.05.2025 23:09:00

Итак, ваша сеть перегружена до такой степени, что происходит потеря пакетов (если предположить, что сервер для бэкапа и для образов не один и тот же). В таком случае я бы посоветовал настроить какой-то приоритетный режим очереди в сетевом стеке — либо на стороне Proxmox, либо на сетевом коммутаторе/роутере. При этом не стал бы динамически увеличивать скорость бэкапа, потому что таймаут или потеря пакетов во время работы виртуальной машины скорее приведут к большим проблемам, чем медленный бэкап. В идеале, конечно, стоит улучшить саму сетевую инфраструктуру. Но я запутался — вы сказали, что это тот же NFS-сервер, тогда вы не делаете бэкапы, а просто копируете данные. Возможно, ваш NFS-сервер просто не справляется с таким количеством запросов — и это уже отдельная проблема.

fiona

Guest

15.05.2025 11:10:00

Привет, нет, Proxmox VE должен читать данные через блочный уровень QEMU, а затем записывать их на целевой бэкап, так что на самом деле данные по сети передаются дважды! В любом случае не рекомендуется использовать одно и то же хранилище для хранения данных и резервных копий.

guruevi

Guest

15.05.2025 13:31:00

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

fiona Guest	#10 0 15.05.2025 16:59:00 Ах, перечитывая твоё предложение, я теперь понимаю, что ты имел в виду.

Читают тему

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