iRedMail backup

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.

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:

tar -cJf valami.tar.xz valami/

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

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

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. 

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)

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

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.

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:

              An archive name that has a colon in it specifies a file  or  de‐
              vice on a remote machine.  The part before the colon is taken as
              the machine name or IP address, and the part  after  it  as  the
              file or device pathname, e.g.:

              --file=remotehost:/dev/sr0

              An  optional username can be prefixed to the hostname, placing a
              @ sign between them.

              By default, the remote host is accessed via the rsh(1)  command.
              Nowadays  it  is common to use ssh(1) instead.  You can do so by
              giving the following command line option:

              --rsh-command=/usr/bin/ssh

              The remote machine should have the rmt(8) command installed.  If
              its  pathname  does  not match tar's default, you can inform tar
              about the correct pathname using the --rmt-command option.

 

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á:

       -T, --files-from=FILE
              Get names to extract or create from FILE.

              Unless specified otherwise, the FILE  must  contain  a  list  of
              names separated by ASCII LF (i.e. one name per line).  The names
              read are handled the same way as command line  arguments.   They
              undergo  quote  removal  and word splitting, and any string that
              starts with a - is handled as tar command line option.

              If this behavior is undesirable, it can be turned off using  the
              --verbatim-files-from option.

              The --null option instructs tar that the names in FILE are sepa‐
              rated by ASCII NUL character, instead of LF.  It  is  useful  if
              the list is generated by find(1) -print0 predicate.

 

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)

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)

Köszi, ezt a tömörítést le fogom tesztelni, mert ~6GB 13GB amit mentenem kell (majd megosztom az eredményt) és már azt is látom hogy csak 1x 1 héten, mert megtaláltam a 

--listed-incremental

paramé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

start_time=$(date +%s)
tar -I "zstd -T0 -1" -cf /home/backup/blabla.tar.zst /var/vmail/vmaill/
end_time=$(date +%s)
elapsed=$(( end_time - start_time ))
echo $elapsed

13GB -> 8156MB 89 mp

gzip

start_time=$(date +%s)
tar cfz /home/backup/blabla.tar.gz /var/vmail/vmaill/
end_time=$(date +%s)
elapsed=$(( end_time - start_time ))
echo $elapsed

13GB -> 8314MB 630 mp

Pl:

start_time=$(date +%s)
nice -n 13 tar -I "zstd -T0 -1" -cf /home/backup/blabla.tar.zst /var/vmail/vmaill/
end_time=$(date +%s)
elapsed=$(( end_time - start_time ))
echo $elapsed

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:

start_time=$(date +%s)
nice -n 13 tar -I "zstd —ultra -22 -T0 -1" -cf /home/backup/blabla.tar.zst /var/vmail/vmaill/
end_time=$(date +%s)
elapsed=$(( end_time - start_time ))
echo $elapsed

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ő!

A következőt szeretném megvalósítani, de én nem értek hozzá. Konkrétan egy iRedMail és annak a mentéséről. Bár ez nem fontos, mert az elképzelésem szerint bármire használható lenne.

Elképzelés

Lehetne 3 szövegfájl. ...

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:

 ExitCode $(SetParam ppid $BASHPID ;$LIMIT_SPEED $CMDSSH -p ${RPORT:-22} ${RLOGIN:-user}@$RHOST "/bin/tar -cz -b 1 -C $(GetParam base.path $FPROP) -T
- -f -" < $FCOPY >$FTAR 2>$REASON ;echo $?)

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)

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.