Proxmox memoárok: hasznos scriptek

Smart adatok: lassú romlási trendek figyelése

Ismét egy csokor bármi: scriptek mindenféle feladatra. Mentés növekményesen, mentés külső meghajtóra "bolondbiztosan", HDD-SSD smart adatok követése, LXC és PVE frissítése és hasonlók. A scriptek egy részét a Te rendszeredhez kell igazítanod a használathoz, ebben Claude és Qwen AI-ok segítenek - ahogy nekem is segítettek a megírásukban.

Proxmox-ZEN: az állapot

Kezdjük a legújabbal: meghajtók állapotának ellenőrzése és nyomon követése.
Az alap adatokat (hőmérséklet, foglaltság) tudja küldeni a Proxmox pl. Home Assistantba, látható a webUI-n. A disks résznél ott a S.M.A.R.T. passed (jó esetben) és a wearout (elhasználódás) százalékos értéke. De mit is jelent ez? A wearout érdekes dolog, a nálam megfordult SSD és HDD nagy részénél nem tudta kiolvasni, ezzel sem megyünk sokra a várható élettartam meghatározásánál.

A SMART PASSED azt jelenti, hogy a merevlemez vagy SSD beépített öndiagnosztikai rendszere sikeresen lefutott és a meghajtó jelenleg egészségesnek és működőképesnek minősül. A lemezt kiválasztva a show SMART values ki is listázza a jelentett adatokat. Ebből lehet csemegézni, ha valakinek eszébe jut és tudja is, hogy mit nézzen. A SMART ellenőrzés szolgáltatásként is fut, ellenőrzésre PVE konzolba írjuk be:
systemctl status smartd

Ha a szolgáltatás Active, akkor látjuk, hogy mikor lesz a következő teszt, az aktuális hőmérsékletek... de nem ezt keressük. A smartd előnye, hogy folyamatosan fut, 30 percenként (ez az alap, de módosíthatjuk) ellenőriz. Volt haldokló merevlemezem, sajnos ezzel sem mentem sokra, a lassú degradálódást nem tudja követni... A merevlemez csere környékén már felmerült az ötlet, hogy kellene folyamatosan vizsgálni és gyűjteni adatokat az állapotról.

Kép: Lovart.AI

Itt a logouton jelent meg egy script erre -sajnos már törölték-, ami az alapokat tartalmazta és nekiláttam a saját verziónak. Az elsőket jórészt én írtam, hátránya, hogy specifikusan erre a gépre szólt, csak /dev/sdX alapján voltak felsorolva a meghajtók. Kellett egy univerzálisabb, "bolondbiztos" script, ami túlél lemezcserét, betűjel változást és -akár- másnál is működne. Jöttek a bonyolultabb részek, ezzel már Claude AI-t is bevontam (Gemini ingyenes sajnos továbbra sem alkalmas hosszabb scriptek gyártására, de részfeladatokat jól hozott szintén). Lassan a smart_check.sh megszületett...

A mérete miatt a scriptet a githubon találjátok, a readme tartalmazza a telepítéshez, futtatáshoz az információkat.

Ezzel a heti ellenőrzést és logolást elintéztük. Crontab-ban a futtatás gyakorisága igény szerint módosítható, a heti elvileg jó kiindulás a degradálódás követésére. Az adatok elemzése más tészta, több lehetőség is van. Elküldhető Home assistantba, időnként megnyitni és nézni a végtelen számokat, bemásolni egy AI-nak és elemeztetni... Ezekkel az a probléma, hogy konkrét user beavatkozás kell, ami ha elmarad, akkor pont semmit nem érnek az adatok. Kellet még egy script...

smart_report.sh, crontab-ból havonta (ezt is lehet változtatni, ha sok órát futott már a vas, akkor a heti report sem probléma, ez nem terheli a lemezeket) elindítva összehasonlítja az utolsó négy értéket és jelez email-ben, ha valami bánat van készülőben. Ilyenkor már lehet a teljes logot feltölteni AI-nak, mellé egy aktuális smart eredménnyel és valószínűleg meg lehet határozni a hátralévő élettartamot is.

