Настройка
Новости
Оплата
Доставка
Информация
Контакты
Загрузки
Форум
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Каталог
    • 1U
      1U
    • 2U
      2U
    • 3U
      3U
    • 4U
      4U
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Каталог
    0 Сравнение
    0 Избранное
    0 Корзина
    Аспро: ЛайтШоп
    Телефоны
    +7 (495) 320-70-49
    Заказать звонок
    0
    0
    0
    Аспро: ЛайтШоп
    • +7 (495) 320-70-49
      • Назад
      • Телефоны
      • +7 (495) 320-70-49
      • Заказать звонок
    • info@proxmox.su
    • Москва, Бакунинская улица, 69с1
    • Пн-Пт: 09-00 до 18-00
      Сб-Вс: выходной
    • 0 Сравнение
    • 0 Избранное
    • 0 Корзина
    Главная
    Форум
    Proxmox Backup Server
    Резервное копирование контейнеров LXC идет невероятно медленно

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    Ответить
    RSS
    Резервное копирование контейнеров LXC идет невероятно медленно, Proxmox Backup Server
     
    infinityM
    Guest
    #1
    0
    18.11.2020 06:44:00
    Привет, ребята! У нас есть LXC-контейнер размером около 2 ТБ. Но когда мы делаем резервное копирование этого сервера, это занимает больше 7 часов. При этом у меня есть несколько виртуальных машин размером 5-6 ТБ, и резервное копирование занимает всего около 20 минут. Почему резервное копирование LXC так медленное?
     
       Цитировать   Имя
     
    dorijan79
    Guest
    #2
    0
    25.04.2022 23:24:00
    Да, у меня такая же проблема, и за последние два года ничего не изменилось. У меня диск LXC на 6 ТБ, и на резервное копирование уходит 3 дня... Я использую proxmox backup.
     
    Цитировать   Имя
     
    tomtom13
    Guest
    #3
    0
    22.08.2022 01:25:00
    Так что я в той же лодке. Перед тем как внедрить PBS для продакшена, я развернул его в тестовом кластере. Тестовый LXC (4 ТБ) занимает 2 часа на бэкап, при том что ничего не менялось. Странно то, что в течение этих 2 часов, пока идёт бэкап, на PBS и машине с LXC почти нет активности диска... При этом процессор даже холодный. Тестовые виртуалки размером 128 ГБ, 300 ГБ и 512 ГБ делают бэкап за секунды. Есть один момент, который не укладывается в голове: весь персонал Proxmox говорит, что только запущенные виртуалки могут быстро делать дифференциальный бэкап, но у меня есть машина с виртуалками, которая включается только периодически и сразу после старта делает бэкап — и у неё это занимает пару секунд. При всём этом LXC с машины, которая работает круглосуточно, бэкапится вечность. Чтобы добавить масла в огонь, проверка всех виртуалок занимает секунду или две для маленьких инкрементных бэкапов, а у LXC проверка инкрементного бэкапа (который всего пара мегабайт, к слову) занимает 7 часов и при этом жрёт диски как сумасшедшая.
     
    Цитировать   Имя
     
    fabian
    Guest
    #4
    0
    22.08.2022 08:57:00
    Помимо главного отличия (грязные битмапы с работающими ВМ позволяют пропускать операции чтения неизменённых блоков), в обработке резервных копий ВМ гораздо меньше сложности — резервные копии ВМ работают на блоках, каждый входящий блок фиксированного размера, ничего не нужно делать, кроме как сжимать, хэшировать и, возможно, шифровать. Резервные копии CT/host основаны на файлах, входящие блоки имеют переменный размер, нужно разбирать дерево каталогов (что может вызвать много случайных операций ввода-вывода), считывать, конвертировать в поток архива pxar, затем сжимать, хэшировать и, возможно, шифровать. Думаю, можно догадаться, что именно производительность вашей файловой системы при работе с каталогами и метаданными влияет на это.

    Что вы имеете в виду под «проверкой»? Верификация PBS выполняется на стороне PBS и заключается в чтении всех блоков снимка и хэшировании их содержимого, так что это и операция чтения, и нагрузка на процессор, но по сути всё одинаково и для fidx, и для didx резервных копий, просто формат индексов немного другой. Содержимое при этом никак логически не анализируется и не проверяется, так что различия в данных значения не имеют.
     
    Цитировать   Имя
     
    tomtom13
    Guest
    #5
    0
    22.08.2022 12:00:00
    Да, ты абсолютно прав. ТОЛЬКО ты (то есть операционная система Proxmox) уже знаёшь, какая файловая система у базового хранилища, потому что я выбираю её из выпадающего списка в GUI — ZFS. Для каждого типа хранилища может быть своя логика, в этом нет ничего особенно сложного — разные функции можно реализовать через switch case.

    Да, этот момент — я говорил про PBS. Но вот это странный момент: хотя бэкапы для CT — инкрементальные (объём, который по отчётам отправляется с PVE в PBS), проверка (периодическая или при приёме — я пробовал оба варианта) занимает 6–7 часов, и PBS, кажется, просматривает все 4 ТБ данных на диске.

    И да, предыдущие бэкапы этого CT уже проверены… можно было бы предположить, что проверяется только инкрементальный бэкап в 10 МБ, который отправлен в PBS… как ты знаешь, инкремент же? И ещё, сейчас в PBS есть 10 бэкапов этого CT размером 4 ТБ, а в отчёте по хранилищу указано занято около 4 ТБ (и чуть больше), так что не думаю, что каждый бэкап — это полные 4 ТБ данных.

    Даже вывод ZFS показывает, что занимаемое место не такое уж большое:  
    Code:  
    zfs list  
    NAME               USED  AVAIL     REFER  MOUNTPOINT  
    rpool             12.7G  1.74T       96K  /rpool  
    rpool/ROOT        12.7G  1.74T       96K  /rpool/ROOT  
    rpool/ROOT/pve-1  12.7G  1.74T     12.7G  /  
    rpool/data          96K  1.74T       96K  /rpool/data  
    storage_cold      3.39T  49.3T     3.39T  /mnt/datastore/storage_cold  

    Ещё один момент (третий): я думал (ну, надеялся), что PBS будет (более) осознавать своё хранилище, и если инкрементальные бэкапы делаются на хранилище вроде ZFS, то они будут основываться на встроенных снимках.
     
    Цитировать   Имя
     
    fabian
    Guest
    #6
    0
    22.08.2022 12:07:00
    Нет, клиент резервного копирования не зависит от файловой системы, он использует обычные операции с файлами и папками, дифференциации на этом уровне нет. Если вы проверяете один снимок, будут проверены все его блоки. Снимок всегда полный, нет инкрементных или полных снимков — все они «равнозначны». Инкрементальной является только выгрузка, так как она пропускает повторную загрузку блоков, которые уже есть на сервере. Хранилище блоков, используемое datastore, занимается дедупликацией. Так что да, в вашем случае (повторная) проверка одного снимка прочитает и проверит 4 ТБ данных. (Повторная) проверка десяти снимков одного CT с небольшими изменениями между ними создаст лишь немного большую нагрузку, чем проверка одного, потому что блоки, уже проверенные в рамках одной задачи проверки, очевидно, не проверяются повторно. Кратко: «проверять после резервного копирования» не обязательно, если только вы не слишком параноите. Плановая проверка с разумными настройками повторной проверки — оптимальный выбор для большинства систем, чтобы снизить нагрузку от проверки и сохранить почти все преимущества. PBS (и клиент, и сервер) практически не зависят от хранилища и используют только стандартные файловые API.
     
    Цитировать   Имя
     
    Страницы: 1
    Ответить
    Читают тему
    BBCode   Правила
    Форма ответов
    Текст сообщения*
    Перетащите файлы
    Ничего не найдено
    Файл
    Загрузить картинки
    #name# #size#
     
    #name#
    Файлы:
    Перетащите один или несколько файлов в эту область
    или выберите файл на компьютере
    Файлы:
    Загрузить файлы
     
    +7 (495) 320-70-49
    info@proxmox.su

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