Mam rozumieć, że plik log zawiera nikomu niepotrzebne dane skoro go zredukowało niemal do zera? Na pierwszy rzut oka wszystkie dane są zachowane, jest pełna historia dokumentów i wszystko hula.
Nie, nie należy tak rozumieć. Przy niedarmowej wersji jest opcja recovery full, która na podstawie ostatniego backupu bazy i logu pozwala przywrócić bazę danych do do dowolnego punktu w czasie od ostatniego backupu bazy do ostatniego poprawnego wpisu w logu (bez backupu logu!), a nie tylko do ostatniego backupu bazy. W tym celu log opisuje KAŻDĄ zmianę w bazie i dlatego się tak rozrasta. By się tak nie rozrastał a były zachowane opcje recovery full, należy oprócz bazy, robić również kopie logu, np. kilka razy dziennie, jeśli to jest potrzebne, z opcją przycinania logu (by zawierał wpisy tylko od ostatniego backupu logu), wtedy wszystko jest małe, szybkie i jest opcja przywracania w czasie.
W wersji darmowej MS SQL przywracanie jest tylko simple, więc recovery można ustawić na simple i wtedy w logu mało co jest zapisywane, ale... gdyby było ustawione recovery full, to można byłoby w razie potrzeby pliki z darmowej bazy przenieść do pełnej i tam odzyskać do punktu w czasie. Dlatego najlepiej jest mieć poprawnie, tj. z logami i ich przycinaniem, ustawiony buckup full nawet w darmowej wersji. Z drugiej strony z praktyki wiem, że jak w bazach księgowych coś się pokićka przy czymś innym niż aktualizacja, to zwykle księgowe orientują się po... paru tygodniach/miesiącach i nie da się wtedy przywracać z backupu (choć backup jest przydatny, by zobaczyć co tam było, gdy było dobrze), tylko trzeba naprawiać bazę... Dlatego akurat w takich zastosowaniach model simple + ups + baza na macierzy z redundancją i jak się da, to serwer z pamięciami serwerowymi (z kontrolą parzystości) i najlepiej system plików z kontrolą poprawności danych w 99% pewnie styka...