NAS gyors takarítása

Ez egy rövid kis script, ami a felesleges fájlokat eltakarítja a TARGET csatolási ponton. Ehhez kell néhány feltételnek teljesülnie, pl. a cél meghajtó (vagy mappa) elérhető kell legyen a PVE számára. Ezzel a VM-nek átadott lemezek kiesnek, ez csak a közvetlenül PVE-hez csatoltaknál járható út. Nálam Windows virtuális gép is fut, a felhasználói mappák egy külön SSD-n vannak, amiket az Alpine NAS LXC oszt meg a Windows 11 VM-nek. Ennek megfelelően oda generálódik némi törölhető fájl, amit az office vagy más program hagy hátra a temp mappában és mindenféle helyeken. A 30 napnál régebbi lomtár elemeket is törli, de a scriptben minden módosítható. Elvileg mentéskor is kihagyja ezeket a temp fájlokat, de szeretem, ha előtte ki van takarítva, mert pl. lomtárat egy az egyben menti és arra feltehetőleg nincs szükség.

Kép: Lovart.AI

Hozzuk létre a nas_cleaner.sh-t, nálam a scriptek a /root/script mappában vannak, de kinek mi...
nano /root/script/nas_cleaner.sh

Az üres fájlba másoljuk be:

#!/bin/bash
set +H
# --- KONFIGURÁCIÓ ---
TARGET="/mnt/ssd"
LOG_FILE="/root/log/nas_cleaner.log"
start_time=$(date "+%Y-%m-%d %H:%M:%S")
# --- 1. CSATOLÁS ELLENŐRZÉSE ---
# Csak akkor futunk neki, ha a lemez tényleg ott van
if ! mountpoint -q "$TARGET"; then
error_msg="HIBA: A meghajtó nincs csatolva a $TARGET pontra, a takarítás elmaradt!"
echo -e "Subject: Meghajtó takarítás HIBA\n\n$error_msg" | /usr/libexec/proxmox-mail-forward
exit 1
fi
{
echo "--- Takarítás indítva: $start_time ---"
# --- 2. ÁTMENETI FÁJLOK (1 napnál régebbiek) ---
# .tmp, ~$ kezdetűek és Thumbs.db törlése
find "$TARGET" -type f \( -name "*.tmp" -o -name "~$*" -o -name "Thumbs.db" -o -name ".thumb*" \) -mtime +1 -print -delete
# --- 3. TEMP és CACHE mappák ürítése (1 napnál régebbiek) ---
# Megkeresi a temp/cache mappákat és csak a bennük lévő fájlokat törli
find "$TARGET" -type d \( -iname "temp" -o -iname "cache" \) -exec find {} -type f -mtime +1 -print -delete \;
# --- 4. LOMTÁR ($RECYCLE.BIN) (30 napnál régebbi fájlok törlése) ---
if [ -d "$TARGET/\$RECYCLE.BIN" ]; then
find "$TARGET/\$RECYCLE.BIN" -type f -mtime +30 -print -delete
fi
end_time=$(date "+%Y-%m-%d %H:%M:%S")
echo "--- Takarítás kész: $end_time ---"
} >> "$LOG_FILE" 2>&1
# --- 5. LEVÉLKÜLDÉS ---
# Csak egy rövid összefoglalót küldünk a log végéből
stats=$(tail -n 6 "$LOG_FILE")
mail_body="A(z) $TARGET takarítása kész.
Kezdés: $start_time
Befejezés: $(date "+%Y-%m-%d %H:%M:%S")
Részlet a logból:
$stats"
echo -e "Subject: NAS Takarítás kész\n\n$mail_body" | /usr/libexec/proxmox-mail-forward

Ehhez is kell a mail forward, amin keresztül a PVE tud nekünk emali-t küldeni. A futtatását crontab-ra bízzuk és ennyi:
crontab -e

