Planowanie archiwizacji wybranych wpisów dzienników moderacji przed kopią zapasową phpBB w środowisku współdzielonym

Administratorzy phpBB prowadzący forum przez wiele lat często stają przed pytaniem, jak ograniczyć rozmiar bazy danych przed wykonaniem kopii zapasowej, nie tracąc jednocześnie informacji potrzebnych do późniejszej weryfikacji działań moderatorów. Wybór między pełną retencją a selektywną archiwizacją wpisów dzienników moderacji wymaga jasnych kryteriów, które można stosować rutynowo w środowisku współdzielonym. Decyzje te wpływają bezpośrednio na czas odtwarzania bazy oraz na możliwość sprawdzenia historii decyzji moderatorskich w razie sporów użytkowników.

Celem jest przygotowanie powtarzalnej procedury, która pozwala na oczyszczenie nieistotnych rekordów przed zablokowaniem dostępu do plików i bazy, a jednocześnie zapewnia, że zmiany ról moderatorów oraz decyzje dotyczące wątków pozostają dostępne na wypadek kontroli. Poniższa lista kontrolna skupia się na praktycznych decyzjach podejmowanych przed uruchomieniem narzędzia do kopii zapasowej. Uwzględnia ona ograniczenia typowe dla hostingu współdzielonego, gdzie nie zawsze można korzystać z pełnych uprawnień administracyjnych.

Określenie celu przechowywania dzienników

Przed przystąpieniem do archiwizacji należy ustalić, czy forum wymaga dzienników głównie do rozwiązywania sporów użytkowników, czy też do okresowych przeglądów pracy moderatorów. W pierwszym przypadku wystarczy zachować wpisy dotyczące zamknięć wątków, usunięć postów oraz zmian uprawnień. W drugim przypadku przydatne są także informacje o przeniesieniach między kategoriami i ostrzeżeniach. Kryterium to powinno wynikać z regulaminu forum oraz oczekiwań społeczności, a nie z ogólnych zaleceń.

Kryterium czasowe pomaga ograniczyć zakres: wpisy starsze niż dwanaście miesięcy, które nie dotyczą aktywnych wątków, można przenieść do osobnej tabeli lub usunąć po wcześniejszym wyeksportowaniu do pliku CSV. Takie podejście zmniejsza rozmiar tabeli bez utraty możliwości odtworzenia historii w razie potrzeby. Warunkiem stosowania tego kryterium jest wcześniejsze sprawdzenie, czy w regulaminie nie ma wymogu dłuższego przechowywania danych. Błędem jest automatyczne usuwanie wszystkich wpisów po upływie roku bez analizy ich związku z aktualnymi zgłoszeniami.

Identyfikacja wpisów nadających się do archiwizacji

W praktyce najwięcej miejsca zajmują wpisy o automatycznych akcjach systemowych, takich jak czyszczenie sesji czy aktualizacje uprawnień po instalacji rozszerzeń. Te rekordy rzadko są potrzebne po upływie kilku miesięcy i można je bezpiecznie usunąć przed kopią zapasową. Warto jednak wcześniej wygenerować raport zliczający typy akcji, aby upewnić się, że nie usuwamy wpisów związanych z ręcznymi decyzjami moderatorów.

Zachować należy natomiast wpisy dotyczące ręcznych decyzji moderatorów: zamknięcie lub otwarcie wątku, przeniesienie do innej kategorii, edycja postu przez moderatora oraz zmiana statusu użytkownika. Przed usunięciem warto sprawdzić, czy dany wpis jest powiązany z aktualnie otwartym zgłoszeniem w kolejce moderacji. Typowym błędem jest usuwanie wpisów o przeniesieniach wątków tylko dlatego, że wątek został później zamknięty. W środowisku współdzielonym takie działanie może utrudnić późniejsze odtworzenie logiki decyzji moderatorskich.

Przygotowanie tabeli pomocniczej

Zamiast usuwać dane od razu, utwórz tymczasową tabelę o nazwie phpbb_moderation_log_archive z taką samą strukturą jak phpbb_moderation_log. Skopiuj do niej wybrane rekordy za pomocą zapytania INSERT INTO … SELECT, ograniczając warunek do daty i typu akcji. Przed uruchomieniem zapytania należy wykonać kopię struktury tabeli za pomocą polecenia CREATE TABLE … LIKE, aby uniknąć różnic w indeksach i kluczach.

