Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: mysiaty w Maj 09, 2017, 16:44:00
-
Wyłączyłem w archiwizatorze SGT kompresję danych. Zamiast dwóch plików: iar i i01 , otrzymałem jeden bak, ale za to 2,5 raza cięższy.Potem zdearchiwizowałem go.
Chciałbym się upewnić, czy podmiot po dearchiwizacji z .bak, zawiera dokładnie to samo co podmiot zdearchiwizowany z plików .iar i .i01.
Czy bezpieczne i rozsądne jest robienie kopii do pliku .bak? Plus jest taki, że kopia robi się szybciej i dearchiwizuje szybciej.Zajmuje za to więcej miejsca.
-
Jest to dokładnie to samo z tym że bak nie jest "skompresowany", ot cała różnica.
-
Wyłączyłem w archiwizatorze SGT kompresję danych. Zamiast dwóch plików: iar i i01 , otrzymałem jeden bak, ale za to 2,5 raza cięższy.
Z czasem i w zależności od stopnia kompresji posiadanych danych (zdjęcia towarów się nie kompresują, gdyż są już skompresowane) stosunek ten będzie zupełnie inny, nawet x10.
Czy bezpieczne i rozsądne jest robienie kopii do pliku .bak? Plus jest taki, że kopia robi się szybciej i dearchiwizuje szybciej.Zajmuje za to więcej miejsca.
Rozsądne jest robienie bezpiecznej kopii (nie napisałeś gdzie są umieszczane, a może to być "pulpit"), czy kopia będzie skompresowana czy nie jak się już domyślasz nie ma większego znaczenia.
-
bak jest robiony mechanizmami sql wiec odpada ryzyko ze skopie sie insertowa kompresja
-
To tych kopi trochę się naprodukuje. Najlepiej na koniec dnia zrobić :
1.Archiwum Insertowskie
2.Archiwum Sql
Obydwa archiwa umieścić na komputerze klienckim, komputerze serwerowym (obydwa w sklepie), na penie w celu przeniesienia do komputera domowego i wcale nie wygląda to dostatecznie pewnie.
Myślę jeszcze o serwerze zewnętrznym (mam trochę miejsca , tam gdzie trzymam stronę), ale jak to jest z tym wysyłaniem w świat. Próbowałem umieszczać pliki archiwum w magazynie Truecrypta, ale po powrocie z serwera nie dają się otworzyć. Jedynie co potrafię , to zahasłować w 7-zip .W tym przypadku po powrocie z serwera dają się otworzyć i zdearchiwizować. Prawdopodonie łatwo jest obejść hasło w 7zip . Jeszcze jest Insertowska e-archiwizacja, ale problem hasłowania pozostaje.
Może to wszystko przekombinowane? Co o tym sądzicie?
-
Z jednej strony zdecydowanie przekombinowane, a z drugiej może okazać się niewystarczające... Przecież @Biniew wyraźniej przypomniał, że backup jest jeden, zawsze wykonuje go serwer SQL, co najwyżej operacja ta może być uruchomiona przez inne aplikacje jaką jest na przykład Archiwizator. Zalecana jest "chmura" na zewnętrznym serwerze, ale bardzo wysoki poziom bezpieczeństwa daje też lokalna (NAS przez ftp).
-
Co ma dać pomysł z robieniem dwóch archiwów na koniec dnia?
Przecież archiwum "insertowskie" to to samo archiwum serwera SQL, tylko potem skompresowane.
-
Zalecana jest "chmura" na zewnętrznym serwerze
Na ten serwer , tak po prostu, wysyłać pliki archiwum bez szyfrowania przez ftp? bardzo wysoki poziom bezpieczeństwa daje też lokalna (NAS przez ftp).
O tym sobie poczytam.Niemniej jednak ten NAS jest w tym samym lokalu co dwa lapki i w razie pożaru,zalania, włamania może wszystko pójść "jak ten misterny plan Siary".
-
Co ma dać pomysł z robieniem dwóch archiwów na koniec dnia?
Zawsze robiłem dwa archiwa Insertowskie , jedno po drugim. Dlaczego?Zaczęło się z niewiedzy i pewnie jakiejś informacji z netu o zasadności robienia dwóch plików archiwów.
Czy jest gwarancja , że zrobione i zapisane archiwum jest w 100% prawidłowe i da się zdearchiwizować bez błędów?Jeżeli tak, to marnowałem czas na robienie tego drugiego.
-
IMO lepiej zrobić jedno na koniec dnia i drugie w połowie niż dwa, jedno po drugim.
Szansa na to że jedno się zrobiło z błędem, a drugie zaraz potem poprawnie jest raczej znikoma.
-
IMO lepiej zrobić jedno na koniec dnia i drugie w połowie niż dwa, jedno po drugim.
Szansa na to że jedno się zrobiło z błędem, a drugie zaraz potem poprawnie jest raczej znikoma.
Czyli sprawa ilości i czasu wykonywania archiwum ustalona.
-
Myślę jeszcze o serwerze zewnętrznym (mam trochę miejsca , tam gdzie trzymam stronę), ale jak to jest z tym wysyłaniem w świat. Próbowałem umieszczać pliki archiwum w magazynie Truecrypta, ale po powrocie z serwera nie dają się otworzyć.
Gdyby jednak ktoś chciał wysyłać kontener zahasłowany Truecryptem, to da się bez problemu.Korzystam z Filezilla i po ustawieniu Transfer/Typ transferu/ Binarny (wcześniej był wybrany automat) jest OK.
Dałbym sobie +1 , ale skromność mi nie pozwala.
-
Hasłowanie archiwum skompesowanego jest już określone w Archiwizatorze. Nie ma potrzeby robić tego dodatkowo.
Przy robieniu archiwizacji z kompresją Archiwizatorem, po zapisaniu archiwum plik pośredni .bak jest automatycznie usuwany - o ile zapisanie archiwum zakończy się poprawnie. W innym przypadku pozostaje w folderze roboczym.
-
dodam tez za zahaslowanie pliku nie ratuje nas przed jego zaszyfrowaniem
-
Czy bezpieczne i rozsądne jest robienie kopii do pliku .bak? Plus jest taki, że kopia robi się szybciej i dearchiwizuje szybciej.Zajmuje za to więcej miejsca.
W teorii nawet bezpieczniejsze, bo teoretycznie w przypadku uszkodzenia archiwum nieskompresowanego jest pewna znikoma szansa na jego ręczną naprawę a przy kompresji prawie żadna. W teorii istnieje też większe matematyczne prawdopodobieństwo, że kopia z kompresją będzie zawierała błędy, ale to bardzo wydumane scenariusze.
W sumie to nie ma znaczenia - rób jak Ci jest wygodniej.
Przy płatnej wersji MS SQL można robić kopie .bak z kompresją mechanizmami serwera i nie korzystać z archiwizera InsERTa. Przy wersji darmowej MS SQL nie ma opcji backupu z kompresją (ale łatwo to przeskoczyć innymi narzędziami) i jak komuś zależy na miejscu na dysku a nie chce się bawić w zewnętrzne narzędzia i skrypty, to archiwizer InsERTa jest dobry.