A végére másoljuk be ezt:
# NAS takarítása (hétfő és péntek)
30 3 * * 1,5 /root/script/nas_cleaner.sh > /dev/null 2>&1

A scriptünk hétfőn és pénteken 3.30-kor lefut (pár sec az egész), az ütemezett mentések csak ezután indulnak (szintén crontab+script kombóval). Manuálisan is futtathatjuk/tesztelhetjük. Ha szintaktikai hibát ír, akkor az a windows vs unix sortörések miatt van 99%-ban. Futtassuk ezt:
sed -i 's/\xc2\xa0/ /g' nas_cleaner.sh

Ne felejtsünk el logrotate-t létrehozni:
nano /etc/logrotate.d/nas_cleaner

Másoljuk bele ezt:
/root/log/nas_cleaner.log {
weekly
rotate 12
compress
missingok
notifempty
}

Mentés, bezárás. Ez 12 heti logot őriz meg, több, mint elég.

Mappák mentése belső tárhelyre

Az oldal címénél már elakadtam. NAS mappák mentése? Az. SMB megosztások mentése? Az is. De ha PVE oldalról nézem, akkor ezek "mezei" mappák, amiket egy NAS-nak becézett LXC oszt meg Samba segítségével, de ez a része a script számára teljesen lényegtelen...

Nálam bind mount az összes adat meghajtó, így a PVE sajátjaként látja őket. Ez leegyszerűsíti a mentések készítését: a samba megosztások tartalmát rsync-el egy nem megosztott meghajtóra másolom néhány naponta. Otthoni homelab, nincs hatalmas adatmozgás, a gyakoriságot mindenki beállíthatja igény szerint.

A másolás növekményes, ha végzett, akkor proxmox mail-forward-al jön róla email. A mentések első lépcsőfoka ez csak (legyen egy második példány instant elérhető). Mivel ez nincs megosztva, a következő mentésig nem fog változni: lehet tömörítve felhőbe küldeni darabokban, vagy menteni a mentést (ez gyönyörű lett, könnyezem) külső meghajtóra további másolatként.

Kép: Adobe Firefly

A kezdetleges és jóval egyszerűbb scripttel már kb. 2 éve mentegetek, folyamatosan bővült. Claude AI segítségével kapott egy kis finomhangolást és proxmox-mail-forward-ot is. Qwen3 extra biztonsági ellenőrzéseket javasolt, Gemini az én lassú tárhely ellenőrző megoldásomat cserélte le... Azért maradt benne a mappaneveken túl az eredetiből is, bár már csak hunyorítva hasonlít a kb. 15 soros ősére. A mentések és a logok rotálása a scripten belül történik. Több ilyen scriptem van, más-más forrás- és célmeghajtókkal, a futtatásuk crontabbal elosztva, hogy ne egyszerre és ne sokáig terhelje a rendszert. Nálam ez a backup2 script, lehet más neve is természetesen. Próbáltam kommentelni, hogy mi és miért került oda, remélem átlátható még.
Githubon is elérhető, letöltéshez van egysoros parancs és van ott is egy rövidített útmutató.

A Te rendszeredre alakítása a # Konfiguráció rész változóinak az átírásával oldható meg. Ha bizonytalan lennél, akkor Claude AI. PVE konzolból az elérési utat a forrás és a cél mappádhoz, illetve a scriptet is bemásolod Claude vagy Qwen3 chat-be és megkéred, hogy ez alapján frissítse. Csak a forrás és a cél ne legyen megcserélve Mert egy régi mentést helyreállítani a friss adatokra... nem szerencsés. Ha a véletlenül visszaállított mappa a feleségedé volt... akkor bajban vagy.

nano backup2.sh

Másoljuk bele a következőt:
#!/usr/bin/env bash
# felkiáltójeles mappák kezelése, előzmény-kiterjesztés kikapcsolása
set +H
# biztonsági kapcsolók, elírt változó, pipeline hibák esetére
set -uo pipefail