Po skopiowaniu sprawdź liczbę wierszy w obu tabelach. Dopiero gdy wynik zapytania SELECT COUNT(*) potwierdzi poprawną liczbę przeniesionych wpisów, można przystąpić do usuwania oryginalnych rekordów. Taka sekwencja minimalizuje ryzyko utraty danych w razie przerwania operacji. Warunkiem powodzenia jest dostęp do uprawnień INSERT i SELECT na poziomie bazy danych; w niektórych pakietach hostingowych te uprawnienia są domyślnie ograniczone i wymagają wcześniejszego zgłoszenia do administratora hosta.

Ograniczenie dostępu przed operacją

W środowisku współdzielonym należy najpierw zmienić uprawnienia pliku config.php na 400, a katalogu cache na 755 z usunięciem praw zapisu dla grupy. Pozwala to uniknąć jednoczesnego zapisu do dzienników podczas wykonywania zapytań archiwizacyjnych. Zmianę uprawnień warto wykonać przez panel zarządzania hostingiem, a nie przez FTP, ponieważ FTP może nie odzwierciedlać rzeczywistych uprawnień systemowych.

Po zakończeniu archiwizacji przywróć uprawnienia do wartości wyjściowych i zweryfikuj, czy moderatorzy nadal mają dostęp do dzienników w panelu administracyjnym. Test polega na zalogowaniu się kontem moderatora i wyświetleniu listy ostatnich akcji. Błędem jest pozostawienie obniżonych uprawnień na dłużej niż kilka godzin, ponieważ uniemożliwia to normalne działanie forum i może prowadzić do błędów przy próbie zapisu nowych postów.

Weryfikacja integralności po archiwizacji

Uruchom zapytanie sprawdzające spójność kluczy obcych między tabelą dzienników a tabelami wątków oraz użytkowników. Brakujące identyfikatory wskazują na konieczność przywrócenia części rekordów z kopii zapasowej sprzed archiwizacji. Warto także porównać sumy kontrolne wybranych kolumn przed i po operacji, aby wykryć ewentualne uszkodzenia danych.

Porównaj rozmiar bazy przed i po operacji. Spadek o więcej niż 15–20 procent zwykle oznacza, że usunięto zbyt wiele wpisów i należy zweryfikować kryteria wyboru. Warunkiem poprawnej weryfikacji jest wcześniejsze zapisanie rozmiaru tabeli w osobnym pliku tekstowym. Bez tego porównania trudno ocenić, czy archiwizacja przyniosła oczekiwany efekt zmniejszenia objętości kopii zapasowej.

Harmonogram powtarzania procedury

W przypadku forum o średnim natężeniu ruchu archiwizację warto wykonywać co sześć miesięcy, zawsze przed zaplanowaną kopią zapasową pełną. Dla forów o bardzo dużej liczbie postów rozsądny odstęp to trzy miesiące. Harmonogram należy dostosować do tempa przyrostu wpisów w tabeli moderation_log, które można monitorować za pomocą prostego zapytania zliczającego rekordy dodane w ostatnim kwartale.

Zapisz datę ostatniej archiwizacji w osobnym pliku tekstowym przechowywanym poza bazą. Pozwala to szybko sprawdzić, czy procedura została wykonana zgodnie z przyjętym harmonogramem przed kolejną aktualizacją phpBB. Typowym błędem jest wykonywanie archiwizacji tylko wtedy, gdy baza zaczyna osiągać limity hostingu; wtedy procedura jest wykonywana pod presją czasu i wzrasta ryzyko pomyłki przy wyborze rekordów do usunięcia.

Ograniczenia i ryzyka

Selektywna archiwizacja nie zastępuje pełnej kopii zapasowej bazy. W razie awarii serwera odtworzenie tylko zachowanych wpisów dzienników może być niewystarczające do pełnej rekonstrukcji historii moderacji. Dlatego przed każdą archiwizacją należy upewnić się, że istnieje aktualna pełna kopia zapasowa wykonana nie wcześniej niż dwadzieścia cztery godziny wcześniej.

Niektóre rozszerzenia zapisują własne informacje do tabeli moderation_log; przed archiwizacją należy upewnić się, że nie polegają one na obecności starszych rekordów. W razie wątpliwości lepiej zachować cały rok wpisów zamiast ryzykować niezgodność. Procedura archiwizacji wymaga uprawnień do wykonywania zapytań ALTER i DROP na tabelach tymczasowych. W niektórych pakietach hostingowych takie uprawnienia są ograniczone, co zmusza do wykonania operacji przez panel phpMyAdmin zamiast skryptu automatycznego.

Po zakończeniu wszystkich kroków warto przeprowadzić testowe odtworzenie małej części bazy na środowisku testowym, aby potwierdzić, że dzienniki zachowały spójność z pozostałymi tabelami. Taka weryfikacja pozwala wykryć problemy, które mogłyby ujawnić się dopiero po przywróceniu kopii na serwerze produkcyjnym.