Perfect Backup

[pyth0n3]

Un backup perfect

Probabil majoritatea se intreaba care ar fi cerintele unui backup perfect si ce fel de aplicatie ar trebui sa foloseasca pentru a crea backup.Un backup perfect ar trebui sa indeplineasca urmatoarele cerinte:

storage in discuri separate

-copia unui back-up necesita un storage in discuri separate, posibil sa nu fie in aceeasi incapere fizica

restore simplu (cross platform)

-un backup nu trebuie sa depinda de un anumit program si trebuie gasita o solutie de restore in cazul in care programul care vine folosit pentru backup nu va functiona

scheduling automat

-un backup necesita sa fie programat , calitatea unui restore depinde de acest lucru (cu cat mai multe backup-uri recente cu atat calitatea de restore este mai buna)

Voi face un exemplu practic pe care il voi adopta zilnic

Pentru un storage separat voi folosi doua disk-uri externe

disk1 650gb

disk2 2000gb

Voi structura disk-urile de backup in urmatoarele partitii:

disk1 = 3 partitii

150gb ntfs (Data_Bck)

250gb ext4 (Data_Bck)

250gb ext3 (encrypted)

disk2 = 2 partitii

1000gb ext4 (Data_Recovery)

1000gb ext4 (Clone_Disk)

Pentru backup voi folosi urmatoarele utility:

Duplicity aka Duply aka Duplicati(windows version)

Duplicity duplicity: Main

Duply ftplicity / duply (simple duplicity)

Duplicati duplicati - A flexible backup system with a friendly user interface - Google Project Hosting

Clonezilla Clonezilla - About

Aceste utility folosesc gpg,tar,winrar pentru a crea o arhiva

Clonezila foloseste partclone,nfsclone,partimage si dd pentru a clona un HD

Un backup necesita sa fie recuperat si in cazul in care nu avem la dispozitie aceste utility

Un backup nu trebuie sa depinda de un program pentru a putea face restore.

Scheduling, (backup scheme)

Cum se va face backup?

Am decis sa aplic urmatoarea structura (personala):

Un backup full pentru fiecare sistem o data pe luna + un backup incremental in fiecare saptamana care va copia doar fisierele care au fost mofificate de la ultimul backup.

Am adoptat urmatorul sistem:

Jan 1st: Full Backup A

Jan 8th: Incremental Backup A1

Jan 15th: Incremental Backup A2

Jan 22nd: Incremental Backup A3

Jan 29th: Incremental Backup A4