# Konfiguráció
# a forrás meghajtó csatolási pontja (ellenőrzéshez)
source_mount="/mnt/ssd"
# forrás mappa, amiben a menteni kívánt mappák vannak
source="/mnt/ssd/"
# mappanevek, amiket almappákkal, fájlokkal menteni szeretnénk
folders=("Tomi" "Viki" "Apa")
# ebbe a mappába mentünk majd (cél)
backup="/mnt/ssd_backup/NAS_backup/"
# a cél meghajtó csatolási pontja (ellenőrzéshez)
target_mount="/mnt/ssd_backup"
# log fájl helye
log_dir="/root/log"
# log fájlnév eleje
log_prefix="${log_dir}/backup2_"
start_time=$(date "+%Y-%m-%d %H:%M:%S")
# Log mappa létrehozása, ha nem létezik
mkdir -p "$log_dir"

# --- 1. HDD csatolás és mappa ellenőrzése (Forrás és Cél) ---
# Ha a forrás nincs csatolva, akkor leáll, nehogy az rsync --delete törölje a backupot!
if ! mountpoint -q "$source_mount"; then
error_msg="HIBA: A forrás meghajtó ($source_mount) nincs csatolva! A mentés megszakítva."
echo -e "Subject: Backup KRITIKUS HIBA - Forrás nincs csatolva\n\n$error_msg" | /usr/libexec/proxmox-mail-forward
exit 1
fi
if ! mountpoint -q "$target_mount" || [ ! -d "$backup" ]; then
error_msg="HIBA: A backup drive nincs csatolva, vagy a $backup könyvtár nem érhető el!"
echo -e "Subject: Backup HIBA \n\n$error_msg" | /usr/libexec/proxmox-mail-forward
exit 1
fi
# --- Cél meghajtó tárhely ellenőrzése ---
# foglalt méretet GB-ban, ~500 GB a meghajtó, 450 GB foglaltság felett ne kezdjen menteni
current_usage=$(df -m "$target_mount" | awk 'NR==2 {print int($3/1024)}')
limit=450
if [ "$current_usage" -ge "$limit" ]; then
error_msg="HIBA: A backup tárhely megtelt! Jelenleg: ${current_usage}GB. Limit: ${limit}GB. A mentés elmaradt!"
echo -e "Subject: Backup KRITIKUS HIBA - Tárhely hiba\n\n$error_msg" | /usr/libexec/proxmox-mail-forward
exit 1
fi

# --- 2-4. Ciklus a mappák mentésére ---
all_stats=""
error_occurred=0
for name in "${folders[@]}"; do
link="${backup}${name}"
sources="${source}${name}"
# Ha a forrás mappa nem létezik, lépés a következőre, nem áll le a mentés
if [ ! -d "$sources" ]; then
all_stats="${all_stats}\n--- ${name} ---\nHIBA: A forrás mappa ($sources) nem létezik!\n"
error_occurred=1
continue
fi
# Régi mentések forgatása (Hardlink-alapú inkrementális logika)
rm -rf "${link}.2"
[ -d "${link}.1" ] && mv "${link}.1" "${link}.2"
[ -d "$link" ] && mv "$link" "${link}.1"
# Log kezelés
cp -f "${log_prefix}${name}.log" "${log_prefix}${name}.1.log" 2>/dev/null || true
# Mentés (rsync)
# A --max-delete=500 megakadályozza, hogy egy véletlenül kiürített forrás mappa letörölje a teljes backupot.
if [ -d "${link}.1" ]; then
rsync -avh --delete --max-delete=500 \
--exclude='*.tmp' --exclude='~$*' --exclude='.trash*' \
--exclude='.thumb*' --exclude='Thumbs.db' \
--link-dest="${link}.1" \
"$sources/" "$link/" > "${log_prefix}${name}.log" 2>&1
else
# Ha még nem volt mentés (ez az első futás), akkor nincs mihez linkelni, sokáig fut...
rsync -avh --delete --max-delete=500 \
--exclude='*.tmp' --exclude='~$*' --exclude='.trash*' \
--exclude='.thumb*' --exclude='Thumbs.db' \
"$sources/" "$link/" > "${log_prefix}${name}.log" 2>&1
fi
rsync_exit=$?
# Hibakezelés: ha az rsync hibakóddal lép ki (pl. I/O hiba, vagy elérte a max-delete limitet)
if [ $rsync_exit -ne 0 ]; then
all_stats="${all_stats}\n--- ${name} ---\nFIGYELEM: Az rsync hibával zárult (kód: $rsync_exit)! Nézd meg a logot.\n$(tail -n 10 "${log_prefix}${name}.log")\n"
error_occurred=1
else
all_stats="${all_stats}\n--- ${name} ---\n"
all_stats="${all_stats}$(tail -n 3 "${log_prefix}${name}.log")\n"
fi
done

