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}
- 846 megtekintés
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
É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.
- A hozzászóláshoz be kell jelentkezni
Részet a tar manualjából:
-O, --to-stdout
Extract files to standard output.
Tehát meg lehet csinálni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Csak ne hoztad volna már megint ide a politikát! :D
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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 a tar -czf csovem ...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
mknod csovem p
sftp remuser@host
put csovem
^Z
bg
tar -czf csovem ...
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Csak egy kérdés, hogy ezt nézted-e már?
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
É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 hozzászóláshoz be kell jelentkezni
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ó.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
Én voltam figyelmetlen, bocs. Az a -T0 valóban nem a tar paramétere.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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).
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
nice - run a program with modified scheduling priority
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Sőt, futásidőt mérni így is lehet:
time [options] command [arguments...]
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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 $?)
- A hozzászóláshoz be kell jelentkezni
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.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nem kell ez a komplikált date-elapsed megoldás. Egyszerűen csak írd oda a time parancsot a tar elé, ha benchmarkolsz.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
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.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni