Aktualizacja systemu CRM w działającym środowisku produkcyjnym należy do operacji, które wymagają starannego przygotowania. Nawet poprawnie przeprowadzony upgrade może ujawnić konflikty z niestandardowymi modułami, zmienione zachowanie API lub niekompatybilności po stronie serwera. Skutki bywają poważne: niedostępność systemu, błędy w przetwarzaniu danych sprzedażowych czy utrata konfiguracji wypracowanej przez miesiące. Dlatego backup wykonany bezpośrednio przed aktualizacją oraz gotowy plan przywrócenia systemu to nie opcja – to warunek konieczny każdej aktualizacji.

Co obejmuje kompletny backup SuiteCRM

SuiteCRM składa się z dwóch niezależnych warstw, które muszą być zabezpieczone osobno: warstwy plikowej oraz bazy danych. Pominięcie którejkolwiek z nich uniemożliwia skuteczne przywrócenie systemu.

Warstwa plikowa obejmuje katalog instalacyjny aplikacji. W jego skład wchodzą:

• config.php i config_override.php – pliki przechowujące parametry połączenia z bazą danych, ustawienia sesji i konfigurację środowiska
• katalog custom/ – wszelkie modyfikacje wprowadzone przez administratora lub dewelopera: niestandardowe moduły, rozszerzenia, layouty, słowniki
• katalog upload/ – załączniki powiązane z rekordami CRM (dokumenty, zdjęcia kontaktów, pliki ofert)
• katalog themes/ – jeśli zastosowano niestandardowy motyw graficzny

Warstwa bazy danych to dump schematu i danych MySQL lub MariaDB. Zawiera całą historię transakcji, rekordy kontaktów, szanse sprzedaży, logi aktywności oraz konfigurację modułów przechowywaną w tabelach.

Jak wykonać backup – krok po kroku

Backup plików przez terminal

Najszybszą i najbardziej niezawodna metodą jest spakowanie całego katalogu aplikacji za pomocą narzędzia tar:

tar -czvf /backup/suitecrm_files_$(date +%F).tar.gz /var/www/html/suitecrm

Flaga $(date +%F) automatycznie dołącza bieżącą datę do nazwy archiwum, co eliminuje ryzyko nadpisania wcześniejszych kopii. Archiwum należy zapisać poza katalogiem aplikacji – najlepiej na osobnym wolumenie lub zdalnym zasobie.

Backup bazy danych

mysqldump -u [użytkownik] -p[hasło] [nazwa_bazy] > /backup/suitecrm_db_$(date +%F).sql

Po wykonaniu dumpa warto zweryfikować jego integralność:

mysql -u [użytkownik] -p[hasło] --execute="SELECT COUNT(*) FROM accounts;" [nazwa_bazy] < /backup/suitecrm_db_$(date +%F).sql

Alternatywnie, dla środowisk bez dostępu SSH, dump bazy można wykonać przez phpMyAdmin (zakłada Export -> format SQL -> Quick export) lub z poziomu panelu hostingowego (cPanel: Backup Wizard, Plesk: Backup Manager).

Automatyzacja backupu przez cron

Ręczne tworzenie kopii zapasowych jest podatne na błędy ludzkie. Zalecanym podejściem jest harmonogram wykonywany automatycznie:

0 2 * * * /usr/bin/mysqldump -u suitecrm_user -pHaslo suitecrm_db > /backup/suitecrm_db_$(date +\%F).sql

30 2 * * * tar -czvf /backup/suitecrm_files_$(date +\%F).tar.gz /var/www/html/suitecrm

Powyższy przykład uruchamia backup bazy o 2:00, a plików o 2:30 każdej nocy, Kopie starsze niż 30 dni można automatycznie usuwać poleceniem find /backup -mtime +30 – delete.

Do replikacji backupów do zewnętrznych zasobów (S3, Google Drive, sewer zdalny) sprawdza się narzędzie rclone, które obsługuje kilkadziesiąt dostawców chmury i umożliwia szyfrowanie archiwów przed transferem.

Przygotowanie do aktualizacji

Przed uruchomieniem Upgrade Wizarda należy wykonać kilka weryfikacji:

Sprawdzenie wymagań systemowych. Każda wersja SuitecRM precyzuje minimalne wersje PHP, MySQL/MariaDB oraz wymagane rozszerzenia PHP (np. imap, curl, mbstring). Niezgodność środowiska z wymaganiami nowej wersji to najczęstsza przyczyna niepowodzeń aktualizacji.

Wyłączenie schedulerów. Przed aktualizacją należy wstrzymać cron SuiteCRM, aby żaden proces w tle nie modyfikował bazy danych w trakcie operacji upgrade’u. W panelu administracyjnym: Admin -> Schedulers – wyłączyć wszystkie aktywne zadania.

Tryb maintenance uniemożliwia logowanie użytkownikom podczas aktualizacji:

// config_override.php
$sugar_config['site_offline'] = true;
$sugar_config['site_offline_message'] = 'System jest chwilowo niedostępny z powodu prac konserwacyjnych.';

Weryfikacja backupu. Przed przystąpieniem do upgrade’u należy upewnić się, że archiwum plików i dump bazy danych są kompletne i możliwe do odczytu. Otwarcie pliku .tar.gz oraz wykonanie testowego zapytania na przywróconej bazie to minimum, które pozwala uniknąć sytuacji, w której backup okazuje się uszkodzony dokładnie wtedy, gdy jest potrzebny.

