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.