Planowanie kwartalnego czyszczenia nieaktywnych kont przed kopią zapasową phpBB przy zachowaniu dostępu moderatorów do dzienników

Administratorzy prowadzący małe lub średnie fora phpBB często stają przed pytaniem, w jakiej kolejności usuwać nieaktywne konta, aby nie zakłócić dostępu moderatorów do dzienników zmian. Zamiast działać ad hoc, warto wprowadzić stały, kwartalny cykl, który łączy czyszczenie kont z przygotowaniem kopii zapasowej. Proces ten wymaga wcześniejszego ustalenia jasnych kryteriów, weryfikacji wpływu na tabele logów oraz precyzyjnego ograniczenia dostępu do wybranych plików tylko na czas wykonywania kopii. Dzięki temu dzienniki moderacji pozostają kompletne, a role zespołu nie ulegają przypadkowym zmianom.

Taki cykl zakłada wcześniejsze zdefiniowanie kryteriów nieaktywności, sprawdzenie wpływu na tabele logów oraz ograniczenie dostępu do plików tylko na czas wykonywania kopii. Poniżej opisano praktyczne kroki, które można wdrożyć bez dodatkowych rozszerzeń. Każdy etap opiera się na standardowych mechanizmach phpBB i może być powtarzany co trzy miesiące bez ryzyka utraty spójności danych. Ważne jest, aby nie przyspieszać żadnej fazy i zawsze dokumentować wykonane czynności w pliku tekstowym przechowywanym poza serwerem.

Definiowanie kryteriów nieaktywności kont

Przed rozpoczęciem czyszczenia należy ustalić, po jakim okresie konto uznaje się za nieaktywne. W phpBB wystarczy sprawdzić datę ostatniego logowania w tabeli users oraz liczbę postów. Typowe progi to 18 miesięcy bez logowania i zero postów w tym okresie. Kryteria te zapisuje się w osobnym dokumencie dostępnym dla zespołu, aby uniknąć przypadkowego usunięcia kont moderatorów lub administratorów. Warto też wykluczyć konta oznaczone jako założycielskie lub posiadające uprawnienia specjalne. Decyzja o progu powinna zależeć od tempa aktywności forum: na forach o niskim ruchu można wydłużyć okres do 24 miesięcy, natomiast na forach o średniej aktywności wystarczy 12 miesięcy. Przed ostatecznym przyjęciem progu należy wykonać zapytanie SELECT COUNT(*) FROM phpbb_users WHERE user_lastvisit < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 18 MONTH)) AND user_posts = 0, aby oszacować liczbę kont przeznaczonych do usunięcia. Zbyt krótki próg prowadzi do usunięcia kont użytkowników, którzy logują się sporadycznie, na przykład raz w roku podczas urlopu. Zbyt długi próg z kolei powoduje niepotrzebne powiększanie bazy danych i wydłuża czas tworzenia kopii zapasowej.

Po ustaleniu progu warto przygotować listę kont do weryfikacji ręcznej. Lista ta zawiera kolumny z user_id, username, user_lastvisit oraz user_posts. Moderatorzy lub administratorzy przeglądają listę i oznaczają konta, które mimo spełnienia kryteriów powinny zostać zachowane, na przykład konta osób prowadzących archiwalne wątki. Taki przegląd zapobiega utracie kontekstu historycznego w dziennikach moderacji. Warunkiem skuteczności tej metody jest regularne aktualizowanie dokumentu z kryteriami po każdej zmianie regulaminu forum.

Kolejność weryfikacji dzienników moderacji

Przed usunięciem kont sprawdza się, czy w tabeli logów nie ma wpisów powiązanych z tymi kontami. W phpBB dzienniki moderacji znajdują się głównie w tabeli log i są powiązane z user_id. Usunięcie konta bez wcześniejszego archiwum może spowodować utratę kontekstu wpisów. Prosta procedura polega na wyeksportowaniu wybranych rekordów z tabeli log do pliku CSV przed jakąkolwiek operacją usuwania. Eksport wykonuje się zapytaniem SELECT ograniczonym do daty i user_id kont planowanych do usunięcia. Plik CSV należy przechowywać przez co najmniej dwa pełne cykle kwartalne, aby w razie potrzeby można było odtworzyć historię działań moderatora.

