jesszus!
addig nem fognék neki egy ilyen megoldásnak, amíg nem tudom biztosan, hogy az lvm tetszőleges darab fájlon is működik. 170 gigát minimum 170 darab egy gigás fájlba tudsz tárolni, szóval ezen agyalni kellene.

A másik nagy kérdés, hogy mit akarsz backupolni? mert szövegfájlok backupolására svn.

"addig nem fognék neki egy ilyen megoldásnak, amíg nem tudom biztosan, hogy az lvm tetszőleges darab fájlon is működik."

Megprobaltam utananezni, ugy tunt, hogy nincs erre vonatkozoan semmi korlat, az LVM1-ben volt annyi, hogy maximum 65536 PE lehetett egy logical volume-ban. Egyebkent az jobban aggasztott, hogy mindegyik file-nak kulon loopback device kell, de ugy tunt, hogy ez se problema.. Ha minden jol megy, akkor ma este ugyis osszerakom az LVM-es reszt es akkor ki fog derulni, hogy beleszaladok-e valami korlatozasba.

"A másik nagy kérdés, hogy mit akarsz backupolni?"

Mindenfelet, pl. a komplett /home-ot.

ez tipikusan egy olyan dolog, amiben nem hinnék el semmit a doksinak. amíg nem teszteltem rogyásig a megoldást, addig nem fogadnám el. abban légy teljesen biztos, hogy ezzel az ötlettel te most kimész a szokásos felhasználási körből és olyat fogsz csinálni, amit szerintem eddig még senki. kicsit egyedül leszel, mint egy úttörő a marson.

a mit akarsz backupolni kérdés inkább fájltípusra vonatkozik. binárist? szöveget?

Binarist meg szoveget vegyesen. Pl. ott van a komplett csaladi fotoalbum, a komplett levelezes, forrasok, pdf-ek, doc-ok, c64-es disk image-ek , tenyleg mindenfele.

szerintem az rsync nem nyálaz végig minden fájlt, vagy legalábbis nem tudom, de rövid időtávon belül nem.

100 millió fájlból gondolom csak lehetne szűrni, mi az ami és ami nem változik nap, mint nap. nem tudom elképzelni amúgy mi az a 100 millió, de akkoris. nekem a 900 giga átlagos személyes cuccokkal végez 2-3 perc alatt, úgy hogy erőltetve van az elején fájllista készítés. télleg nem tudom mi lehet nálad, ha egy linux is csak 1-200 ezer fájl. most megnéztem, az összes privát fájlom 120.000. és ebben benne vannak a privát emailek fájlonként (a gmail egészben...) meg minden.

ha már mindenképp titkolni és felhős gépen, akkor szerintem rsync incrementál | gpg --> feltőt. de szerintem ez sehogyse jó, mert pl nekem a virtualbox image-em ilyenkor 1:1 újra felkerül, hatalmas overhead. valahogy a tárolót kéne eleve titkosítottá tenni, gondolom lehet távoli dm-crypt-et csinálni, nem? akkor transzparens.

de én még mindig truecrypt, ami távolinál nem biztos hogy műx.

nemtom, valahol olvastam, hogy ez az rsync inkrementálos megoldás nem kezeli le jól a jogosultságokat (merthogy hardlinkelsz). aztán lehet ezt benézem csak, vagy nem erről van szó.

de én csak ugatom a témát, ezt tudjátok.

(hozzáteszem én xp-s offline files-on nőttem fel és az tényleg nyálazott ezerrel, azért nyaralásonként be van zippelve a fotóalbum, mert minek küzdjön vele a gép).

[ Szerkesztve ]

rsync: beállítástól függ, vagy csak az utolsó módosítás/kreálás dátumát nézi végig és az alapján dönt vagy mondhatod neki, hogy csináljon md5-ös checksumot minden fájlról és az alapján döntse el, hogy változott-e valami.

ha titkosítani kell, akkor lehet, nem az rsync a jó megoldás, hanem tar vagy hasonlók. a tarfájlt már lehetne titkosítani.

mondjuk szerintem normál esetben nem kell a hash, nem is default.

ja, valahogy úgy képzeltem, hogy a diffet-incrementet képezni rsynccel, aztán tar és gpg.

az xp saját titkolója volt jó, az tényleg file szinten titkolt. perszer ahhoz kéne egy online titkolt backup is a diffhez.

de nekem még mindig az ilyen extra fájlok problémásak, mint virtuáldiszk vagy thunderbird mail konténer. ott busz mindent, még mindig egyetlen esélyed egy távoli rsync szellem, hogy az ilyen giga fájloknak csak a dirib-darab checksumjait hasonlítsa a hálón át, aztán meg csak a különbséget küldje át.

többek közt ezért maildirelek mbox helyett a saját szerveren, elég szívás még lokál neten is, míg a thunderbird gmail local cache átdarál x gigát 2 új spam miatt.

[ Szerkesztve ]