# --- 5. Statisztikák összegyűjtése az összes mappáról és levél összeállítása ---
end_time=$(date "+%Y-%m-%d %H:%M:%S")
# Újra lemezméret, hogy lássuk mennyit változott
final_usage=$(df -m "$target_mount" | awk 'NR==2 {print int($3/1024)}')
# Levél státuszának beállítása hiba esetén
if [ $error_occurred -eq 1 ]; then
subject="Backup FIGYELEM - Részleges hiba"
status_msg="A mentés során hiba lépett fel (lásd a statisztikát)."
else
subject="Backup kész"
status_msg="Mentés sikeresen lefutott."
fi
mail_body="Mentés kezdete: $start_time
Mentés vége: $end_time
$status_msg
--- Tárhely ---
A backup SSD-n jelenleg: ${final_usage} GB foglalt.
Összesített statisztika:
$all_stats"
echo -e "Subject: $subject\n\n$mail_body" | /usr/libexec/proxmox-mail-forward

Manuálisan is futtathatjuk/tesztelhetjük, de a forrás mappa méretétől függően az első mentés akár órákig is eltarthat. 100 GB mentésekor HDD-ről HDD-re, kis fájlokkal, töredezett fájlrendszerrel az első mentés akár 2,5 óra is lehet. Ha a forrás SSD, a cél HDD, akkor 30-60 perc. SSD-ről SSD-re 100 GB kis fájlnak csak 20 perc kell. Szal. semmi pánik, ha az első futása "végtelen történet".

Kis módosítással több forrás meghajtót és több másolandó mappát is tudna kezelni... de ott probléma lehet, hogy ha sokáig fut, akkor ütközik mással. Ezért több ilyen backup scriptem van, minden ment egy kicsit, gyorsan, más-más időpontban.

Ha szintaktikai hibát ír, akkor az a windows vs unix sortörések miatt van 99%-ban. Futtassuk ezt:
sed -i 's/\xc2\xa0/ /g' backup2.sh

Crontabban keressünk neki egy megfelelő időpontot:
crontab -e

Adjuk a végéhez ezt (illetve módosítsa mindenki a szokásai szerint):
# user mappák mentese (Csutortok 04:00)
20 4 * * 4 /root/script/backup2.sh > /dev/null 2>&1

Mentsük el, ezzel készen is vagyunk. Logrotate a scriptben, tesztelés és kész.

Mentés USB külső meghajtóra

Szintén egy rövid, "bolondbiztos" script - mert a külső meghajtók kezelése Proxmoxon kicsit más,
mint a desktop linuxokon. Nekünk ebből csak annyit elég tudnunk, hogy PVE-n nincs automatikus csatolás (megoldható természetesen ez is, ha valakinek erre van igénye), asztali linuxokon a külső meghajtó a /media/akármi mappába kerül automatikus csatolásra.

Itt egy meglévő (akár fájlokkal teli) lemezt csatolunk most, skippeljük a formázást. Proxmoxon az USB meghajtókat fstab-al (van más opció is, systemd és webUI csatolás, de az fstab a jó ehhez) tudjuk csatolni. Ehhez kell nekünk a lemez UUID-je, egyedi azonosítója. A külső lemezt csatlakoztassuk, majd
blkid
parancs, amire lesz egy hosszú lista... Legjobb, ha kimásoljuk a teljes kimenetet jegyzettömbbe és kitöröljük, amiről biztosan tudjuk, hogy nem a külső lemez. Ebben a PVE disks oldala segít.