Po eksporcie sprawdza się, czy w wynikach nie pojawiają się wpisy dotyczące przydzielania uprawnień lub usuwania postów. Jeżeli takie wpisy istnieją, konto należy przenieść do grupy tymczasowej zamiast usuwać. Warunkiem poprawnego wykonania tego kroku jest posiadanie uprawnień do odczytu tabeli log bez możliwości jej modyfikacji. Typowym błędem jest pominięcie tabeli log_topics lub log_forums, co prowadzi do niekompletnych archiwów. Przed rozpoczęciem eksportu warto upewnić się, że baza danych ma włączone binlogi, aby w razie awarii można było cofnąć zmiany.

Ograniczanie dostępu do plików przed kopią zapasową

Po weryfikacji dzienników należy ograniczyć dostęp do katalogów includes i cache. W praktyce oznacza to zmianę uprawnień na 750 dla plików PHP i 700 dla katalogów na czas tworzenia kopii. Taka zmiana uniemożliwia jednoczesną modyfikację plików przez skrypty forum. Moderatorzy zachowują dostęp do panelu administracyjnego, ponieważ uprawnienia do plików dzienników w katalogu store pozostają niezmienione. Po zakończeniu kopii uprawnienia przywraca się do wartości wyjściowych. Przed zmianą uprawnień należy sprawdzić, czy żaden proces cron nie próbuje w tym momencie odczytać plików z katalogu cache.

Zmianę uprawnień wykonuje się za pomocą poleceń chmod w terminalu lub przez panel hostingowy. Po każdej zmianie warto uruchomić testowe żądanie HTTP, aby upewnić się, że forum nadal działa dla uprawnionych użytkowników. Warunkiem bezpiecznego ograniczenia dostępu jest wcześniejsze wyłączenie wszystkich aktywnych sesji moderatorów. Typowym błędem jest pozostawienie uprawnień 755 na katalogu store, co umożliwia nieautoryzowany zapis dzienników podczas tworzenia kopii. Po przywróceniu uprawnień należy ponownie zweryfikować, czy moderatorzy mogą przeglądać dzienniki w panelu administracyjnym.

Usuwanie kont a zachowanie spójności ról

Usunięcie konta powoduje automatyczne usunięcie powiązanych rekordów z tabeli user_group. Aby zachować spójność, przed usunięciem przenosi się użytkownika do grupy „Usunięci” lub po prostu archiwizuje jego identyfikator w osobnej tabeli tymczasowej. Po operacji sprawdza się, czy żadna rola moderatorska nie straciła przypisania. W panelu administracyjnym przegląda się listę uprawnień w sekcji Zarządzanie grupami i upewnia się, że liczba moderatorów w każdej kategorii pozostała niezmieniona. Przed usunięciem należy wykonać zapytanie SHOW GRANTS, aby potwierdzić, że konto bazy danych używane przez phpBB ma uprawnienia do kasowania rekordów w tabelach users i user_group.

Po usunięciu kont warto uruchomić zapytanie optymalizujące tabele, na przykład OPTIMIZE TABLE phpbb_users, phpbb_user_group. Optymalizacja zmniejsza fragmentację i skraca czas kolejnych kopii zapasowych. Warunkiem skuteczności tego etapu jest wcześniejsze wyeksportowanie tabeli user_group do pliku SQL. Typowym błędem jest usunięcie kont bez sprawdzenia, czy użytkownik pełnił funkcję moderatora w ukrytych kategoriach. W takim przypadku uprawnienia mogą pozostać w tabeli acl_users, co prowadzi do niespójności po przywróceniu kopii zapasowej.

Integracja z harmonogramem kopii zapasowych

Cały proces czyszczenia kont należy wykonać co najmniej 48 godzin przed zaplanowaną kopią zapasową. Dzięki temu baza danych ma czas na wykonanie operacji usuwania i indeksowania, a dziennik zmian nie zawiera niekompletnych wpisów. Kopia zapasowa tworzona jest dopiero po przywróceniu standardowych uprawnień do plików. W ten sposób plik kopii zawiera spójny stan dzienników moderacji i aktualne role. Przed rozpoczęciem kopii należy wyłączyć wszystkie aktywne połączenia do bazy danych za pomocą polecenia FLUSH TABLES WITH READ LOCK.

