Szeretném megköszönni a segítőkész embereknek, hogy elláttak jótanácsokkal. Külön köszönet a zstd beküldőjének, több mint 7-szeres a sebesség, és jól is tömörít.
Összeraktam ollóztam és módosítottam az iRedMail mentő scriptet. Ha valaki bármilyen optimalizálást hibát vagy bármit tud az ne tartsa magába. Némi magyarázattal fűszerezve kérem szépen.
Van egy aggasztó rész, ami a régebbi biztonsági másolatokat törli, ott az a fránya rm -rf. Megfelelőek a paraméterei, de ha valaki biztonságosabbá tudja tenni, az írja le kérem. Ettől engem ráz a hideg.
Frissítem a topikot, a neve az lesz hogy iRedMail backup. Más cím javaslatok is jöhetnek.
Köszönök mindent.
A backup.txt fájlt még bővítem.
Csomag függöség alap telepítésen felül certbot és zstd.
backup.txt
# CRLF érzékeny a tar, ezért a sorok végén csak LF lehet!
# Egyéb domainek DKIM aláírásai miatt módosult
/etc/amavis/conf.d/50-user
# DKIM kulcsok
/var/lib/dkim
# Let's Encrypt
/etc/letsencrypt
/etc/ssl/certs/iRedMail.crt
/etc/ssl/private/iRedMail.key
# Alapértelmezett email könyvtár
/var/vmail/vmail1
backup_iredmail.sh
#!/usr/bin/env bash
export PATH='/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/sbin'
# Ennyi napig nem törli az előző biztonsági másolatotokat.
# Az alapértelmezett nap 3.
KEEP_DAYS='3'
# Törölje a régi biztonsági másolatokat? YES ha igen.
export REMOVE_OLD_BACKUP='NO'
# Hol tárolja a biztonsági másolatokat.
export BACKUP_ROOTDIR="/home/backup/iredmail"
# Dátum. A biztonsági másolat fájl nevéhez és az adatbázis biztonsági másolat
# könyvtárai eléréséhez szükséges.
export CMD_DATE='/bin/date'
export YEAR="$(${CMD_DATE} +%Y)"
export MONTH="$(${CMD_DATE} +%m)"
export DAY="$(${CMD_DATE} +%d)"
# Az adatbázis biztonsági másolatokat könyvtárai.
# Ezt az iRedMail 3 óra 1 perc és 4 óra 1 perckor hozza létre.
export DATABASE_BACKUP_ROOTDIR="/var/vmail/backup"
export POSTGRESQL_BACKUP_DIR="${DATABASE_BACKUP_ROOTDIR}/pgsql/${YEAR}/${MONTH}/${DAY}"
export SOGO_BACKUP_FILE="${DATABASE_BACKUP_ROOTDIR}/sogo/${YEAR}/${MONTH}/${DAY}.tar.bz2"
# Biztonsági mentés mappa
export BACKUP_DIR="${BACKUP_ROOTDIR}/${YEAR}/${MONTH}/${DAY}"
# Mappa ellenőrzés, ha nem létezik létrehozza.
[ ! -d ${BACKUP_DIR} ] && mkdir -p ${BACKUP_DIR} 2>/dev/null
# Log fájl
export TIME="$(${CMD_DATE} +%H-%M-%S)"
export TIMESTAMP="${YEAR}-${MONTH}-${DAY}-${TIME}"
export LOGFILE="${BACKUP_DIR}/${TIMESTAMP}.log"
# Log fájl inicializálás
echo "* Starting at: ${YEAR}-${MONTH}-${DAY}-${TIME}." >${LOGFILE}
echo "* Backup directory: ${BACKUP_DIR}." >>${LOGFILE}
# Fájl, ami tartalmaza a menteni kívánt fájlokat és könyvtárakat.
export BACKUP_FILE='backup.txt'
# Biztonsági másolat státusza
export BACKUP_SUCCESS='YES'
if [ X"$?" == X'0' ]; then
# Virtuális gépen 2 VCPU esetén a -T1 az optimális
time tar -I "zstd -T1 -1" -cf ${BACKUP_DIR}/iredmail.tar.zst --exclude='#*' -T ${BACKUP_FILE} ${POSTGRESQL_BACKUP_DIR} ${SOGO_BACKUP_FILE} >>${LOGFILE}
else
export BACKUP_SUCCESS='NO'
fi
# Fájl méret hozzáfűzése a log fájlhoz.
export CMD_DU='du -sh'
echo -e "* File size:\n----" >>${LOGFILE}
cd ${BACKUP_DIR} && \
${CMD_DU} *zst >>${LOGFILE}
echo "----" >>${LOGFILE}
# Biztonsági másolat státusz hozzáfűzése a log fájlhoz.
echo "* Backup completed (Success? ${BACKUP_SUCCESS})." >>${LOGFILE}
# A biztonsági másolat befejeztével emailben érkeznek ezek az adatok.
if [ X"${BACKUP_SUCCESS}" == X'YES' ]; then
echo -e "\n[OK] Backup successfully completed.\n"
else
echo -e "\n[ERROR] Backup completed with ERRORS.\n" 1>&2
fi
# Régi bizonsági másolat könyvtárak.
shift_year=$(date --date="${KEEP_DAYS} days ago" "+%Y")
shift_month=$(date --date="${KEEP_DAYS} days ago" "+%m")
shift_day=$(date --date="${KEEP_DAYS} days ago" "+%d")
export REMOVED_BACKUP_DIR="${BACKUP_ROOTDIR}/${shift_year}/${shift_month}/${shift_day}"
export REMOVED_BACKUP_MONTH_DIR="${BACKUP_ROOTDIR}/${shift_year}/${shift_month}"
export REMOVED_BACKUP_YEAR_DIR="${BACKUP_ROOTDIR}/${shift_year}"
# Régebbi biztonsági másolatok törlése
if [ X"${REMOVE_OLD_BACKUP}" == X'YES' -a -d ${REMOVED_BACKUP_DIR} ]; then
echo -e "* Old backup found. Deleting: ${REMOVED_BACKUP_DIR}." >>${LOGFILE}
rm -rf ${REMOVED_BACKUP_DIR} >> ${LOGFILE} 2>&1
rmdir ${REMOVED_BACKUP_MONTH_DIR} 2>/dev/null
rmdir ${REMOVED_BACKUP_YEAR_DIR} 2>/dev/null
fi
# A biztonsági másolat befejeztével emailben érkeznek ezek az adatok.
echo "* Backup log: ${LOGFILE}:"
cat ${LOGFILE}
Hozzászólások
Oke, este van, de en nem ertem a feladatot.
Van egy file lista, ezt betarolni nem gond, feltolteni sem.
Mit akarsz a konyvtarlistaval? Es az adatbazis tabla nevekkel? Tar-olni lehet a konyvtarakt is. A tablakat eloszor ki kene dumpolni imho.
De ha mindez egyszerre kell, akkor a szivas a konzisztenciaval lesz, mert mig csomagolod a dumpolt tablat, addig jon egy uj file az alkonyvtarba, de arra mar nem lesz hivatkozas, vagy valami hasonlo, nem ertek az iRedMail -hez, csak tippelek.
Szoval service stop, adatbazis es alkonyvtarak nem modusulnak, masolas, service start.
Ezt lehet gyorsabban es veszelyesebben service stop, sync, lvm snapshot, service start, masolasok, snapshot delete -el csinalni, de akkor ugy kell kialakitani hozza a tarhelyet .
Amugy tar helyett javaslom az xz -t.
Szerintem az xz tömörít, a tar pedig egy file-ba archivál komplett könyvtár struktúrát, sok file-t, s mindeközben, de nem feltétlenül tömöríteni is tudja ezt, akár xz-vel is:
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
És azt meg lehet oldani hogy egy csövön rögtön sftp szerverre feltöltse, vagy szükséges lokálban tárolni majd feltölteni? Tételezzük fel hogy nem szakad meg a kapcsolat a két pont között.
Részet a tar manualjából:
Tehát meg lehet csinálni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Köszönöm, akkor már csak shell mágus kell aki példát ír fájlra és könyvtárra némi magyarázattal. Meg még sok minden kell, de ez már egy alap lehet.
Az egész topic-kal az a bajom, hogy valójában nem segítséget kérsz, hanem felvetettél egy problémát, igazából meg sem fogalmaztad a pontos specifikációt, nem algoritmizálod a feladatot, hanem vársz egy vagy több balekra, akik megoldják neked. Amikor a tar dolgairól volt szó, akkor is egyetlen paranccsal - man tar - vagy netes kereséssel megtudhattad volna a választ, ehelyett inkább megvártad, amíg én megkerestem. Pedig én sem tudtam fejből.
Nem a kérdéssel van önmagában baj, hanem azzal, hogy a magad részéről semennyi erőfeszítést sem teszel. Így viszont nem együtt gondolkodás, segítség lehet ebből, ha egyáltalán, hanem egy lelkes balfácán kihasználása, ami azért cseppet sem etikus.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Elsőként szeretném megköszönni, hogy kifejtetted a véleményed az első mondathoz, és kiegészítetted a véleményeddel. Nagyra értékelem.
Továbbá van a főoldalon egy dátum kivágós ugyancsak script kérdés, ahol lelkesen segítettek az emberek. Megnéztem mit produkáltál ott, de a hozzászólásaid ott se vitték előre a megoldást. Ez egy ilyen hely, van aki csak beleírogat, és van aki segít. De szívesen olvasom amit írsz.
Kettőnk között van egy filozófiai különbség. Te halat adnál az éhezőnek, én hálót, amellyel megtanul halat fogni. Annál is inkább, mert én tanítottam középiskolában. Szerinted mennyit tanulnának abból a diákok, ha felírnék egy feladatot a táblára, majd saját szórakoztatásomra meg is oldanám? Ettől képessé válnak problémamegoldásra?
Ha megfigyeled, az általad hivatkozott topicban írtam, hogy például az x=$((${x}+1)) kifejezés helyett célszerű a C szintaxishoz hasonlító és egyszerű ((x++)) alak használata. Ezekből lehet tanulni. Abból nem, ha valaki kész megoldást szállít, megírja helyetted.
Te is lehetsz Bash expert, javasolom tanulmányozásra ezt a dokumentációt, szerintem nagyon jó.
Szerk.: annál is inkább rosszul jön ez ki, mert nyilvánvalóan tudsz programozni az adatlapod alapján, aztán mégis csinálja más...
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Sajnos van egy olyan irányzat, hogy az a legfontosabb csak, hogy az éhes csak jóllakottnak, vagy kevésbé éhesnek találja magát. Azaz se halat nem ad, se nem tanít meg halat fogni. Képzeld, akár mennyire hangzik hajmeresztően, működik! Egyre hosszabb távolságig képesek elhinni az éhesek, hogy valójában ők csak képzelték hogy éhesek.
(egyébiránt erről a témáról ugyanaz a véleményünk. "adj halat de gyorsan" topic)
Csak ne hoztad volna már megint ide a politikát! :D
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Létrehozol egy pipe-ot (
mknod csovem p
), azt feltöltöd sftp-vel (put), ekkor a feltöltés még nem indul el, hanem vár arra, hogy egy másik síkon írjál a pipe-ba. Na ezen a másik síkon lesz atar -czf csovem ...
Ezt nem értem. Mi az, hogy másik síkon? Van egy pipe-od, az egyik végébe tolod az adatot, a másikból olvasod. Abban igazad van, hogy ha a program nem tudja, ez akkor is megoldható, hiszen a pipe lényegében file-ként látszik.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Mondjuk egy másik virtuális terminálon. Vagy az sftp-t háttérbe küldjük (bg), amíg a fájl megírása tart.
Oké, természetesen elkészül az adatbázisok dump. Ez több fájl. Bekerül egy könyvtárba. Innentől kezdve ez is csak könyvtár. Menthető. Az adatbázisban nincs hivatkozás a fájlokra. iRedMail-nél speciel nincs, de máshol előfordulhat. Ez nehezebb eset. Megnéztem az iRedMail táblákat és nincs bennük dátum, hogy a teljes mentés után a kezdés és vég dátum közötti időre futtasson egy incrementált hogy ne legyen gond vagy hiány, de ezt meg tudom oldani, rakok minden táblába létrehozás dátumot auto kitöltéssel, és akkor lehet ellenőrizni.
Mit akarok a könyvtárakkal. Van olyan eset, ahol csak bizonyos fájlokat kellene menteni könyvtárakból, visszaállításnál nem írható felül, ami még ott van. Pl egy teljes új telepítés után csak kicsomagolom a mentést és működik. Van ahol a teljes könyvtárat menteni kell.
Csak egy kérdés, hogy ezt nézted-e már?
https://docs.iredmail.org/backup.restore.html
Köszönöm szépen, igen néztem és használtam is amkor 3 hónapja összeomlott a levelezés, manuálisan lementettem mindent. Voltak ezen kívül egyéb konfigurációs fájlok és tanúsítványok amit menteni kellett, de az elmélet amit itt felvetettem működött. Ezért is szeretném automatizálni, hogy más is használhassa. Új telepítés után csak kicsomagoltam a mindent és hiba nélkül működött elsőre. Ráadásul mysql volt és postgres-re tértem át, még az sql mentést is migráltam.
A tar-hoz ez még jól jöhet:
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Sajnálatos módon, az ahol van a backup sftp, az kizárólag és csak is sftp. Nincs lehetőség semmi másra, így a fenti ajánlásod sajnos ide (nekem) nem jó.
A --rsh-command paraméter nem épp erre való? Szerintem a tar azt is megengedi, hogy ha írsz egy saját átviteli protokollt, akkor azt a programot használd.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Amit csináltál, az járható, hiszen argumentumként a shell felsorolja a tar-olandó file-okat, viszont erre a tar-nak van beépített megoldása, nem kell a shell szolgáltatása hozzá:
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Teljesen jól megoldottad egyedül. Annyi, hogy a $(cat blabla) résznél a cat után több fájlt is fel lehet sorolni, pl. $(cat fájlok.txt mappák.txt adattáblák.txt), a cat pont arra való, hogy többféle adatot, fájlt úgy tud összeömleszteni, összefűzni, mintha csak egy fájl, egy adatfolyam lenne.
Annyi, hogy én a tgz helyett zstd használatát ajánlom, lehetőleg több szálon, irgalmatlanul gyors, állva hagyja a gzip-et és a többi megoldást, és kicsivel jobban is tömörít. Pl.:
tar -I "zstd -T0 -1" -cvf blabla.tar.zst $(cat fájllista)
A -I (nagy i) azt adja meg a tar-nak, hogy külső tömörítőt használjon, a -T0 azt, hogy az összes elérhető prociszálat használja, a -1 a tömörítési fok (1 és 19 között), ezzel játszhatsz, hogy mennyire akarod a mentést betömöríteni. Ahogy meglátod, hogy mennyivel gyorsabb, mint a gzip, le fogsz menni hídba, azt garantálom. Szóba jönne még az lz4 is, de az csak egy szálon gyorsabb, több szálat még nem támogat, és rosszabbul is tömörít, mint a gzip.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Érdekes ez a -T, mert attól függ a jelentése, hova írod. Van neki ilyen jelentése is: -T, --files-from=FILE
Ez pedig épp annak a nem túl szép cat-os dolognak a szebb megoldását teszi lehetővé.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A jelentése attól függ, hogy a zárójeles (külső tömörítős) részbe írod-e, mert akkor a zstd parancs kapja meg, annál a T=thread. Ha a zárójeles részen kívülre írod, akkor a tar parancs kapja meg, és valóban, azt csinálja, amit írsz, meg amit a topiknyitó akarna.
Elvileg működik a tar -I helyett a tar --zstd is, ez rövidebb, csak ilyenkor meg nem biztos, hogy így meghívva a zstd használni fog 1-nél több szálat. Azért ha több magos, SSD-s gép, több szálon durván begyorsul a tömörítés, ha nem fog valami I/O meg cache bottleneckbe, akkor lineárisan skálázódik a szálakkal, I/O sebességgel. Arra még felhívnám a figyelmet, hogy a -I ilyen értelmű használata tar-nál egy GNU bővítés, az eredeti POSIX kompatibilis BSD tar, pl. más értelmeben használja ezt a kapcsolót, annál -I = -T jelentésben áll.
Egyébként meg ezt lehet tar nélkül is, mármint amit a topiknyitó akar, pl. beállít cron-feladatot vagy systemd service-t, és az x időnként lefuttat egy felparamtérezett rsync parancsot, ami meghatározott mappákat átküldi a másik szerverre, és ott meg a fájlrendszeren bekapcsolható transzparens tömörítés, így kb. ugyanott van az ember. Ez a szép a unixlike rendszerekben, hogy egy problémára többféle megoldás is van, egyiknek ez, másiknak az lehet az előnye, és nincs az, mint a mainstream, proprietary rendszereken, hogy mindenkire egy megoldás van ráerőltetve, mint „sztenderd”. Akár még az is lehet, hogy a rendszeresen menteni kívánt mappákat, fájlokat egy külön btrfs-s volume-on tartani, és arról x időnként automatizált snapshot készíthető, és btrs-en a transzparens röptömörítés is beállítható.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Én voltam figyelmetlen, bocs. Az a -T0 valóban nem a tar paramétere.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Köszi, ezt a tömörítést le fogom tesztelni, mert
~6GB13GB amit mentenem kell (majd megosztom az eredményt) és már azt is látom hogy csak 1x 1 héten, mert megtaláltam aparamétert és a használati módját.
Szóval a híd garantált köszi. 3x futtattam le mind a két módot mert nem hittem el és döbbenet a különbség. Szinte kínos kivárni a gzipet.
A gép egy virtuális gép 4GB RAM 2VCPU.
zstd
gzip
Még ugyanezt multithreading nélkül is próbáld ki (sőt, mivel servergépről van szó, akár a 'nice' opciónak is lehet realitása: egy darab mentés nem foghat le egy teljes szervert).
Ezt lefordítanád nekem futtatható parancsra? :-) Gőzöm sincs mi a nice opció.
Közben lefuttattam
zstd sftp mount-ra -T0 az 225 mp.
zstd local filesystem -T1 72 mp.
nice - run a program with modified scheduling priority
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Kérlek tedd félre az önérzetes oktatási módszeredet és a fenti scriptet kérlek egészítsd ki. Köszönöm.
Pl:
A gzip helyett meg nézz rá a pigz-re, a sebesség miatt. Ha meg jobban rámennél a tömörítésre:
Sőt, futásidőt mérni így is lehet:
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Nyilván lehetne azon a részen is javítani, de nem akartam refaktorálni a script-jét, csak minél tömörebben válaszolni a konkrét kérdésre. :)
Köszönöm, a parallel nálam nem jó, mert az 1 szálas zstd 72mp alatt fut le míg több szálon 89mp. Ezért a -T0 helyett -T1 van.
2x futtattam nice -n 13-al és nem is terhelte annyira a szervert és 70mp alatt lefutott. Ez így tuti lehet. 13 GB 70 mp alatt durva.
Ne haragudj, de bennem rossz erzest kelt egy ilyen mondatresz, hogy "... onerzetes oktatasi modszeredet ...".
Kaphattal volna annyi valaszt is, hogy RTFM, leven a kerdesedre a valasz osszesen egy google keresesnyi vagy egy man nice parancs kiadasnyi tavolsagban van toled.
Az ember szivesen segit, iranyba allitja a kerdezot, elmondja neki, hogy merre van a kozert, de helyette elmenni es bevasarolni senki nem akar puszira. Foleg, ha panaszkodik, hogy csak terkepet kap segitsegul, es nem fuvart.
Lehet, hogy nem sertesnek szantad a fenti mondatot, nekem olyan csengese volt. Ha szarkasztikusnak szantad, es csak lemaradt a smiley, akkor nem szoltam.
A probléma gyökere nem a szmájliban vagy annak hiányában keresendő!
Hát ez az! Ha egyszer nem értek hozzá, akkor meg kéne próbálni a feladatot egyszerűen megfogalmazni! Pl.: X rendszer szerenék menteni és a mentést távoli szerveren tárolni. stb.
Erre a Rutinos Rókák rögtön lökik a rutinos megoldásaikat, illetve felteszik az ilyen feladatokhoz szükséges járulékos információk megszerzésére irányuló rutinkérdéseket.
A "Milyen színnel írjam a tar parancsban az r betűt?" kérdés előtt még egy csomó dolgot kellene tisztázni. :-D
Szerintem ilyen parancsot kellene alkalmazni:
nice-szal is lehet, de sokkal elegánsabb, ha a szálak számát korlátozod. Akkor nem 0-t adsz meg a -T paraméter után, hanem annyi szálat, amennyit akarsz. Pl. ha 8 szálas a proci, akkor -T0 helyett -T4-et adsz meg, és kapásból csak fele annyi procit eszik majd.
A tömörítési fokkal is lehet játszani, az nem a prociterhelést érinti, de néha kitömörítésnél gyorsíthat, meg helyet takaríthat meg. Azt mondanom sem kell, hogy a zstd nem csak betömörítésnél gyorsabb, de ez az előnye megmarad kitömörítésnél is.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
2VCPU-m van, így T1 lett igy 72mp, míg ha visszaírom T0-ra akkor 89mp. A T1 az tuti és nem is terheli annyira a szervert.
Nem kell ez a komplikált date-elapsed megoldás. Egyszerűen csak írd oda a time parancsot a tar elé, ha benchmarkolsz.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Ja, először én is alig hittem a szememnek, hogy mennyivel gyorsabb bármi másnál. Eleinte azt hittem, hogy ez is csak egy feleslegesen hájpolt soydev tool, de tévedtem. Nem minden szar meg hype, ami népszerű. Sok embert elriaszt, hogy a Facebook jegyzi, de ez tévinformáció. Nem a Facebooknál fejlesztették, hanem létezett előtte is, egy Yan Collet nevű fejlesztő fejlesztette magánban, a FB csak megvette a technológiát, meg fizeti a fejlesztőt, de az továbbra is egyedül fejleszti, a FB-nál csak tesztelik, használják, de amúgy free opensource technológia.
Arch pl. nagyon durvát gyorsul, mióta zstd-vel tömörítik a csomagokat, és a pacman tud párhuzamos csomagletöltést (sajnos párhozamos csomagkitömörítést még nem tud). Állva hagyja az apt-ot meg a dnf-et.
Persze a gzip-nek is megmarad a felhasználási köre, a kompatibilitás. Pl. ha a tömörítvényeket nagyon muzeális, ergya gépeken, és régi OS-eken kell bontogatni, oda a zstd lehet nem lesz jó, de a gzip igen. Bár ilyen felhasználási körre meg lehet jobb info-zip-et használni, az teljesen pkzip kompatibilis, és nagyon windowsos normik is simán kibontják akármivel, akár a Windows beépített tömörítvénykezelőjével is, sőt, akár még FreeDOS, MS-DOS, stb. alatt is kibontható, az info-zip tud egyszerre több fájlt is tömöríteni, így még tar-se feltétlenül kell. Szóval én még ezeket sem írnám le, de mentés tömörítésére, modern rendszerre, normális szerverre jobb az zstd.
A gzipnek viszont az az előnye az info-zip-pel szemben, hogy létezik párhuzamosított variánsa, a pigz, az tud több prociszálon tömöríteni, azzal nyerhetsz egy kis időt, de a zstd akkor is köröket fog köré futni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Hát, ha nem kell tömöríteni akkor tényleg gyors. :)
Ha kell, akkor meg kurva lassú:
# time tar -I "zstd -17" -cf pt.tar.zst 1/
real 4m18,640s
user 4m18,962s
sys 0m1,420s
# time tar -I "xz -3" -cf pt.tar.xz 1/
real 2m37,501s
user 2m37,028s
sys 0m3,668s
# ls -la pt*
-rw-r--r-- 1 root root 110785224 júl 23 21.03 pt.tar.xz
-rw-r--r-- 1 root root 112185020 júl 23 21.00 pt.tar.zst
# time tar -I "zstd -T2 -17" -cf pt.tar.zst 1/
real 2m15,979s
user 4m29,120s
sys 0m1,535s
# time tar -I "xz -T2 -3" -cf pt.tar.xz 1/
real 1m20,940s
user 2m39,999s
sys 0m1,699s
Nyilván az xz-nél kevésbé tömörít, de cserében gyorsabb. Nem tudom mit tömörítettél vele, mert kb. azonos tömörített fájlméretnél gyorsabb szokott lenni az xz-nél lényegesen, de ha a legfelső tömörítési fokait használod, akkor ja, exponenciálisan belassul. Ezen nincs csodálkozni való, minden tömörítővel így van, még a multimédiás tömörítésekkel is, legyen az veszteséges vagy veszteségmentes. Nem is a maximum tömörítésre tervezték, arra az xz és a paq-klónok valók. Ennek a gyorsaság a lényege, és igen, akkor ha alacsonyabb fokozaton tömörítesz, akkor kevésbé fogja tömöríteni, de még ilyenkor is jobban összenyomja, mint a gzip, amivel viszont sebességben is versenyez.
Azért is írtam, hogy a zstd-nél játszani kell egy kicsit a tömörítési fokkal, ki kell kísérletezni néhány time-olt próbatömörítéssel, hogy melyik az a tömörítési fok, aminél még a tömörítési idő még nem szalad el túl hosszúra a -1 és a default -3-hoz képest, de a tömörítési fok határozottan javul, és még jelentősen gyorsabb vagy, mint a hagyományos tömörítők. Pl. nálad lehet, hogy -5 vagy -7-es fokozaton betömöríti ezt a mappát 120 megára, de cserébe jóval gyorsabb lesz az xz-nél. Attól is függ, hogy milyen fájlokat csomagolsz vele. Vannak furcsa határesetek. pl. nekem van egy régi szótárcédén egy több száz megás filler fájl (semmi funkciója nincs, csak helykitöltő szerepet töltött be, hogy a korai 90-es években a másolást megnehezítse ballasztadattal), annál az a furcsa helyzet ált elő, hogy ha először zstd -3-mel tömörítettem, majd azt xz -9-cel, akkor 40× olyan jól tömörítette be az xz, mintha csak magában küldtem volna rá az xz-t maximum tömörítési fokozaton, végül a két tömörítő kombinációja 2,8 KB-ra tömörítette be.
Nem véletlen, hogy a legtöbb tömörítőnél a default tömörítési fok az -3 és -5 között szokott lenni, mert általában a legtöbb algoritmus még ezeknél hatékony, ezért a fejlesztők ezt ítélték a leggazdaságosabbnak átlagos adatok tömörítésére. Ahogy ezek fölé küldöd a tömörítési fokot, úgy egyre meredekebben lassul be (exponenciálisan), de ezzel párhuzamosan a tömörítési fok egyre kisebb mértékben (logaritmusgörbe szerint) javul, azaz a gazdaságosság (extra tömörítési megtakarítás osztva idő) egyre pocsékabb lesz, annak ellenére, hogy azért összességében kisebbre tömöríti. Függ attól is, hogy neked mi a fontos, ha a maximum tömörítési fok bármi áron, az idő sem érdekel, akkor nyilván nem a sebességre kihegyezett tömörítőket kell használni.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Szeretném megköszönni a segítőkész embereknek, hogy elláttak jótanácsokkal. Külön köszönet a zstd beküldőjének, több mint 7-szeres a sebesség, és jól is tömörít.
Összeraktam ollóztam és módosítottam az iRedMail mentő scriptet. Ha valaki bármilyen optimalizálást hibát vagy bármit tud az ne tartsa magába. Némi magyarázattal fűszerezve kérem szépen.
Van egy aggasztó rész, ami a régebbi biztonsági másolatokat törli, ott az a fránya rm -rf. Megfelelőek a paraméterei, de ha valaki biztonságosabbá tudja tenni, az írja le kérem. Ettől engem ráz a hideg.
Frissítem a topikot, a neve az lesz hogy iRedMail backup. Más cím javaslatok is jöhetnek.
Azok, akik csak úgy idejöttek belebeszélni mert valami nyomja a szívüket, azok nyissanak maguknak topikot és ott írogasson ne itt.
Teszteltem egy visszaállítást. Bővítettem a backup.txt fájlt a Let’s Encrypt iRedMail tanúsítványok hivatkozásával. Alap telepítésen felül pedig két csomag szükséges, certbot zstd.