Fórumok
Sziasztok!
Szkriptben tar -t használok felhasználók munkakönyvtárainak mentésére.
Minden egyes felhasználó egy tar fájlba kerül.
A munkakönyvtárakat egy hálózati megosztáson (samba) keresztül éri el a szkript.
Mindig csak a változott fájlokat kellene mentenie a szkriptnek,
ezzel szemben vannak napok amikor az összes felhasználó összes állománya
mentésre kerül. Az hogy melyik nap fut le így a mentés az látszólag véletlen szerű.
Munka könyvtárak csatolása:
mount -t cifs //szerver/munka -o username=...,password=...,rsize=130048,wsize=57344,noatime /mnt/munka
Egy könyvtár (user1) mentése:
tar -g user1.diff -czf user1.tar /mnt/munka/user1 &> /dev/null
Valakinek valami ötlete, h miért lehet?
Előre is köszönöm.
Hozzászólások
--no-check-device ?
akkor mar inkabb "rsync -avc", de a "v" nem is kell.
+1 rsync
Csak hát ez nem tömörít.
________________________________________
https://sites.google.com/site/eutlantis/
A sima tar sem. :D
Bar o hasznal ott -z kapcsolot is. De minek is? Ha lementi az 1GB-os filet is amiben 1 byte valtozott csak.
Amugy meg rakjon a samba ala egy fuse fs-t ami compress-al es kesz.
Szoval a samba hoston csinal egy konyvtarat, majd fusecompress alatt mountolja, majd rsync -ac. Ennyi. Es nem kell sambat konfigolni, nincs cifs overhead, stb, stb.
Ha jól látom és gondolom, akkor a samba hoston lévő fájlokat nem a hostra menti vissza. Ha nem "szambázik", akkor az rsyncd-t kell konfigurálnia.
________________________________________
https://sites.google.com/site/eutlantis/
Inkább sshd-t, de ugye az rsync és a tar két nagyon más cucc.
Meg amúgy is, mást csinál. Pl. marhára nem mindegy hogy tar összesen két fájlt csinál (és tömörít is közben a -z miatt), az rsync meg ahány, annyit. És a -c miatt végigolvassa az összes fájlt, ami amúgy szerintem jó ötlet (vagy nem, környezettől függ). A tar viszont valami metadatát néz, ami gondolom timestamp, ami vagy jó, vagy nem.
Ha elegendő az időt és a méretet figyelni, akkor nem kell a -c.
________________________________________
https://sites.google.com/site/eutlantis/
Windows felcsatoláshoz futtatva -u -val működik csak emlékeim szerint -c nélkül.
Érdekel a téma.
+1
Off: a mentés készítéséhez másik alkalmazás nem jöhet szóba? Ha igen, akkor én a dar-t (http://dar.linux.free.fr) javaslom figyelmedbe, itt írtam róla régebben.
Nálam az úgy megy, hogy mikor teljes mentés van (heti 1X) akkor elmentem a mentés dátumát egy fájlba és utána --newer opcióval megadom a tarnak hogy mikori dátumnál frissebbeket mentse.
--
Rózsár Gábor (muszashi)
Mondjuk az &> /dev/null helyett lehetne &>/dev/null, de még inkább &>log.meg.kellene.nezni
Az a spéc nem sokat játszik.
Viszont sokkal érdekesebb, ha egy bg process a fg-ban írt listáját irányítod valahova. ;)
Helyesen: ... >listafile 2>errorfile &
Lásd még: exec
Hallani véltem már olyan shell-ről, ahol gondot okozott a szóköz. A többit nem értem pontosan, de bizonyára igazad van.
Szerk: Ja, hogy az &>file mit jelent? Azt, hogy >file 2>&1
Aha.
Ez valami gnu fícsör, vagy annyira értelmetlen, hogy az utóbbi pár évtizedben elekerülte a figyelmemet. :(
Amire gondoltam:
MkLog()
{
exec 1<&-
exec 2<&-
exec 1>${1}.log
exec 2>${1}.stderr
}
for dir in dir1 dir2 ...
do
( Mklog $dir ; tar czvf $dir.tar $dir ) &
done
Így azért jobban látszik mi történt.
A "--no-check-device" megoldotta a problémát, köszönöm!
Alternatív megoldások is érdekelnek, de a tar -os megoldás elég és kézenfekvő volt.
A munka könyvtárak Linux-on vannak. A menteni kívánt megosztás könyvtárait
kézenfekvő volt a létező (Samba) megosztáson keresztül leszedni. Ha ez
működik, a célnak megfelelő, nem gondoltam más megoldást keresni.
Pár perc alatt lefut az egész, úgy gondolom nem éri meg keresgélnem.
Linux alól más gépről Windows megosztásokból is mentek, így hasonló a
két szkript, nem kell két mentési eljárást kitalálni, dokumentálni.
És nem utolsó szempont, ha valaki kolléga helyettesít annak
sem kell annyit agyalni egy esetleges visszaállítás alkalmával.
Köszönöm, az ötleteket, tippeket.
11 napba telt?! :)
Hát igen, mivel előtte nem volt kiszámítható a jelenség.