Przeprowadzenie aktualizacji SuiteCRM

Paczki upgrade dostępne są na oficjalnym repozytorium GitHub projektu SuiteCRM. Należy pobrać plik odpowiedni dla posiadanej wersji i zalogować się do panelu administracyjnego.

Ścieżka w panelu: Admin -> Upgrade Wizard. Kreator przeprowadza przez kolejne etapy: weryfikację środowiska, wgrane paczki, wykonanie migracji bazy danych i plików.

Najczęstsze problemy podczas aktualizacji:

• Przekroczenie limitu max_execution_time – należy zwiększyć wartość w php.ini do do najmniej 300 sekund
• Niewystarczający limit memory_limit – zalecane minimum 256 MB, dla większych instalacji 512 MB
• Błędy uprawnień – katalog aplikacji musi być możliwy do zapisania przez proces serwera WWW
• Konflikty w katalogu custom/ – niestandardowe rozszerzenia pisane pod starszą wersję API mogą wymagać aktualizacji po stronie dewelopera

Roll-back – przywracanie systemu po nieudanej aktualizacji

Kiedy roll-back jest konieczny

Sygnałami wymagającymi natychmiastowego przywrócenia poprzedniej wersji są: biały ekran aplikacji (HHTP 500), błędy PHP widoczne w logach serwera, brakujące rekordy lub dane, niedostępność kluczowych modułów oraz niemożność zalogowania się do systemu mimo poprawnych danych.

Przywracanie plików

# Zatrzymanie serwera WWW
systemctl stop apache2 # lub: systemctl stop nginx
# Usunięcie uszkodzonego katalogu aplikacji
rm -rf /var/www/html/suitecrm
# Przywrócenie z archiwum
tar -xzvf /backup/suitecrm_files_YYYY-MM-DD.tar.gz -C /var/www/html/
# Przywrócenie uprawnień
chown -R www-data:www-data /var/www/html/suitecrm
chmod -R 755 /var/www/html/suitecrm
chmod -R 775 /var/www/html/suitecrm/cache /var/www/html/suitecrm/upload /var/www/html/suitecrm/custom
# Uruchomienie serwera WWW
systemctl start apache2

Przywracanie bazy danych

mysql -u [użytkownik] -p[hasło] [nazwa_bazy] < /backup/suitecrm_db_YYYY-MM-DD.sql

W przypadku hostingu współdzielonego bez dostępu SSH: phpMyAdmin -> zakładka Import -> wskazanie pliku .sql -> Go.

Weryfikacja po roll-backu

Po przywróceniu systemu należy wykonać następujące czynności:

• Sprawdzić logi aplikacji: /var/www/html/suitecrm/suitecrm.log – szukać wpisów FATAL i ERROR
• Sprawdzić logi PHP: /var/log/php_errors.log lub odpowiednik zależny od konfiguracji serwera
• Zalogować się do panelu administratora i zweryfikować działanie kluczowych modułów (Kontakty, Szanse sprzedaży, Raporty)
• Sprawdzić, czy harmonogramowe zadania (schedulery) działają poprawnie
• Wyłączyć tryb maintenance w config_override.php
• Poinformować użytkowników o przywróceniu systemu

Dobre praktyki

Zasada 3-2-1. Trzy kopie danych, na dwóch różnych nośnikach, z czego jedna jest przechowywana poza siedzibą lub w chmurze. W praktyce oznacza to: lokalny backup na serwerze, kopia na NAS w sieci wewnętrznej i replika na zewnętrznym zasobie chmurowym.

Środowisko stagingowe. Aktualizacja powinna być zawsze przetestowana na kopii produkcyjnej przed wdrożeniem na właściwym systemie. Środowisko stagingowe eliminuje większość niespodzianek i pozwala ocenić wpływ nowej wersji na niestandardowe moduły.

Dokumentacja wersji. Warto prowadzić dziennik zmian: data aktualizacji, wersja przed i po, osoba przeprowadzająca operację, ewentualne problemy i ich rozwiązania. Taki rejestr jest nieoceniony przy kolejnych aktualizacjach oraz w sytuacjach awaryjnych.

Monitoring po aktualizacji. Pierwsze 24-48 godzin po wdrożeniu nowej wersji to okres podwyższonego ryzyka. Warto w tym czasie aktywnie monitorować logi aplikacji, wydajność bazy danych oraz zgłoszenia od użytkowników.

Podsumowanie

Backup wykonany bezpośrednio przed aktualizacją i gotowy rollback producenta to dwa elementy, bez których żadna aktualizacja SuiteCRM w środowisku produkcyjnym nie powinna być przeprowadzona. Opisane powyżej kroki obejmują zarówno środowiska z pełnym dostępem SSH, jak i hosting współdzielony i mogą być zaadaptowane do konkretnej infrastruktury. Czas poświęcony na przygotowanie backupu jest zawsze krótszy niż czas potrzebny na odbudowanie systemu bez kopii zapasowej.

Jeśli zainteresował Cię ten temat, skontaktuj się z nami. Chętnie odpowiemy na pytania.