A blkid listából a /dev/mapper, /dev/loop és /dev/nvme kezdetűek biztosan kiesnek. Aminek csatolási pontja van a disk oldalon (sda, sdb, nvme...) az is kiesik, mert a külső meghajtónak ez nincs. A maradék lesz a meghajtónk sora. Ha bizonytalanok vagyunk, akkor csak le kell húzni, újra blkid parancs és ami hiányzik,
az a mi külső lemezünk.

A lemez UUID-ja a fájlrendszer létrehozásakor (gyors vagy teljes formázáskor) generálódik. Vannak olyan parancsok, amikkel a fájlrendszer törlése vagy formázása nélkül is meg lehet változtatni és van olyan parancs is, ami formázás ellenére is megtartja az azonosítót.

Nálam ez:
/dev/sdd1: UUID="99d6ac0f-c0c4-41e4-b6d9-fec5fa0ce26d" BLOCK_SIZE="4096" TYPE="ext4" PARTLABEL="Basic data partition" PARTUUID="0000fb07-ddd0-1c94-f98e-da010ef60100"

A következő lépés, hogy létrehozzuk a csatolási pontot Proxmoxon, ehhez a PVE konzolba írjuk be:
mkdir /mnt/external_hdd

A csatolásokat ajánlott az /mnt-n belül létrehozni, a mappa neve bármi lehet, de ha sok csatolás lesz, akkor jobb, ha a nevéből tudjuk, hogy mi is az.

A jogosultság problémákat megelőzni:
chown nobody:nogroup /mnt/external_hdd
Senki nem tulajdonos, semmilyen csoporthoz nem tartozik. Ez mindenhol ugyan az.
Előfordulhat, hogy az fstab csatolásunk nem csatolódik valamiért, ilyenkor ha valami írni akar a mappába, akkor az a Proxmox meghajtójára íródik. A meghajtó vagy a partíció betelhet, nincs boot és az nem jó.
Ezért ez a mappa legyen Immutable (nem módosítható):
chattr +i /mnt/external_hdd

Ezután ha a merevlemezt nem sikerül csatolni, akkor a mappa írásvédett marad. Ha ide mentenénk vagy másolnánk, akkor hibára futunk. Cserébe nem tudjuk teleírni a meghajtót.
lsattr -d /mnt/external_hdd
Ezt kell látnod: ----i---------e---- /mnt/external_hdd
Az az i betű az elején jelzi, hogy a mappa immutable lett.

Következik az fstab módosítása, ahol megadjuk a rendszernek, hogy melyik lemezt és hova kell csatolnia:
nano /etc/fstab

Itt a végére, új sorba adjuk meg a lemezünket, a csatolási pontot és még pár dolgot:
# external Toshiba 750 GB
UUID=99d6ac0f-c0c4-41e4-b6d9-fec5fa0ce26d /mnt/external_hdd ext4 defaults,noatime,noexec,nodev,nosuid,noauto,nofail 0 0

Természetesen a Te rendszeredhez igazítva, a Te meghajtód UUID azonosítójával kell hozzáadni. Az UUID után megadjuk a csatolási pontot, majd a fájlrendszer típusát, végül néhány paraméter:
Biztonsági opciók: a nodev, nosuid, noexec. Nálam ide mentések kerülnek, ezeket inkább tiltom. Részletesen a korábbi logout bejegyzésben írtam ezekről.
noatime: teljesítmény-optimalizálás, időbélyegeket nem ír. SSD-nél szinte kötelező, nálam ez backup lemez, nem igénylem. Kihagyható.
nofail: ha lemezhiba van (eltávolítottuk a lemezt, vagy "csak" haldoklik), akkor ezzel a kapcsolóval a boot nem akad meg. Próbálgatja csatolni, majd halad tovább. Kihagyható, de ajánlott a használata.
noauto: Ez viszont nem kihagyható... A Proxmox induláskor átugorja a lemezt, nem akad fenn akkor sem,
ha nincs csatolva. A mentős külső lemezt nem is szeretném a gépre dugva tartani, annak egy "mindent visz" táphiba esetén nem sok haszna lenne. Illetve a boot folyamatot sem lassítja egy USB-n döcögő külső lemez csatolásával.
Még pár parancs kell:
ctrl+x # kilépés nano-ból
Mentés kérdésre egy y és enter, majd
systemctl daemon-reload

