Pomoć-primer backup strategije u full recovery modelu SQL SERVER 2005
Trebalo bi napraviti backup strategiju koju bih odradio preko maintenance wizarda, napravio bih tri plana za full (jednom nedeljno), diferencijalni (jednom dnevno) i transakcioni log na svakih sat npr. Da li koristiti varijantu sa ukljucenom opcijom
Create a Backup File for Every Database (čiji mi je naziv malo nejasan, ali shvatio sam da je to jedini način da dobijem više fajlova, a ne da sve spucava u jedan backup device odnosno fajl u mom slucaju - u koji appenduje ili brise prethodno).
Ovako bih dobijao seriju fajlova-za jednu nedelju 1 full, diferencijalne i puuno trnova koliko mi se cini. Kako bih onda radio restore ako uradim restore fulla, poslednji diferencijalni i sada treba da restorujem npr. 12 trn fajlova da dodjem do disaster tacke. Verovatno ne fajl po fajl :)
Ovo resenje pravi takodje jako puno zasebnih fajlova.
Mozda jedan backup device (jedan fajl) gde ce biti i full i diff i transakcioni ali sa overwrite varijantom -mada me zbunjuje na koji nacin se radi overwrite transakcionih logova? Meni ce za restore trebati svi od poslednjeg diferencijalnog...
Mozda nesto ne kapiram kako treba, ali molim za pomoc...:)
Ukratko, moze li jedan primer kakva vam je backup strategija u full recovery modelu. I kako bi ukratko uradili restore koristeci svoje backup fajlove.
 |  |
 |
), neko preferira traku, neko backupuje na LAN, neko pravi vise kopija backup-a, neko ko ima dovoljno para posle svakog full backupa nareze celu proslu seriju na DVD/blueray, itd, u principu nista od toga nije pogresno dok god u trenutku havarije ti imas pristup backupima koji ti trebaju. Iz tog razloga npr ja nikada ne drzim backup ni na samom SQL serveru a kamoli na isto disku/RAID-u. Da li ces to drzati u jednom fajlu ili u vise fajlova zavisi od toga sta hoces da radis sa tim fajlom/fajlovima ali ja npr vise preferiram podelu na vise fajlova, sto ne znaci da je to resenje bolje iz nekog specijalnog razloga, cisto meni to vise odgovara jer mogu npr da napravim neku sekundarnu storage semu sa inkrementalnim arhiviranjem tih fajlova. Sa druge strane drzanje u jednom set-u olaksava automatiku restore-a, sto nekima znaci ali meni npr ne toliko jer produkcioni restore nije nesto sto se radi na dnevnoj osnovi vec samo u slucaju havarije. 
), itd, itd, pogledaj malo te tabele pa ces videti. To i dalje ne znaci da su ti fajlovi i prisutni na disku ili toj lokaciji, ovo samo pomaze SQLu da omoguci automatiku kroz menadzer i da zna unapred koji su LSN-ovi u kojim fajlovima da bi mogao da zna restore path bez velikih rucnih intervencija. Btw, ako hoces da ti se spisak ne prosiruje u beskonacnost, u maintenance planu navedi da set istice (expire) posle nekog vremena, recimo dve nedelje ako ti je full backup na nedelju dana. Trebalo bi nakon isticanja da nestanu iz spiska. Ako nemas te informacije u msdb bazi ili si backup fajlove pomerio na drugu lokaciju onda moras manuelno da das restore-u gde su i onda ce sql menadzer da iz njih procita LSNove, tako da infomracije u msdb bazi nisu kriticne, samo su korisne. U krajnjoj liniju uvek mozes da odradis restore sekvencu kroz full+diff+NxTRN T-SQL komandi kao sto si i sam video.