Jak wykonać logistycznie kopie zapasową ?

Kolejny temat do przedyskutowania jeśli ktoś ma ochotę. Pracuje sobie nad programem SaaS. Klient może kupić dostęp i używać programu. Załóżmy, że jest 10 klientów. Baza danych jest jedna. Robie kopie zapasową bazy powiedzmy ileś tam razy dziennie. Nagle jeden klient skasował sobie jakiś wpis z bazy bezpowrotnie i prosi by go przywrócić. I teraz co ?

1. Nie można przywrócić całej bazy do poprzedniego stanu bo skasują się obecne dokonane już zmiany dla tego czy innego użytkownika.
2. Zamiast kasować wpis mogę zrobić SoftDelete czyli wpis będzie nadal ale niewidoczny dla systemu, to sprawia że baza będzie większa a jak wiemy w MYSQL skasowanie danych z tabeli zmniejsza tym samym plik danej tabeli. (kiedyś tak nie było)
3. Ostatnią kopie zapasową rozwijam na systemie testowym (czy przeznaczonym do takich zadań) i ręcznie przywracam wpis(wpisy) do bazy ?

Czy jak właściwie to powinno być zrobione ?

A czemu nie masz osobnej bazy dla każdego usera? Wiem, ze nie jest to odpowiedź na Twoje pytanie, ale tak się zastanawiam - jakie argumenty Cię przekonały do trzymania wszystkiego w jednej bazie?

No wyobraź sobie że masz 1000 klientów i musisz teraz podczas nowej wersji zaktualizować jakies pola w bazie w sensie tp dodac jakies pole czy nowa tabelke xD, Jeśli uzytkownik będzie potrzebowal zwiekszenia bazy czy odzielenia danych moze zamowic taki server z oprogramowaniem do swojej lokalizacji i wpiac w lokalna siec

Jeśli idziesz w tysiące/dziesiątki tysięcy to rzeczywiście może to mieć sens. Bardziej myślałem, że masz ich kilkudziesięciu/kilkuset. Aczkolwiek - co do zmian hurtowych - odpalasz jakiś skrypt, po kolei na wszystkich bazach robisz ALTER i nie jest to coś nierealnego.

Nie kasuj danych od razy. Oznacz rekord jako skasowany i dopiero np po 30 dniach do kosza z nim. Daj klientowi możliwość przywracania sobie danych samemu - inaczej się zajedziesz bezsensowną robotą i bierz kasę za trzymanie danych historycznych.

Zależy jak często użytkownicy robią taki numer. :) Jak rzadko to punkt 3, jak często to 2...

A czy nie możesz mieć dwóch replikujących się baz danych w trybie master-slave ale na tej drugiej ograniczyć operacje (np. zabronić operacji drop? ). No i pozostaje tez opcja odzyskania z logów.

@enclude: Tylko duplikacja baz zabezpieczy raczej przed awarią głównego serwera - np. padną dyski czy system plików, albo serwerownia pójdzie z dymem śladami OVH. Ale jeśli ktoś wykona jakieś operacje na bazie i zostaną one poprawnie wykonane (poprawnie - nie w sensie logiki czy celowości, ale poprawnie - w sensie, że baza wykona te zapytania, które otrzyma) to stan bazy po takiej operacji zostanie przeniesiony na replikę. A co za tym idzie - zrobisz jakieś DELETE * FROM xxx WHERE 1=1 i po kilku sekundach na obu instancjach bazy będziesz miał pozamiatane.

Zauważ, że OP pisał o zabezpieczeniu przed omyłkowym skasowaniem jakichś danych przez użytkownika a nie o awarii serwera czy utracie danych z przyczyn będących jakąś awarią.

@cerrato: Zauważ co napisałem w nawiasie, zaproponowałem aby na slave cofnąć uprawnienia DELETE/DROP (lub podobne), oraz też aby logować wszystkie zapytania i ich wyniki.

Jak zablokujesz DELETE/DROP to może powstać dość duży rozjazd - bo albo te zmiany będą zasysane z głównej bazy, albo będziemy mieli rozjazd trudny do ogarnięcia. Poza tym - jeszcze są inne rzeczy, które też mogą namieszać - chociażby UPDATE/ALTER. I jak to wszystko poblokujemy to nie wiem, czy można mówić o tym, że mamy duplikację - a raczej jakąś wariację na temat bazy pierwotnej.

