Zapis/odczyt plików na FTP – zabezpieczenie przed utratą danych

0

Witajcie , to mój pierwszy post ,programuje od 8 roku życia okresowo i dla siebie. od Atari basic zaczynałem teraz lazarus pod Mac OS i Windows
Amatorem jestem Wiec wybaczcie mi proszę podstawowe błędy gdyby się pojawiły.

Pisze program dla siebie pod badanie naukowe zbierający z wielu urządzeń z uruchomionym programem danych zarówno online jak i offline.
Po połączeniu z internetem i serwerem ftp dana kopia programu pobiera szyfrowany plik binarny z serwera. plik nazwijmy go x.dat. jest to prosty plik bazy danych. (Nie potrzebuje komponentów do tego bo baza jest prosta bardzo i nie mam na razie czasu uczyć się obsługi bardziej skomplikowanych baz)
Następnie program stawia plik znacznik na serwerze aby zablokować w tej czynności inne kopie programu(prosta prewencja kolizji zapisu) porównuje wpisy z własna baza i uzupełnia bazę o nowe wpisy po czym wysyła plik ponownie na serwer.

I tutaj pojawiają się zagrożenie:
Jeśli program podczas wysyłania pliku na serwer zostanie zamknięty albo łącze internetowe przerwane to w pliku na serwerze (tym x.dat) powstanie błąd. Korzystam z ftpsend synapse.

Dlatego mam dwa rozwiązania:

  1. Renamefile x.dat na xcopy.dat przed zapisem na serwerze. I w razie wystąpienia błędu kolejna łącząca się z ftp kopia programu przywróci z niej plik x.dat przez kolejne rename...

  2. na czas zapisu program ściągnie plik x.dat i zapisze na serwerze ftp jako xcopy.dat bez użycia rename, i dopiero jak to się powiedzie bez błędu rozpocznie zapis nowego pliku x.dat na serwerze po czym usunie xcopy.dat - lub na wszelki wypadek zostawi.

Nie ukrywam ze pierwsza opcja jest bardziej kusząca przez brak transferu danych ale nie wiem jaka jest jej awaryjność- czy również może powstać błąd krytyczny?
Który sposób byście wybrali?
Baza będzie raczej nie większa niż 5-10 Mb i to tylko jeśli będzie dużo użytkowników. Na początek nie więcej niż 1mb a poszczególni użytkownicy stosunkowo rzadko będą ja ściągać. Zwykle 1-2x w tygodniu.

Pozdrawiam
Krzysiek

0

Czy ja dobrze rozumiem, masz jeden serwer ftp z plikiem x.dat do którego różni klienci się łączą aby w nim cos pozmieniać? Masz wpływ na łączące się programy?

2

a wszystkie te problemy rozwiązało by skorzystanie z jakiejkolwiek bazy SQL gdzieś na darmowym serwerze (chociaż jeśli masz jakiś publiczny FTP to i SQL by mógł tam być). Nie ma żadnych kolizji zapisu, nie przejmujesz się zerwaniem połączenia w trakcie zapisu (po prostu ponawiasz zapis po powrocie połączenia a transakcje dbają o to aby śmieci nie było), kilka/naście/dzieisąt/set klientów może pobierać i zapisywać dane jednocześnie...
Ale po co się babrać w rozwiązaniach, które zajmą w kodzie może ze 30 linijek jak można wymyślać koło na nowo...

0

Masz racje ze sql pewnie by rozwiązał problem ale czy nie pojawiłby się kolejny? Przy przenoszeniu się na nowy serwer ftp (z różnych powodów) wystarczy ze administrator ( program posiada różne klasy dostępu do danych oraz funkcji) podaje nowy adres ftp i dane dostępowe po czym pozostawia plik flagowy który przekieruje w ciągu tygodnia pozostałych użytkowników do nowego serwera ftp. Samo przenoszenie odbywa się za pomocą prostego skopiowania trzech plikow z serwera na serwer bez ustawiania bazy danych na nowym ftp. A z baza sql nie byłoby to chyba tak proste? Ale jeśli byłoby to może macie racje ze może nauczenie się obsługi jakiegoś komponentu sql byloby prostszym rozwiązaniem i pewniejszym?

@Panczo - tak dobrze rozumiesz. Inne programy łącza się i zmieniają plik x.dat jednak wpływ na ich działanie myślałem osiągnąć za pomocą pliku flagowego na serwerze ftp.
Poza tym programy sa nie zależne i tez przechowują swoją kopie pliku x.dat

Poza tym przy każdym zapisie nowej wersji pliku x.dat pojawi się tez na innym serwerze plik klucz. Bo jak mówiłem plik x.dat jest szyfrowany za pomocą losowego klucza z xorowaniem i zmienia się za każdym razem gdy nastąpi zapis.
Nie wiem czy tak silne zabezpieczenie da mi sql z lazarusa?

No i baza danych zapisana na dysku usera tez musi być obsługiwana przez program w razie dłuższej przerwy z dostępem do ftp czy internetu. Bo użytkownicy również korzystają ze statystyk i danych gromadzonych w pliku x.dat. Poza tym program ma dzialac na pendrivie i baza musi być odczytywana i aktualizowana na dowolnym komputerze bez dostępu do internetu również. A aktualizacja bazy tzw matki tożsamej zwykle z kopiami musi się odbywać tylko przy połączeniu z ftp i w obecności internetu.
Czy baza sql będzie dzialac lokalnie? I będzie możliwość jej przeszyfrowywania za każdym razem?

1

Ja bym zrobił jeszcze inaczej:

  1. Klienci pobierają x.dat
  2. Aktualizują swoje bazy
  3. Uploadują na serwer plik "wymiany", niezależny od x.dat
  4. Po stronie serwera cyklicznie scalasz pliki z x.dat
  5. Dodajesz plik z datą ostatniej aktualizacji x.dat, aby klienci nie musieli pobierać x.dat jak nic się nie zmieniło.
