Citat:
Ovo sam također htio pitati tj. da li je samo od posljednjeg full backupa ili gleda eventualno i posjeće diferencijalne backupe? Po ovome što si napisao, ja zapravo mogu napraviti overwrite postojećeg diferencijalnog backupa jer zadnji diferencijalni ionako ima sve ono što i ovi prethodni?
Uvek je od poslednjeg full backupa. Možeš da čuvaš više verzija diferencijalnog bekapa, ali ti je dovoljan samo poslednji da dovedeš bazu u stanje u tom momentu.
Citat:
Također, malo sam testirao sa povećim transaction logom od 1 GB, i bez obzira što sam napravio njegov backup njegova veličina je i dalje ista?
Transkcioni log obično ne smanjuje log fajl, samo označava prostor kao slobodan.
Citat:
Znači, bez obzira što diferencijalni backup ima sve podatke iz tog vremena point in time se može vraćati samo ukoliko postoji backup transakcijskog dnevnika? Naravno, recovery model je FULL.
Pa, da. U diferencijalnom bekapu se nalaze SVI blokovi koji su izmenjeni od full bekapa, ali ne mora da znači da su izmenjeni blokovi upisani u redosledu njihovih izmena. Naravno, ako čuvaš više dif bekapa, to ti je neka vrsta point in time bekap strategije, ali transakcioni log ti daje "finiju granulaciju"
Citat:
Da li to znači da svaki backup trans. dnevnika mora ići u zasebnu datoteku tj. ne mogu napraviti overwrite kao u slučaju diferencijalnog jer bi time izgubio transakcije iz prethodnog vremenskog razdoblja?
Obično je format imena bekapa transakcionog loga kombinacija imena baze, datuma i broja sekvence, tako da nema prepisivanja postojećeg log bekapa, ali je jednostavno da počistiš višak.