În 2016-05-27 15:35, Catalin Muresan a scris: > 2016-05-26 20:48 GMT+01:00 Flavius Aspra <flavius...@gmail.com>: > >> 2016-05-26 20:40 GMT+02:00 Catalin Muresan >> <catalin.mure...@gmail.com>: >> >> > >> > Problema mea e ca $HOME e mare (29G) si e ineficient sa backup+encrypt >> > zilnic. >> > >> >> In cazul programarii, cele mai mari sunt repositoriile, iar pentru ele >> ma >> gandeam la instalarea de hooks in git (git init ar fi redirectionat >> printr-un alias) care s-ar ocupa de backup separat de backupul >> datelor. >> >> Ceea ce nu-mi place la abordarea asta e push de backup, prin pull ar >> fi >> mult mai sigur (boxul de backup se conecteaza la boxurile carora le >> face >> backup si isi trage diferentele de acolo). >> > > Daca ai control tu la backup server + clienti aunci sunt multe solutii > (full, incrementale, diferentiale, etc) care fac ce vrei tu (bacula de > ex. > are agent si merge push/pull) > > >> >> Ca program de backup am pus ochii pe https://github.com/bup/bup, in >> teorie >> designul mi se pare bun, insa pacat ca nu a atins inca v1. >> >> Poate cunosti tu niste alternative bune? >> > > Cea mai eleganta chestie care am vazut-o este BRTFS/ZFS send-receive. > Faci > simplu backup la doar blocurile care s-au schimbat, similar sa zicem cu > git > dar la block-level nu file level.
Si eu zic, ca zfs send/receive e de departe cea mai sigura solutie, dar si cea mai rapida(in sensul ca zfs-ul nu sta sa "afle" care blocuri s-au modificat si care nu, ca sa comparam cu alte sisteme la nivel de FS, gen rsync, si daca ai multe fisiere in multe subdirectoare, avantajul e si mai evident). Dezavantajul ar fi ca trebuie sa ai zfs si pe sursa si pe masina de backup. Cu siguranta zfs este mai matur si mai bine pus la punct pe partea de stream send/receive fata de btrfs. Deasemenea, e de avut in vedere si TIMPUL de resturare al statiei, in caz de probleme si aici vad urmatoarele aspecte care ar trebui analizate/cunoscute: - in cazul restaurarii zfs-send-recive(criptat si pe home si pe masina de backup), viteza este buna, ca si timp total de resturare - in cazul restaurarii via FS/rsync, sigur dureaza mai mult(diferenta e cu atat mai mare cu cat sunt mai multe fisiere si directoare) - bun, avem backup-ul criptat(sistem non-zfs), tragem datele, si oooops .... avem ceva erori ca de, HDD-le mai dau erori uneori, caz in care, e o problema(daca ai zfs, macar stii ca ai probleme, si daca pe server ai ceva cu zfs redundant, gen mirror/raid6, si esti in zona de siguranta, si te-ai scos, inclusiv corectia automata a erorilor din datele de redundanta) Daca mai luam in calcul si ultima moda .... cu "varcolaci" care cripteaza, cu zfs mai ai o sansa sa vezi fisierele neafectate din snapshot-le de la zfs. Crede-ma ca stiu ce zic .... ;) > Ce vreau eu e $HOME pe encrypted block device si backup incremental > criptat > cu asymetric encryption (PK) spre un remote in asa fel incit datele sa > fie > in clear doar la mine pe workstation, oriunde altundeva sa fie criptate > (wire, remote backup, etc). Dupa mine, daca asta e rationamentul, e de preferat sa ai si la tine si remote tot criptat. Daca ideea asta nu te avantajeaza, se poate face zfs send/receive cu un pipe catre un tool de criptare(gpg de ex.) > Asa cine asculta pe retea sau are control > complet asupra serverului de backup nu poate folosi ce e acolo. > Ideea ar fi ca zilnic sa faci snapshot la FS si send diferenta > > Am cautat si am gasit btrbk care pare sa faca exact ce vroiam: > encrypted > backup to non-btrfs target, interesant. > > https://btrfs.wiki.kernel.org/index.php/Incremental_Backup > http://docs.oracle.com/cd/E19253-01/819-5461/gbchx/index.html > https://github.com/digint/btrbk > > >> _______________________________________________ >> RLUG mailing list >> RLUG@lists.lug.ro >> http://lists.lug.ro/mailman/listinfo/rlug >> > _______________________________________________ > RLUG mailing list > RLUG@lists.lug.ro > http://lists.lug.ro/mailman/listinfo/rlug ================================ ATENTIONARI ============================= - nu trimiteti date personale (CNP, copii dupa acte de identitate etc). O lista completa cu reguli de utilizare exista la: http://gw.casbv.ro/forum_smf/index.php?topic=2000.msg3106#msg3106 C.A.S.J. Brasov - B-dul Mihail Kogalniceanu, nr. 11,Brasov [web-site]: http://www.casbv.ro [forum]: http://gw.casbv.ro/forum_smf/index.php ========================================================================== _______________________________________________ RLUG mailing list RLUG@lists.lug.ro http://lists.lug.ro/mailman/listinfo/rlug
