Защо ми се пълни диска с Proxmox бекъпи и как да оптимизирам процеса (Практическо решение)

Наскоро се натъкнах на класически проблем и трябваше да направя оптимизация на Proxmox бекъпи, защото външният ми диск за архиви започна да крещи, че е пълен.

В конфигурацията на скрипта имах една много логична на пръв поглед настройка: KEEP_DAYS=30. Очаквах скриптът да пази бекъпите за последните 30 дни и да трие по-старите. Проблемът? Дискът ми започна да крещи, че е пълен.

Ето как разкодирах проблема и как го реших с няколко премерени команди.

Илюзията на KEEP_DAYS и математиката зад нея

Първата ми грешка беше, че не обърнах внимание на математиката. В моя скрипт бях конфигурирал да бекъпвам 12 контейнера едновременно:

SERVER_0="pve-main|10.110.110.68|root|/backup512/dump|102:104:107:108:110:111:112:113:116:109:222:900"

Настройката KEEP_DAYS=30 НЕ означава, че държиш общо 30 бекъпа на диска. Тя означава, че държиш по 30 бекъпа за всеки един контейнер.

Ако скриптът се пуска всеки ден:

• 12 контейнера × 30 дни = 360 бекъп файла. Ако средният размер на контейнер е 2 GB, това означава, че държа постоянни 720 GB задържани на диска. Всяка нощ се добавят 12 нови файла и се трият 12 старите. Дискът винаги е на 100% капацитет.

Ловът на "невидимите" боклуци: Проблемът с шаблоните

Докато анализирах списъка, забелязах нещо важно. Някои от контейнерите (напр. 222 и 900) всъщност не бяха активни машини, а бяха превърнати в Официални Proxmox Шаблони (Templates).

Тук се крие друга капана. Инструментът vzdump, който Proxmox използва за бекъп, отказва да прави бекъп на шаблони. Резултатът? Скриптът всеки ден се опитваше, гърмеше за тези два ID-та, но техните стари бекъпи (от времето, когато са били контейнери) си стояха в папката и заемаха излишно място.

Решение 1: Просто ги махнах от конфигурацията на скрипта:

SERVER_0="pve-main|10.110.110.68|root|/backup512/dump|102:104:107:108:110:111:112:113:116:109"

Инкрементални ли са тези бекъпи? (Short answer: Не)

Преди да трия неща, се чудях: "Нали Proxmox/right копира само променените файлове?" Отговорът е Не. Тези бекъпи са пълни архиви (Full Backups) – цялата файлова система на контейнера е пакетирана в един .tar.gz или .tar.zst файл. Дори да си променил само един конфигурационен файл от 2 KB, новият бекъп ще е с пълния размер на контейнера.

Затова, когато намалим KEEP_DAYS от 30 на 3, ефектът върху диска е драстичен.

📚

Препоръчано четиво

Имат ли все още бъдеще традиционните сайтове и как ги прехвърлих на безплатен хостинг с една команда

→ Прочети статията

Агресивното изчистване на миналото

Промених KEEP_DAYS=3 в конфига, но възникна нов проблем: Скриптът трие старите файлове само когато създаде нов. Ако не исках да чакам месец, за да се изчисти дискът естествено, трябваше да го направя ръчно.

Първоначално използвах хитър "one-liner", който оставя само най-новия бекъп за дадено ID и трие останалите:

ls -t *-900-* | tail -n +2 | xargs rm -f

Логиката тук е красива: ls -t сортира файловете по дата (най-новият е първи). tail -n +2 взима всичко от втория ред надолу (т.е. пропускаме най-новия) и ги подава на rm -f.

Това обаче помогна малко, защото истинският проблем бяха 10-те активни контейнера с техните 30-дневни истории. Трябваше ми ядрена опция.

Решението: find с изтриване по време Тъй като вече бях решил да държа само 3 дни история, използвах следната команда, за да изтрия миналото наведнъж:

find /mnt/d/backup_proxmox2/pve-main -type f -name "vzdump-*" -mtime +3 -delete

Тази команда е брилянтна в своята простота. Тя намира всички файлове (-type f), които започват с vzdump- (за да не изтрия случайно нещо друго) и са по-стари от 3 дни (-mtime +3), след което ги трие (-delete). Изпълних я и за секунди освободих стотици гигабайти.

Какво стана на следващия ден?

На следващото денонощие скриптът се стартира по график. Той свали новите бекъпи за деня в вече чистата папка. След това автоматично изтри бекъпите, които бяха станали на 4 дни старии.

Системата влезе в идеален баланс: дисковото пространство спря да расте неестествено, а аз запазих достатъчно история (3 дни назад), за да мога да възстановя счупена инсталация, ако се наложи.

Бонус: Полезни команди за управление на Proxmox бекъпи

Ако и вие се сблъскате с подобна ситуация, ето няколко команди, които ми бяха изключително полезни при диагностиката:

1. Проверка колко бекъп файла имате общо:

find /път/до/бекъпите -name "vzdump-*" | wc -l

2. Преглед на размерите на отделните бекъпи (за да видите кой контейнер е "грамаден"):

du -sh /път/до/бекъпите/vzdump-*

3. "Dry Run" на изтриването (Безопасен тест): Ако искате да видите какво щеше да изтрие командата find, просто махнете -delete накрая:

find /път/до/бекъпите -type f -name "vzdump-*" -mtime +3

Тя ще ви изпринтира списъка на файловете. Ако сте съгласни, натискате стрелка нагоре и добавяте -delete.

4. Скрипт за прецизно изчистване по брой (алтернатива на датите): Ако искате да оставите точно 3 бекъпа за всеки контейнер, независимо от колко дни са стари, този малък цикъл свърши чудесна работа:

for ID in 102 104 107 108; do

COUNT=$(ls -1 vzdump-lxc-${ID}-* 2>/dev/null | wc -l)

if [ "$COUNT" -gt 3 ]; then

ls -t vzdump-lxc-${ID}-* | tail -n +4 | xargs rm -f

fi

done

Заключение

Когато управляваме бекъпи, простото намаляване на днейте в конфига не винаги е достатъчно, ако не разбираме какво точно се съхранява. Премахването на статични елементи (шаблони) от рутината и агресивното изчистване на миналите архиви с find е най-чистият начин да възстановите дисковото си пространство без риск за реалните данни.