Po zakończeniu kopii sprawdza się rozmiar pliku kopii i porównuje go z poprzednimi kopiami. Jeśli rozmiar jest mniejszy o więcej niż 15 procent, oznacza to, że usunięto znaczną liczbę rekordów i proces przebiegł poprawnie. Warunkiem poprawnej integracji jest posiadanie osobnego harmonogramu dla kopii dzienników moderacji. Typowym błędem jest uruchamianie kopii zapasowej natychmiast po usunięciu kont, co może spowodować, że dziennik transakcji bazy danych nie zostanie w pełni zapisany.

Przygotowanie i testowanie w środowisku izolowanym

Zanim cykl zostanie uruchomiony na forum produkcyjnym, należy przetestować całą sekwencję w środowisku izolowanym. Środowisko to powinno zawierać identyczną wersję phpBB oraz zbliżoną liczbę kont i wpisów w dziennikach. Test polega na wykonaniu wszystkich kroków z pominięciem rzeczywistego usunięcia kont – zamiast DELETE używa się SELECT. Po teście sprawdza się, czy uprawnienia moderatorów do dzienników pozostały niezmienione.

Wyniki testu zapisuje się w dokumencie zawierającym czas każdego etapu oraz ewentualne błędy. Warunkiem przydatności testu jest użycie kopii bazy danych nie starszej niż siedem dni. Typowym błędem jest pominięcie testu uprawnień do katalogu store, co prowadzi do problemów na forum produkcyjnym. Po pozytywnym teście można przystąpić do wdrożenia cyklu na forum właściwym.

Ograniczenia i typowe pułapki

Metoda nie nadaje się do forów z bardzo dużą liczbą kont, ponieważ ręczne eksporty dzienników stają się czasochłonne. W takich przypadkach konieczne jest wcześniejsze przygotowanie skryptu powłoki, ale skrypt ten musi być testowany w środowisku odizolowanym. Nie należy usuwać kont, które posiadają prywatne wiadomości w tabeli privmsgs. Usunięcie takiego konta może spowodować osierocone rekordy, które utrudniają późniejsze przywracanie bazy z kopii. Przed usunięciem kont z prywatnymi wiadomościami należy najpierw wyczyścić tabelę privmsgs_to i privmsgs.

Innym ograniczeniem jest brak możliwości cofnięcia operacji usunięcia kont po wykonaniu kopii zapasowej. Dlatego każdy etap musi być poprzedzony weryfikacją listy kont. Typowym błędem jest ignorowanie kont z uprawnieniami do wielu kategorii jednocześnie, co prowadzi do niespójności ról po przywróceniu kopii. Dokumentacja każdego cyklu powinna zawierać listę pominiętych kont wraz z uzasadnieniem.

Przywracanie uprawnień i weryfikacja końcowa

Po zakończeniu kopii zapasowej uprawnienia do plików przywraca się w odwrotnej kolejności. Najpierw przywraca się uprawnienia do katalogu includes, następnie do cache. Po przywróceniu sprawdza się, czy moderatorzy mogą przeglądać dzienniki w panelu administracyjnym. Weryfikacja obejmuje sprawdzenie, czy liczba wpisów w tabeli log nie uległa zmianie w porównaniu z eksportem wykonanym przed czyszczeniem.

Ostatnim krokiem jest aktualizacja dokumentu z harmonogramem na kolejny kwartał. Warunkiem poprawnego zakończenia cyklu jest potwierdzenie przez co najmniej dwóch członków zespołu, że wszystkie etapy zostały wykonane zgodnie z procedurą. Typowym błędem jest pominięcie weryfikacji uprawnień do pliku config.php, co może uniemożliwić przyszłe aktualizacje phpBB. Po zakończeniu cyklu warto wykonać testowe przywracanie kopii zapasowej na środowisku izolowanym, aby potwierdzić, że dzienniki moderacji są dostępne.