0

@Panczo - Dzięki za sugestię. Wytłumacz mi proszę pkt 4? Czy to znaczy ze muszę napisać skrypt php i wrzucać na serwer aby scalał pliki?
Czy chodzi Tobie o to ze klient scala u siebie i wysyła jako plik np xcopy.dat- już scalony i jak mu się to uda bez błędu to robi rename na x.dat a xcopy.dat usuwa z serwera?
Kurczę zawsze jakieś małe programiki dla siebie robiłem a ten byłby większym projektem i chciałbym żeby obyło sie bez katastrofy z utrata danych po zaangażowaniu stu użytkowników. Wiec muszę teraz wszystko przetestować i obmyślić dobrze.
Jest to badanie naukowe medyczne i dane musza być dobrze zabezpieczone zgodnie z nową dyrektywą Rodo... lub lepiej bo nie chciałbym żeby badanie ktokolwiek mógł przejąć(mimo ze osobowe dotyczyć będą tylko osób przeprowadzających badanie, a badani będą anonimowi).

0

@Windowbee: ty chcesz osiągnąć efekt synchronizacji danych pomiędzy klientami za pośrednictwem jednego pliku x.dat, który jest hostowany na serwerze FTP. Przy 100 klientach masz 100 możliwości na to że pójdzie coś nie tak... Ja proponuje scenariusz w którym klienci pobierają x.dat: jak coś pójdzie nie tak to pobiorą dane jeszcze raz. Plik x.dat ma zapisaną wersje w osobnym pliku, aby nie generować ruchu.
Klienci nie ruszają w ogóle zawartości x.dat tylko dane do wrzucenia, wysyłają osobnym plikiem na FTP.
I tu jest klucz do rozwiązania: tylko jeden "komputer" zajmuje się aktualizacją x.dat na podstawie plików.
Jeżeli tu pójdzie coś nie tak, to podwyższenie numeru wersji bazy sprawi, że klienci pobiorą x.dat i zwrócą różnicowe pliki do aktualizacji. Odpada "proszenie" klientów o wysłanie danych jeszcze raz, bo z automatu dostaniesz różnicę w plikach.

I teraz pkt. 4 Nie, nie musi to być to być skrypt PHP, możesz na swoim komputerze mieć program który pobierze pliki różnicowe, doda do x.dat i wrzuci na serwer FTP razem z podniesieniem wersji pliku.
Może to być skrypt PHP/Python (czy to co potrafi obsłużyć serwer hostujący FTP) i w CRON-ie puszczać cyklicznie aktualizacje pliku x.dat.

Nie podałeś najważniejszej informacji: jak szybko zbierane dane mają być dostępne dla innych?

Reasumując ja dążyłbym do tego, żeby aktualizacja x.dat była wykonywana w jednym miejscu, bo to jest jedno miejsce w którym szukasz problemu. w twoim wypadku zmiana w module aktualizacji x.dat czy jakiś fix, będzie powodował konieczność aktualizacji 100 klientów (czy ilu ich tam będziesz miał)

To tyle jeżeli chodzi o FTP, ja poszedłbym jednak w kierunku jakiejś bazy danych, w której trzymałbym dane i napisał dwa skrypty (np. PHP):

  1. który pobierze od użytkownika plik różnicowy, zaktualizuje na jego podstawie baze danych i wygeneruje na jej podstawie x.dat
  2. który zwróci użytkownikowi x.dat

Nic nie piszesz jakim serwerem dysponujesz i co sam potrafisz zrobić, to wymaga oczywiście zabezpieczenia aby nie dodawać tych samych danych jeżeli klient wyśle jeszcze raz to samo. I zapominasz o tym, że niektórzy mogą mieć zablokowany dostęp do serwerów FTP i wtedy się nie zsynchronizują...

0

@Panczo,
Jeszcze raz dzięki myślisz podobnie jak ja dlatego w ogóle ten post powstał.. bo czuje problemy...
Moje umiejętności to tylko delphi/lazarus na podstawowych komponentach plus synapse ftpsend którego się uczę właśnie.
Program który pisze sam przeprowadza testy psycho- wizualne z badanymi pod kontrolą badających i wyniki tych testów spływają do bazy na serwerze ftp. I pojedyncze badanie nie będzie tak ważne jak integralność całej bazy. ( duża ilość badań = duża wartość statystyczna wyników). Dlatego program jest nie instalacyjny a jedynie w katalogu na pendrivie.
W przypadku błędu przesyłania komputery klienckie nie będą się łączyć sto razy wznawiając próby tylko zapiszą zmiany (tak jak mówisz w plikach różnicujących) i po ponownym uruchomieniu programu lub po naciśnięciu w opcjach synchronizacji spróbują wysłać dane ponownie. Tak ze po ich stronie nie spodziewam się problemów - kosztem zniszczenia danych zbieranych a nie zapisanych poprzednio przez danego klienta jeśli wystąpiły bledy w plikach. Napisałem procedurę badającą poprawność wprowadzanych danych. Przed wysłaniem z opcja ich „apoptozy’
na razie wymyśliłem scalanie na każdym komputerze i tworzenie kopii zapasowych na dysku twardym administratorów. A php i innych języków prawie wcale nie znam. Tzn nie na tyle żeby biegle w nich wykonywać procedury na danych.
Ale muszę mieć chwile żeby przemyśleć to co napisałeś na spokojnie bom w pracy 😅

0

Warto przemyśleć, ale trzymaj sie zasady, że plik x.dat dla klientów jest tylko do odczytu, to dużo ułatwi.

0

Dziękuje ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1