TL;DR: Przed każdą aktualizacją SuiteCRM należy zabezpieczyć dwie niezależne warstwy: pliki aplikacji (tar) i bazę danych (mysqldump). Backup trzeba zweryfikować przed rozpoczęciem upgrade’u, a w razie niepowodzenia aktualizacji przywrócić system z kopii w kolejności: zatrzymanie serwera WWW → przywrócenie plików → przywrócenie bazy → weryfikacja logów. Pełny backup plików i bazy średniej instalacji SuiteCRM zajmuje zwykle od kilku do kilkunastu minut, w zależności od wielkości bazy danych i liczby załączników w katalogu upload/.

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?

Kompletny backup SuiteCRM obejmuje dwie niezależne warstwy: warstwę plikową i bazę danych. Pominięcie którejkolwiek z nich uniemożliwia skuteczne przywrócenie systemu.

Warstwa plikowa to katalog instalacyjny aplikacji, w skład którego 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 SuiteCRM krok po kroku?

Backup SuiteCRM wykonuje się w trzech krokach: zabezpieczenie plików, zabezpieczenie bazy danych i – opcjonalnie – automatyzacja tego procesu przez cron.

Jak zrobić backup plików przez terminal?

Najszybszą i najbardziej niezawodną metodą backupu plików 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.

Jak zrobić backup bazy danych SuiteCRM?

Backup bazy danych SuiteCRM wykonuje się poleceniem mysqldump:

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).

Jak zautomatyzować backup SuiteCRM za pomocą crona?

Backup SuiteCRM automatyzuje się poprzez zaplanowanie zadań cron, ponieważ ręczne tworzenie kopii zapasowych jest podatne na błędy ludzkie.

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, serwer zdalny) sprawdza się narzędzie rclone, które obsługuje kilkadziesiąt dostawców chmury i umożliwia szyfrowanie archiwów przed transferem.

Jak przygotować się do aktualizacji SuiteCRM?

Przed uruchomieniem Upgrade Wizarda należy wykonać cztery weryfikacje: sprawdzić wymagania systemowe, wyłączyć schedulery, włączyć tryb maintenance i potwierdzić kompletność backupu.

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.

Jak przeprowadzić aktualizację SuiteCRM?

Aktualizację SuiteCRM przeprowadza się przez wbudowany Upgrade Wizard dostępny w panelu administracyjnym, po pobraniu odpowiedniej paczki z oficjalnego repozytorium GitHub projektu.

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

Najczęstsze problemy podczas aktualizacji SuiteCRM:

• 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

Kiedy i jak zrobić roll-back po nieudanej aktualizacji SuiteCRM?

Roll-back SuiteCRM polega na przywróceniu systemu ze stanu sprzed aktualizacji przy użyciu wcześniej wykonanego backupu plików i bazy danych.

Kiedy roll-back jest konieczny?

Roll-back jest konieczny, gdy po aktualizacji pojawi się jeden z następujących sygnałów: biały ekran aplikacji (HTTP 500), błędy PHP widoczne w logach serwera, brakujące rekordy lub dane, niedostępność kluczowych modułów albo niemożność zalogowania się do systemu mimo poprawnych danych.

Jak przywrócić pliki SuiteCRM z backupu?

Pliki SuiteCRM przywraca się poprzez zatrzymanie serwera WWW, usunięcie uszkodzonego katalogu aplikacji i rozpakowanie archiwum backupu w jego miejsce:

# 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

Jak przywrócić bazę danych SuiteCRM z backupu?

Bazę danych SuiteCRM przywraca się poleceniem mysql z pliku dumpa SQL wykonanego przed aktualizacją:

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.

Co sprawdzić po roll-backu?

Po przywróceniu systemu należy wykonać sześć czynności kontrolnych:

• 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

Jakie są dobre praktyki backupu SuiteCRM?

Cztery dobre praktyki minimalizują ryzyko utraty danych przy aktualizacji SuiteCRM: zasada 3-2-1, środowisko stagingowe, dokumentacja wersji i monitoring po wdrożeniu.

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.