Kurcze, programy zupełnie dla mnie egzotyczne, jeszcze strona w języku niezbyt dobrze mi znanym... Może należałoby dopytać u źródła.
Z moich skromnych doświadczeń wynika, że każdy tego typu program wykorzystuje jakąś bazę danych. Może to być jakiś autorski silnik, ale najprawdopodobniej jest to jakiś mechanizm Accessa lub coś SQLoweg. Jeżeli baza opiera się o Accessa, to gdzieś na dysku leży lub leżą pliki z rozszerzeniem *.mdb. Natomiast sam silnik bazodanowy może być wkompilowany w program. Tak jest to zrealizowane np. w naszym rodzimym Płatniku (chociaż tam jest możliwość wyboru i można korzystać z bazy SQLowej). Drugą opcją jest wykorzystanie zewnętrznego systemu baz danych opartego np. o język SQL, np. Microsoft SQL. Piszę akurat o MS SQLu, bo ten silnik jest dostępny w wersji Express, jest wtedy darmowy i często dołączany jest do oprogramowania, jako jego składnik (w wersji darmowej ma on swoje pewne ograniczenia). Najczęściej podczas instalacji program pyta się, czy ma zainstalować MS SQL. Jak się zatwierdzi, instaluje się serwer baz danych, instalator sam tworzy bazę danych, ustawia jej parametry i tworzy jej strukturę itd. Tak, że użytkownik nie jest nawet świadom, że coś takiego miało miejsce. Z tym, że baza SQLowa też gdzieś musi dane fizycznie na dysku przechowywać. Siedzą one w jakimś pliku, prawdopodobnie w katalogu, gdzie jest zainstalowany serwer baz danych. Taki serwer uruchamia się razem z komputerem w tle, wczytuje plik bazy i jest gotowy do pracy, nasłu****e. Jak uruchamiasz program, to łączy się on z tą bazą i sobie pobiera dane. Komunikacja programu z bazą odbywa się za pomocą zapytań (queries). Tak więc jeżeli komputer jest widoczny w sieci, to teoretycznie można się do tego serwera podłączać zdalnie z innego komputera. Sam program jest tylko klientem. No to tyle teorii...
Tak, czy siak, gdzieś te dane muszą być trzymane. Są to pliki, które teoretycznie wystarczy skopiować, żeby mieć backup. I tu zaczynają się drobne schody. W momencie, gdy plik jest w użyciu, nie można go w normalny sposób skopiować (zakładamy, że już wiemy, który to plik), bo jest zabezpieczony. Pół biedy, gdy jest to plik accessowy. Wystarczy wtedy wyłączyć program, żeby można było plik skopiować. Natomiast jeżeli jest to jakiś serwer SQL, to on pracuje cały czas w tle i ciągle trzyma ten swój plik danych w pogotowiu, uniemożliwiając jego skopiowanie. Trzeba wtedy albo wyłączać każdorazowo serwer albo... No właśnie... Tego rodzaju programy mają zazwyczaj opcję archiwizacji danych. Wysyłają wtedy odpowiednie zapytanie do serwera bazodanowego, a ten wykonuje taki jakby zrzut danych i wypluwa je w postaci pliku będącego obrazem. Później, w razie czego, można kolejnym zapytaniem wczytać dane z tego obrazu do bazy danych w celu odtworzenia jej zawartości.
I to jest moment, kiedy wartałoby się zwrócić do producenta oprogramowania, do działu wsparcia i wypytać, jak to się w tym konkretnym przypadku odbywa i jakie oni przewidują metody tworzenia kopi zapasowych. Bo przypuszczam, że jakieś przewidzieli. Pisząc, że robisz to źle, miałem na myśli to, że nie ma konieczności kopiowania całej zawartości partycji systemowej, bo wystarczy skopiować jedynie odpowiednie pliki. Tak teraz sobie pomyślałem, że skoro do tej pory kopiowałeś całe katalogi, to znaczy, że przy wyłączonym programie, miałeś możliwość skopiowania tego pliku. Więc jest szansa, że to jednak jakiś Access. Wtedy każdorazowo po wykonaniu jakiejkolwiek operacji, plik bazy danych jest aktualizowany i zawsze występuje w najnowszej wersji. Wystarczy zamknąć program i można go kopiować. Więc w dowolnym momencie mamy dostęp do najaktualniejszej wersji. W przypadku SQLa, archiwum tworzymy na żądanie w jakichś odstępach czasu. Bo każdorazowe wyłączanie serwera, czy odpinanie pliku bazy danych jest mocno kłopotliwe. Bo potem trzeba go znowu podpinać, włączać serwer itd...
Teraz to mogę sobie jedynie gdybać, bo znam szczegółów technicznych, ale już pewnie zorientowałeś się, że nie da się robić ciągłego backupu. Zawsze to będzie kopia pliku/plików wykonana w danym momencie. Chyba, że jako lokalizację dla takiego pliku bazy danych podasz jakiś współdzielony obszar na NASie. Wtedy będziesz miał dane zabezpieczone przez awarią dysku, zakładając, że w NASie masz dwa dyski w RAID1. Zawsze to jakiś sposób. Natomiast nie zabezpieczy Cię to przez przypadkowym uszkodzeniem samych danych, czy zrobieniem jakiejś głupoty przez człowieka. Dlatego jednak warto jest mieć snapshot wykonany co jakiś czas. Wtedy tracisz tylko to, co się zmieniło między ostatnią modyfikacją, a ostatnim backupem.
Trudno mi coś konkretnego Ci poradzić. Ja nad swoją strategią backupu myślałem dosyć długo i ciągle nie jestem pewien, czy jest ona słuszna. Na problemy z kopiowaniem plików będących w użyciu są patenty. Np. windowsowa usługa kopiowania volumenów w tle (Volume Shadow Copy Service). W oparciu o nią działają backupy systemowe, punkty przywracania itd. A Synology mimo, że jest bardzo fajnym urządzeniem, nie zrobi za Ciebie wszystkiego. Musisz mu wskazać, co ma kopiować i kiedy. Albo inaczej. Co ma być na niego kopiowane i kiedy.
Szukaj
Odpowiedz z cytatem
prawdopodobnie w niedługim czasie odezwę się z problemami 
Skontaktuj się z nami