Feb 5th: Full Backup B (Won't delete backup chain A because we always keep two full backups)

Feb 12th: Incremental Backup B1

Feb 19th: Incremental Backup B2

Feb 26th: Incremental Backup B3

Mar 5th: Incremental Backup B4

Mar 12th: Full Backup C (After this, the last incremental backup in chain A is over a month old and we have two full backups, so chain A will be deleted)

Aceste backup-uri se vor face direct pe disk1.

Sistemele windows vor face backup in partitia ntfs 150gb disk1 <users data>

Sistemele Unix/Linux vor face backup in partitia ext4 250gb disk1 <home users>

Datele considerate confidential vor face backup in partitia ext3 250gb encrypted disk1 <home users>

Partitiile ntfs 150gb disk1 si ext4 250gb disk1 vor face mirror in partitia 1000gb ext4 disk2 (Data_Recovery)

Partitia ext3 250gb disk1 va fi clonata in partitia 1000gb ext4 (Clone_Disk) disk2 <full partitionclone>

Toate sistemele vor fi clonate in mod complet si separat de backup o data pe luna in partitia 1000gb ext4 disk2 <Full system clone> Acest lucru comporta copierea fiecarui harddisk la un block-level access (very low-level file access) full disk.Dupa fiecare clona se va face un test pentru restore iar ambele disk-uri vor fi separate in spatii diverse.

Diagrama backup

Edited June 2, 2012 by pyth0n3

[bcman]

Mersi, nu auzisem despre aceste tool-uri de backup (în afar? de clonezilla). Îmi place ?i cum ai gândit scheduler-ul. Nu eram sigur cam câte backup-uri s? p?strez.

[pyth0n3]

Uitasem sa precizez , pentru a crea un mirror a datelor poate fi folosit rsync .Acest lucru deoarece datele de backup vin facute de catre user-ul care foloseste sistemul respectiv si e necesar ca fiecare atribut sa fie pastrat atunci cand se face transferul de la primul dispozitiv de backup disk1 la al doilea dispozitiv de backup disk2 (Data_Recovery).

Recursive mode

Preserves symbolic links

Preserves permissions

Preserves timestamp

Preserves owner and group

Iar in legatura clonelor , un hard disk clonat poate fi replicat in alte hard-disk-uri.Presupunem ca aveti un sistem pe un disk de 150gb in care ati folosit 80gb iar restul e liber.In momentul in care se va face o clona a acestui hard disk ,imaginea clonei va fi in jur de 70GB (Zip) iar restul pana la 150GB nefiind date va fi doar trecut ca directiva care va fi extinsa atunci cand se va face restore.O clona poate fi la randul ei montata ca un disk normal intrun mount point oricare ar fi si datele pot fi extrase fara ca sa fie creat un restore.Pot fi la randul lor montate doar unele partitii dintro clona sau se poate face un restore doar de la unele partitii.Clonezilla face un split de 2gb pentru fiecare bucata de imagine a clonei.

Asadar daca careva vrea sa faca un mount a unei partitii care a fost clonata va trebui sa creeze o imagine separata care va fi montata folosind partclone.Exemplu split :

part1-sda1aa

part1-sda1ab

part1-sda1ac

part2-sda2aa

part2-sda2ab

part3-sda3aa

Aceasta poate fi o clona a unui sistem cu 3 partitii.Presupunem ca vrem sa montam o singura partitie din clona facuta deoarece un restore complet ar necesita un disk + aprox 12 ore de restore pentru 250gb.

Presupunem ca avem nevoie de datele din partitia sda2.Vom crea o Imagine si o vom monta intrun director folosind partclone si mount.

cat part2-sda2* | gzip -d -c | partclone.restore -C -s - -O image_sda2.img

Note:

Asigurati-va ca imaginea a fost creata cu gzip inainte sa treceti prin pipe gzip

Pentru a monta imaginea si recupera datele

mkdir /mnt
mount -o loop image_sda2.img /mnt

In cazul in care imaginea are un filesystem windows ntfs se poate monta cu urmatorul comand

ntfs-3g  image_sda2.img /mnt

Un restore complet se poate face cu clonezilla, la fel si clona , se poate face si un restore de la o anumita partitie pe un disk extern dar atentie ca va rescrie datele existente.Cand se va face un restore complet a unei clone pe un drive va trebui oricum creat un backup inainte a datelor existente deoarece clona va rescrie tot disk-ul.E important sa simulati un restore pe un disk de test inainte sa creati un restore intrun disk unde exista deja un sistem.Un alt aspect important , daca harddisk-ul care se va clona este cryptat si are 250gb iar voi ati folosit doar 80GB si restul este liber , clona va avea 250GB deoarece nu poate fi citit un harddisk criptat si se va face o copie low level folosind dd care va dura destul de mult (in jur de 14 ore usb2.0).

Edited June 3, 2012 by pyth0n3

[Flubber]

Curios este faptul insa, in organizatii mari in special de Data Storage & Management sau oricare din serviciile de file hosting, e-mail services ce sunt nevoite prin lege sa tina informatiile un anumit timp, daca ultimul disk (BACKUP-SRV3#Mar31) va sta 6 luni in camera lui speciala (unde se tine cont de: umiditate, temperatura, purificare a aerului s.a.m.d.), nu trebuie facut back-up la tot continutul datorita faptului ca in timp acel disk se poate deterioara (BACKUP-SRV3#Mar31)?

Ar fi introdusa o noua politica: back-up la continutul back-up-ului de 2TB, in caz ca este dorita o stocare a datelor pe un termen mai indelungat. Ce alte cai ar fi ce tin seama de "Data preservation over long time"?

[dany_love]

sper ca sunteti constienti ca din ce ati zis mai sus..peste 90% nu o sa inteleaga nimic da?

[aelius]

sper ca sunteti constienti ca din ce ati zis mai sus..peste 90% nu o sa inteleaga nimic da?

"Important este sa fiu criticat de un om cu cap decat sa fiu iubit de 1000 de robi" - Decartes

Ca si in cazul de fata, daca tutorialul este util unei persoane, nu ne intereseaza ceilalti. Cine e interesat, pune mana si citeste.

// ontopic: Apropos de backup, eu folosesc doar rsync over ssh cu keys si oarece scripturi bash. Backup-urile de la mysql se fac local (pe servere), cu mysqldump, se arhiveaza si apoi sunt luate de rsync. Pentru stergerea backup-urilor vechi: find+atime,ctime.

[pyth0n3]

nu trebuie facut back-up la tot continutul datorita faptului ca in timp acel disk se poate deterioara

Ar fi introdusa o noua politica: back-up la continutul back-up-ului de 2TB, in caz ca este dorita o stocare a datelor pe un termen mai indelungat. Ce alte cai ar fi ce tin seama de "Data preservation over long time"?

In diverse organizatii backup-urile nu vin tinute pe disck-uri , datele vin stocate in tape (casete) si des vin folosite librarii care se ocupa de backup precum sl8500 sau diverse alte produse IBM , etc.O politica adoptata spre exemplu la un corporate unde ma ocup de IT consulting ar fi urmatoarea:60 de zile full backup , 1 incremental pe zi + 1 archive database in fiecare ora pentru orice sistem + clona ambient , deci asta ar insemna ca vine pastrata o copie a unui ambient de productie (daca exista 10 servere database, vor exista 10 servere clone database ).Ceea ce vine pastrat in termen mai lung ar fi doar datele care vin stocate in db de productie si sincer sa fiu nu cunosc exact timpul cat pot fi pastrate dar vin stocate in ambiente destul de sofisticate chemate bunker cu o clima constanta si structuri destul de solide.In general se face cam 6-7 Terabyte de backup pe zi.