Nos, a nagy részével készen is vagyunk. Kell egy script, nálam ez a /root/script mappába kerül - githubról a parancs csak a /root-ba menti, az elérésre a crontabban szükségünk lesz, érdemes szerintem az ilyesmiket egy mappába gyűjteni. A feladata az lenne, hogy amikor a crontab elindítja, akkor próbálja csatolni a külső merevlemezt. Ha nem találja az nem hiba, lépjen ki. Ha megtalálta, akkor csatolja a létrehozott /mnt/external_hdd mappába és a belső meghajtón a mentéseket másolja át a külső meghajtóra is.

Közben a folyamatot egy saját fájlba logolja, ez a /root/log/external_sync.log fájl lesz és küldjön egy rövid összefoglalót email-ben a mentésről. A meghajtót le is kell választania, mintha ott sem lett volna...
nano /root/script/external_sync.sh

Új file, másoljuk bele ezt (alternatívaként githubról is letölthető, a readme utasításban a parancs hozzá):
#!/bin/bash
set +H
set -uo pipefail

external_mount="/mnt/external_hdd"
source_backup="/mnt/ssd_backup/NAS_backup/"
dest_backup="/mnt/external_hdd/NAS_backup/"
start_time=$(date "+%Y-%m-%d %H:%M:%S")
log_file="/root/log/external_sync.log"

# HDD csatolás - ha nincs bedugva, csendben kilép
mount "$external_mount" 2>/dev/null
if ! mountpoint -q "$external_mount"; then
exit 0
fi

# Szinkronizálás
rsync -avh --hard-links --delete \
"$source_backup" "$dest_backup" \
> "$log_file" 2>&1

exit_code=$?

end_time=$(date "+%Y-%m-%d %H:%M:%S")
ext_usage=$(du -sh "$external_mount" 2>/dev/null | awk '{print $1}')

if [ $exit_code -eq 0 ]; then
subject="External Backup kész"
status="Szinkronizálás sikeresen lefutott."
else
subject="External Backup HIBA"
status="HIBA: rsync hibakóddal zárult: $exit_code"
fi

log_tail=$(tail -n 5 "$log_file")
mail_body="Mentés kezdete: $start_time
Mentés vége: $end_time
$status
--- Tárhely ---
Külső HDD foglalt: $ext_usage
--- Összefoglaló ---
$log_tail"

echo -e "Subject: $subject\n\n$mail_body" | /usr/libexec/proxmox-mail-forward

# HDD leválasztás (biztonságos eltávolításhoz)
umount "$external_mount"

Mentés és futtathatóvá tétel:
chmod +x /root/script/external_sync.sh

Ehhez is kell a PVE-ben beállított mail forward, a futtatását crontab-ra bízzuk:
crontab -e

A végére másoljuk be ezt:
# Külső HDD szinkronizálás (minden nap 05:00)
20 5 * * * /root/script/external_sync.sh > /dev/null 2>&1

Nézzük részletesebben az rsync parancsot, ami a lényeget adja:
rsync -avh --hard-links --delete \
"$source_backup" "$dest_backup" \
> "$log_file" 2>&1