@cerrato: Dobrze a co z zapisywaniem każdej operacji wraz z wynikiem do pliku?

Ja uważam, że ta opcja jest sensowna, ale cześć ludzi twierdzi, że to jest overkill. Tylko tak naprawdę to nadal mamy problem z tym, że jak będzie chciał odtworzyć część zmian, to jest ręczne grzebanie i rzeźbienie - czy to w backupie bazy, czy odtwarzanie z logów.

@cerrato: Pytanie co jest inwazyjniejsze? Czy zrobienie INSERT usuniętego wpisu? Czy powrót do punktu w czasie dla dziesiątek klientów, bo ktoś coś zjeb***? a co do Update, to pewien system, którym wcześniej zarządzałem miał tak, ze robiąc update wpisu właściwie robił się INSERT tego wpisu ale ze zwiększonym licznikiem wersji (osobna kolumna) i w przypadku SELECT tylko ten o najwyższym numerze wersji był brany pod uwagę.

To jest fajna opcja - tylko w przypadku dużej ilości danych i częstego ich poprawiania, baza może mocno puchnąć.

@cerrato: Tak, ale można mieć dwie bazy. W jednej trzymać najnowszy rekord, a w drugiej archiwalne, a nawet trzecią i w niej trzymać tylko określoną ilość danyc (np. ostatnie 14 dni)

nie no to już zrobiłem SoftDelete w bazie po skasowaniu rekordow dodaje sie data w polu deleted_at i corn casuje te rekordy jesli jest ponad 30 dni. także przy wyciaganiu danych Model::withTrash() poakzuje wszystkie dane te usuniete tez i uzytkownik moze je przywrocic ale po 30 dniach sie kasuje. Kopia zapasowa jest robiona często więc jesli po 30 dniach np za 3 miesiace użytkownik będzie chcial coś przywrocic to wtedy musi zaplacic za rozwiniecie bazy i przywrocenei rekordów tylko dla niego. A to nie bedzie trudne przywroci sie ze starymi ID ktore wiasomo ze sie nie powotorza po ich fizycznym skasowaniu. Zobacze jak sie to sprawdzi w zyciu

A przez jaki czas chcesz trzymać backupy? Bo wcześniej pisałeś o tysiącach userow. Codziennie (albo i częściej) robiona kopia, razy kilka miesięcy, to moze być dość konkretny rozmiar danych do trzymania.

Poza tym - jak chcesz przejrzeć bazy z ostatnich 3 miesięcy, gdy dostaniesz informacje, że jakiś czas temu miałeś coś o projekcie pani Basi, teraz już nie ma, a trzeba to odkopać i znaleźć tam numer do kierownika z jakiejś firmy, która miała zapewnić kontakt do kogoś od nagłośnienia? Zero konkretów, nikt nie pamięta jak się facet nazywał ani kiedy to zostało skasowane. Trochę słabo to widzę. Jeszcze w ciągu tych 30 dni, gdy masz soft-delete to możesz klientowi pokazać wszystko, co zostało skasowane i niech sobie sam szuka. Ale później to musisz sam ręcznie przeglądać bazy. Czy może chcesz jakaś odtworzyć jako osobnego klienta i nieco sobie tam szuka? Napisz proszę, jaki masz pomysł na to.

Może źle to opisałem, pomysł jest na synchroniczną przyrostową kopię bazy danych. Baza danych zawiera tabele, a w niej dwa rekordy. O godzinie 00:30 robiona jest kopia bazy danych. Następnie klienci robia jakieś rzecz np dochodzi 10 rekordów czyli jest już 12. Z czego 4 sa skasowane. Czyli robiąc synchro do bazy zapasowej wybieram dane z tabeli gdzie ID > od ostatniego rekordu. pobieram 10 rekordów i wstawiam je do bazy zapasowej. z czego 4 sa jako soft delete.

Następni kolejny dzien i kasuje mu te rekordy ktore powinny byc skasowane, baza danych sie zmniejsza tak? a ze mam synchro u siebie to jak klient doda kolejne rokordy do tabeli to ja robiac synchro biore kolejna porcje dzienna rekordow od id > niz moje ostatnie itd.

Jemu baza danych sie zmniejszy ale moja baza zapasowa jest przyrostowa. Przy pytanie o jakis rekord sprzed roku, sysytem wyszuka dany rekord bo soft delete jest skasowane tylko na produkcji a nie na mojej zapasowej.