Информация
Услуги
  • Внедрение
  • Настройка
  • Поддержка
  • Ремонт
Контакты
Оплата
Новости
Доставка
Загрузки
Форум
Настройка
    info@proxmox.su
    +7 (495) 320-70-49
    Заказать звонок
    Аспро: ЛайтШоп
    Войти
    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 deduplication

    Форумы: Proxmox Виртуальная Среда, Proxmox Backup Server, Proxmox Mail Gateway, Proxmox Datacenter Manager
    Поиск  Пользователи  Правила  Войти
    Страницы: 1
    RSS
    backup deduplication, Proxmox Виртуальная Среда
     
    moihuguesjoyal
    Guest
    #1
    0
    29.08.2019 22:51:00
    Привет, я хочу создать скрипт, который будет делать резервную копию моей текущей виртуальной машины и хранить её в системе дедупликации. (Я использую BorgBackup с удалённым репозиторием для хранения.) Я пытался использовать vzdump, который создает файл .vma, но он, похоже, плохо работает с дедупликацией. Чтобы обойти это, я попробовал создать снимок виртуальной машины, а затем конвертировать этот снимок изображения в файл qcow2, и это вроде как сработало, но я не уверен, делаю ли я всё правильно. Предположим, у меня есть работающая виртуальная машина с ID 100, сначала я создаю снимок, используя следующую команду: qm snapshot 100 qmsnap. Если виртуальная машина использует формат qcow2, я могу использовать qemu-img info, чтобы увидеть снимок. qemu-img info vm-100-disk-0.qcow2. Я также могу использовать qemu-img convert, чтобы создать новое изображение из снимка. qemu-img convert -O qcow2 -s qmsnap vm-100-disk-0.qcow2 vm-100-snap.qcow2. Если виртуальная машина использует хранилище LVM, я также могу использовать qemu-img для конвертации LVM в файл .qcow2, но для этого мне нужно предварительно активировать том. vgchange -ay qemu-img convert -O qcow2 /dev/pve/snap_vm-100-disk-0_qmsnap vm-100-snap.qcow2. После завершения конверсии у меня есть новое изображение, которое я смог загрузить без проблем на данный момент. Я могу переместить резервную копию с помощью borg, и я удаляю снимок с помощью: qm delsnapshot 100 qmsnap. Так что мой вопрос — имеет ли это смысл?
     
     
     
    rcd
    Guest
    #2
    0
    12.06.2020 20:04:00
    Я знаю, что прошло немного времени, но я сталкиваюсь с похожими проблемами и только что наткнулся на эту тему. Так что, если я правильно понимаю, ты передаешь vzdump в скрипт? Что я не понимаю, так это зачем тебе разжимать дамп с помощью lzop -d — почему просто не не сжимать его изначально, если ты знаешь, что он пойдет в The Borg? Извини, если я все совершенно неправильно понял.
     
     
     
    Alan Urquhart
    Guest
    #3
    0
    31.08.2020 13:41:00
    vzdump сжат с помощью LZO, lzop --to-stdout -d разжимает его перед тем, как передать в BORG. Это сделано для улучшения дедупликации. Если вы отправите сжатый vzdump напрямую в borg, то в моих тестах вы получите примерно 20% дедупликации (на ВМ, которая почти не изменилась между дампами). Если вы отправите разжатый vzdump (как в этом скрипте), я достигаю 92% дедупликации. Сжатый VZDUMP: Код: Количество файлов: 1
    ------------------------------------------------------------------------------
                          Исходный размер      Сжатый размер    Дедуплицированный размер
    Этот архив:                  2.45 ГБ              2.35 ГБ              1.88 ГБ
    Все архивы:                 4.91 ГБ              4.70 ГБ              4.21 ГБ Нерасжатый (по скрипту) Код: Количество файлов: 1
    ------------------------------------------------------------------------------
                          Исходный размер      Сжатый размер    Дедуплицированный размер
    Этот архив:                  5.10 ГБ              2.48 ГБ            179.61 МБ
    Все архивы:                10.20 ГБ              4.96 ГБ              2.47 ГБ
     
     
     
    Bengt Nolin
    Guest
    #4
    0
    31.08.2020 14:49:00
    Да, конечно, вы можете настроить встроенную систему резервного копирования PVE так, чтобы VMA-образ не сжимался при создании резервных копий, а затем передавать его в Borg без распаковки. Вы даже можете вручную запланировать VZDUMP с помощью cron и напрямую передавать данные из VZDUMP в Borg, не сохраняя файл на диске. Но, насколько я понимаю, это невозможно сделать с помощью встроенной системы резервного копирования, управляемой из веб-интерфейса.
     
     
     
    Alan Urquhart
    Guest
    #5
    0
    03.09.2020 20:57:00
    Вот что я использую для достижения этой цели. У меня есть кластер из 3 узлов, который создает резервные копии ВМ на общем ресурсе NFS (на одном из узлов). По этой причине я не хотел использовать скрипт хуков VZDUMP, чтобы избежать проблем с блокировками в borg. Поэтому я запускаю этот скрипт через cron (с узла, который хранит резервные копии vzdump) после завершения всех резервных копий. Код: #!/bin/bash
    export BORG_REPO=''
    export BORG_PASSPHRASE=""

    LOGDIR=/var/log/borgbackup
    LOGFILE=$LOGDIR/vm_backup_$(date +"%Y_%m_%d_%I_%M_%p").log

    SOURCEDIR=/nfs/proxmox_backup/dump
    VMFILE=/tmp/vms.txt
    BACKUPLIST=/tmp/backup.txt
    pvesh get /cluster/resources --type vm --output-format yaml | egrep -i 'vmid|name' | paste - - -d' '| awk '{ print $4 " " $2 }' > $VMFILE
    find $SOURCEDIR -mtime -1 -name '*.lzo' > $BACKUPLIST

    if [ ! -d "$LOGDIR" ]
    then
       mkdir $LOGDIR
    fi

    touch $LOGFILE
    #перенаправляем весь вывод в лог файл
    exec &>> $LOGFILE

    # некоторые помощники и обработка ошибок:
    info() { printf "\n%s %s\n\n" "$( date )" "$*";} >> $LOGFILE

    START_TIME=$(date +%s)

    info "Начинаем передачу сегодняшних резервных копий в $BORG_REPO"
    info "Найдено $( cat "$BACKUPLIST" | wc -l ) резервных копий"

    while read line;
    do

    VMID=$( echo "$line" | cut -d '-' -f 3 )
    VMNAME=$( grep "$VMID" $VMFILE | cut -d ' ' -f2 )
    BACKUPDATE=$( echo "$line" | cut -d '-' -f 4 )
    info "Перенос резервной копии ВМ: $VMID - $VMNAME в Borg"
    lzop --to-stdout -d $line | borg create --verbose --filter AME  --list --stats --show-rc --compression lz4 --exclude-caches --chunker-params 12,20,15,4095 ::vm-$VMID-$VMNAME-$BACKUPDATE -

    done < ${BACKUPLIST}

    info "Общее время выполнения: $(date -ud "@$(($(date +%s) - $START_TIME))" +%T) (ЧЧ:ММ:СС)"
     
     
     
    Bengt Nolin
    Guest
    #6
    0
    04.09.2020 09:49:00
    Это очень похоже на то, что я делаю в одной из своих конфигураций, но я использую один репозиторий Borg на каждую виртуальную машину, чтобы снизить потребление памяти, ускорить удаления и проверки, а также предоставить возможность запускать операции Borg параллельно. Это занимает немного больше дискового пространства, но мне это кажется обоснованным из-за других преимуществ. Это позволяет мне запускать 3-5 резервных копий одновременно, что значительно ускоряет процесс.
     
     
     
    linum
    Guest
    #7
    0
    04.09.2020 10:29:00
    Не является ли новая система резервного копирования Proxmox именно тем, что вы пытаетесь решить?
     
     
     
    Bengt Nolin
    Guest
    #8
    0
    04.09.2020 10:37:00
    Это более или менее так, и даже больше. Это также в бета-версии.
     
     
     
    Alan Urquhart
    Guest
    #9
    0
    04.09.2020 13:35:00
    Да, новая система резервного копирования Proxmox действительно решит проблему резервного копирования кластеров Proxmox эффективно и безопасно. Однако в нашем случае мы используем наши резервные узлы с Borg не только для Proxmox, но и для многих других систем и случаев использования. Нам пришлось бы полностью redesign и reconfigure наши серверы и процессы — что не стоит того. Плюс, она все еще в бете.
     
     
     
    Страницы: 1
    Читают тему
    +7 (495) 320-70-49
    info@proxmox.su

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