-a (archive): ez a legfontosabb gyűjtőkapcsoló, ami biztosítja, hogy a másolat mindenben megegyezzen az eredetivel. Rekurzívan a mappastruktúrát is megtartja, illetve a jogosultságokat, a tulajdonost/csoportot, a szimbolikus linkeket és az időbélyegeket is.
-v (verbose): Részletes kimenet. Kilistázza a terminálban (vagy a logban), hogy éppen melyik fájlt másolja vagy ellenőrzi.
-h (human-readable): A számokat (pl. fájlméretek, átviteli sebesség) jól olvasható formátumban (KB, MB, GB) jeleníti meg.
--hard-links: ez a kapcsoló megtartja a forrásmappában (pl. korábbi mentésekből adódóan van néhány) található hard linkeket. Elengedhetetlen a kis fájlmérethez, mert így ha a forrásnál hard link van, akkor azt másolja és nem a linkelt fájlt.
--delete: ha a forrásban törölve lett egy fájl, akkor azt a mentésből is törli. Sikerült még régebben egy "delete" nélküli mentést visszaállítanom, amiben a kiválogatásra váró fájlok is megvoltak és a már válogatott mappák is... Hát nem voltam megdicsérve.
A log része a kimenetet irányítja át a script elején megjelölt fájlba.

A script minden hajnalban lefut, ha nincs a külső lemez csatlakoztatva, akkor csak kilép. Ha a lemezt csatlakoztattuk fizikailag, akkor egy növekményes mentést csinál. A mentési metódus miatt az első az nem lesz gyors... utána a változásokat menti csak. Tehát ha pl. családi fotókat vagy más, nem folyamatosan változó adatot mentenénk, akkor a változások követése gyors lesz, de az első mentést ki kell várni.

Ne felejtsünk el logrotate-t létrehozni ehhez is:
nano /etc/logrotate.d/external_sync.log
Másoljuk bele ezt:
/root/log/external_sync.log {
weekly
rotate 5
compress
missingok
notifempty
}

Mentés, bezárás. Ezzel 5 heti logot őrizgetünk, bőven elég szerintem, de módosítsd, ahogy tetszik.

Alpine, Debian/Ubuntu LXC és a PVE frissítése egyszerűen

A Proxmox helper scripts oldalon rég fent van és sokáig használtam is a "PVE LXC Updater" scriptet az LXC-k frissítésére, majd kiegészítettem pár alap paranccsal, hogy a PVE frissítés is fusson le az LXC frissítése után. Később journal mérettel, grub frissítéssel, trimmel és még pár aprósággal bővült.

A homelabom átalakult közben, a Debian LXC helyett Alpine lett, ezt nem kezelte a helper script, ahogy a docker frissítéseket sem. Amiket sikerült belegyúrni: PVE konzolból indítva a futó Alpine és Debian/Ubuntu LXC-ket frissíti. A leállított LXC-ket nem indítja el és nem is frissíti (a helper oldalon a script ezt tudja, de nekem ez jobb így). Frissítés után az LXC-ben törli a 7 napnál régebbi logokat, a temp- és cache fájlokat. Semmi erőltetett törlés, nem akasztja meg a futó folyamatokat. Dockereket frissíti és takarítja, a "gazdátlan", nem hivatkozott image-okat törli, de a futó, vagy csak leállított dockereket nem piszkálja.

Kép: Lovart.AI

Ezután egy trim parancs is lefut (megfelelően konfigolt PVE és LXC esetén erre nincs szükség, de nem árt). Listázza a hibás vagy hiba miatt leállt szolgáltatásokat, ha vannak. Nem javítja -ilyesmivel nem is próbálkoztam-, de a logba bekerül és lehet kutatni az okok után. Ha az LXC-k készen, akkor lefut PVE-n az apt update, upgrade és az autoremove. A dist-upgrade kihagyása szándékos, az figyelmet kíván: az allupdate.sh után lehet futtatni, ha indokolt.

Mérete miatt ezt is Githubon találjátok, Angol-Magyar útmutatóval együtt.

Köszönöm, hogy benéztél. Ha hibát találtok vagy kiegészítés lenne hozzá, azt jelezzétek és javítom.