Wprowadzenie​

Wybór odpowiedniego hostingu to kluczowa decyzja dla każdej firmy czy projektu. Czy lepiej postawić na VPS, czy zainwestować w serwer dedykowany? Łatwo tu popełnić błąd — albo przepłacimy, albo staniemy w obliczu braku zasobów. W tym artykule omówimy, kiedy tani VPS spełni swoje zadanie, a kiedy nie obejdzie się bez bare-metal.

VPS i serwer dedykowany – czym się różnią?​

• VPS (Prywatny serwer wirtualny) to wydzielona część fizycznego serwera z określonymi zasobami. Choć działa jak samodzielna maszyna, współdzieli „sprzęt” z innymi użytkownikami.
• Serwer dedykowany to natomiast cały fizyczny serwer, którego pełna moc obliczeniowa jest do twojej wyłącznej dyspozycji.

Sprawdźmy teraz, kiedy VPS będzie wystarczający, a kiedy warto zainwestować w serwer dedykowany.

Kiedy VPS jest idealnym wyborem​

1. Małe i średnie projekty​

Jeśli twoja strona lub aplikacja nie generuje dużych obciążeń, VPS to świetny wybór. Jest tańszy, a zasoby są wystarczające do większości zadań.

2. Środowisko testowe i deweloperskie​

VPS jest idealny do rozwoju, testowania i eksperymentowania. Możesz łatwo wdrożyć serwer, przywracać zmiany i instalować różne systemy operacyjne.

3. Startupy i rozwijające się projekty​

Jeśli twój projekt dopiero nabiera tempa, VPS pozwoli ci zacząć bez dużych kosztów. Wraz ze wzrostem zapotrzebowania możesz przejść na bardziej wydajny plan lub serwer dedykowany.

4. VPN/proxy​

Usługi takie jak VPN czy proxy nie wymagają dużej mocy obliczeniowej, dlatego VPS poradzi sobie z nimi bez problemu.

Kiedy serwer dedykowany jest koniecznością​

1. Bardzo obciążone projekty​

Jeśli twoja strona internetowa, CRM lub baza danych obsługuje tysiące użytkowników na minutę, VPS może sobie nie poradzić. Serwer dedykowany zapewni stabilność i odpowiednią wydajność.

2. Sklepy internetowe, usługi finansowe i SaaS​

Jeśli masz sklep internetowy, platformę finansową lub projekt SaaS, spadek prędkości = utrata przychodów. Serwer dedykowany gwarantuje maksymalną wydajność.

3. Projekty wymagające wysokiego poziomu bezpieczeństwa​

Jeśli przetwarzasz dane osobowe, informacje finansowe lub firmowe, lepszym wyborem będzie serwer dedykowany, który zapewnia wyższy poziom izolacji i bezpieczeństwa.

4. Serwery gier i streaming​

Jeśli planujesz uruchomić serwery gier (takie jak Minecraft, Valheim lub inne gry, które lubisz) lub przesyłać strumieniowo wideo, możesz potrzebować dedykowanej karty graficznej, szybszego magazynu i stabilnego połączenia o większej przepustowości. VPS może nie być w stanie sprostać tym wymaganiom.

Podsumowanie: co wybrać?​

VPS – jeśli potrzebujesz równowagi między ceną a zasobami: strony internetowe, blogi, małe serwisy, testy.

Serwer dedykowany – gdy kluczowa jest moc i stabilność: niezbędny dla dużych projektów, rozbudowanych baz danych i zaawansowanych produktów SaaS.

Jeśli masz wątpliwości, co wybrać, zawsze możesz zacząć od VPS i przejść na serwer dedykowany, gdy obciążenie wzrośnie. Najważniejsze to postawić na sprawdzonego dostawcę hostingu, który zagwarantuje niezawodność i wydajność.

Szukasz niezawodnego VPS lub serwer dedykowany w świetnej cenie? Wybierz kodu.cloud – potężne plany, całodobowe wsparcie z responsywnym zespołem zawsze gotowym pomóc w przypadku jakichkolwiek problemów z serwerem i niezawodna wydajność przez cały okres dzierżawy!

Jeśli przeglądarka wyświetla komunikat DNS_PROBE_FINISHED_NXDOMAIN, oznacza to, że nie może określić adresu IP żądanej strony. Może się to zdarzyć z różnych powodów:

• Nazwa domeny nie istnieje w serwerach DNS lub jej rejestracja wygasła.
• Serwer obsługujący strefę domenową jest niedostępny.
• DNS jest nieprawidłowo skonfigurowany na urządzeniu.
• Zakłócenia spowodowane przez VPN, antywirusa lub zaporę sieciową.
• Nieprawidłowe działanie dostawcy usług internetowych.

Towarzyszący tekst błędu może wyglądać nieco inaczej w różnych przeglądarkach:

• Google Chrome: „Ta witryna jest nieosiągalna”.
• Mozilla Firefox: „Niestety, nie udało się odnaleźć tej strony”.
• Microsoft Edge: „Niestety… nie można przejść do tej strony”.
• Safari: „Safari nie może znaleźć serwera”.

Jak określić przyczynę błędu?​

1. Sprawdź status domeny​

Na początek upewnij się, że wpisany adres jest poprawny. Jeśli wszystko się zgadza, sprawdź rejestrację domeny za pomocą ICANN Lookup. Wprowadź URL i zobacz, czy domena jest aktywna.

2. Dostępność przez proxy​

Spróbuj otworzyć stronę, korzystając z proxy, VPN lub innej sieci (np. mobilnej). Jeśli w tym przypadku strona działa, oznacza to, że problem najprawdopodobniej leży w ustawieniach twojego urządzenia lub sieci.

Jak naprawić błąd DNS_PROBE_FINISHED_NXDOMAIN​

Czyszczenie pamięci podręcznej​

Czasami przeglądarka lub system przechowuje nieaktualne wpisy DNS. Ich wyczyszczenie może pomóc w odświeżeniu ustawień.

• Windows:

1. Otwórz Wiersz poleceń (jako administrator): Start → wpisz cmd w wyszukiwaniu i naciśnij Enter. 
2. Uruchom polecenie:

ipconfig /flushdns

3. Uruchom ponownie przeglądarkę.

• macOS:

1. Otwórz Terminal: na klawiaturze naciśnij cmd + spacja, wpisz Terminal i naciśnij Enter.
2. Wpisz:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

3. Naciśnij klawisz Enter.

• Google Chrome:

1. W pasku adresu przeglądarki wpisz:

chrome://net-internals/#dns

2. Kliknij Clear host cache.

Aktualizacja adresu IP​

Jeśli wyczyszczenie pamięci podręcznej nie pomogło, spróbuj zmienić adres IP.

• Windows:

ipconfig /release
ipconfig /renew
netsh int ip set dns
netsh winsock reset

Zrestartuj system.

• macOS:

1. Przejdź do Ustawienia systemowe → Sieć.
2. Kliknij w usługę sieciową → Szczegóły → TCP/IP.
3. Kliknij Odśwież dzierżawę DHCP.

Korzystanie z alternatywnych serwerów DNS​

Problem może być związany z serwerami DNS dostawcy internetu. Spróbuj użyć Google DNS (8.8.8.8, 8.8.4.4) lub Cloudflare DNS (1.1.1.1, 1.0.0.1).

• Windows:

1. Otwórz Panel sterowania → Sieć i Internet → Centrum sieci i udostępniania.
2. Wybierz aktywne połączenie → Właściwości
3. W sekcji IP w wersji 4 (TCP/IPv4) wpisz:

• Podstawowy DNS: 8.8.8.8

• Dodatkowy DNS: 8.8.4.4

• macOS:

1. Otwórz Ustawienia systemowe.
2. Przejdź do sekcji Sieć.
3. Wybierz aktywne połączenie (np. Wi-Fi lub Ethernet) w lewym panelu.
4. Kliknij Szczegóły.
5. Przejdź do zakładki DNS.
6. W sekcji Serwery DNS kliknij + i dodaj następujące serwery DNS:

• 8.8.8.8 (Google DNS)
• 8.8.4.4 (Google DNS)

 lub

• 1.1.1.1 (Cloudflare DNS)
• 1.0.0.1 (Cloudflare DNS)

1. Kliknij OK, a następnie Zastosuj.

Ponowne uruchomienie usługi klienta DNS (Windows)​

1. Otwórz Wiersz poleceń jako administrator.
2. Wpisz:

net stop dnscache
net start dnscache

Sprawdzenie pliku hosts​

Plik hosts może zawierać nieprawidłowe wpisy blokujące dostęp do strony.

• Windows:

1. Otwórz Notatnik jako administrator.
2. Otwórz plik (Plik  →  Otwórz):

C:\Windows\System32\drivers\etc\hosts 

3. Usuń linie zawierające problematyczną domenę.

• macOS:

1. Otwórz plik hosts w edytorze tekstowym:

sudo nano /etc/hosts

2. Usuń linie zawierające problematyczną domenę.
3. Zapisz plik za pomocą skrótu Ctrl + O, a następnie wyjdź z edytora, naciskając Ctrl + X. 

Resetowanie flag Chrome​

Niektóre ukryte ustawienia przeglądarki mogły zostać zmienione.

1. W pasku adresu wpisz:

chrome://flags/

2. Kliknij Zresetuj wszystko.

Wyłączenie antywirusa i VPN​

Niektóre programy antywirusowe lub usługi VPN mogą blokować zapytania DNS. Tymczasowo je wyłącz i sprawdź, czy strona jest dostępna.

Sprawdzenie ustawień CDN​

Jeśli strona korzysta z Cloudflare lub innego CDN, spróbuj tymczasowo wyłączyć proxy dla tej domeny w panelu zarządzania CDN.

Restartowanie routera​

Czasami problem może dotyczyć routera. Spróbuj:

1. Wyłączyć router na 5 minut.
2. Włączyć go ponownie i sprawdzić połączenie.

Podsumowanie​

Błąd DNS_PROBE_FINISHED_NXDOMAIN jest związany z problemami DNS. Można go naprawić, czyszcząc pamięć podręczną, zmieniając serwery DNS, sprawdzając status domeny lub dostosowując ustawienia systemowe. Jeśli problem nadal występuje, skontaktuj się z dostawcą internetu.

Wprowadzenie​

Jeśli kiedykolwiek konfigurowałeś serwer pocztowy lub miałeś do czynienia z odwrotną weryfikacją DNS, prawdopodobnie spotkałeś się z rekordami PTR. Ale czym one właściwie są? Dlaczego często nie można samodzielnie skonfigurować rekordów PTR? Przyjrzyjmy się temu bliżej!

Co to jest rekord PTR?​

PTR (Pointer) — to typ rekordu DNS, który umożliwia konwersję adresu IP na odpowiadającą mu nazwę domeny. W przeciwieństwie do standardowych rekordów A, które mapują domenę na adres IP, rekordy PTR wskazują, do jakiej domeny przypisany jest dany adres IP.

Jak działa rekord PTR?​

Gdy serwer odbiera połączenie przychodzące, może zapytać odwrotny DNS (rDNS) o adres IP nadawcy. Jeśli rekord PTR jest skonfigurowany, otrzyma odpowiednią nazwę domeny. Jest to ważne dla:

• Konfigurowania serwerów pocztowych (serwery SMTP często wymagają PTR, aby poprawnie wysyłać wiadomości e-mail i nie zostać wrzuconym do spamu);
• Rozpoznawania adresów IP w logach i zwiększenia bezpieczeństwa;
• poprawnego działania niektórych usług zależnych od rDNS.

Dlaczego nie mogę samodzielnie skonfigurować rekordu PTR?​

Wielu użytkowników, którzy mają dostęp do zarządzania rekordami DNS, oczekuje, że będą w stanie utworzyć rekord PTR, tak jak rekord A lub CNAME. Jednak tu pojawia się kluczowy problem: Rekordy PTR nie są konfigurowane w hostingu DNS, lecz u dostawcy adresu IP (ISP, centrum danych lub dostawcy usług hostingowych).

Główne powody:​

1. Kontrola nad adresem IP – Rekordy PTR należą do właściciela puli adresów IP. Jeśli korzystasz z serwera dedykowanego lub VPS, właścicielem adresu IP jest twój dostawca hostingu, który powinien skonfigurować rekord PTR.
2. Brak dostępu do zarządzania rDNS – Nawet jeśli masz pełną kontrolę nad DNS swojej domeny, odwrotna strefa DNS (in-addr.arpa) jest zarządzana przez właściciela zakresu IP.
3. Wymagania dostawcy – Niektórzy dostawcy hostingu pozwalają na konfigurację PTR wyłącznie poprzez zgłoszenie do pomocy technicznej, a nie poprzez panel sterowania.
4. Dynamiczne adresy IP – Jeśli twój adres IP jest dynamiczny (np. w domowym połączeniu internetowym), twój dostawca prawdopodobnie nie pozwoli ci ustawić własnego rekordu PTR.

Jak skonfigurować rekord PTR?​

1. Skontaktuj się z dostawcą​

Aby stworzyć lub zmienić rekord PTR, należy skontaktować się z dostawcą hostingu lub ISP, który przypisał ci adres IP. Zwykle robi się to poprzez zgłoszenie do pomocy technicznej.

2. Podaj odpowiednią domenę​

Zazwyczaj dostawca wymaga, aby rekord PTR wskazywał na rzeczywistą domenę, która jest już skonfigurowana i rozwiązana w rekordzie A.

3. Sprawdź konfigurację​

Po zmianie rekordu PTR warto sprawdzić jego działanie za pomocą poniższej komendy:

Windows:

nslookup 123.123.123.123

Linux i MacOS:

dig -x 123.123.123.123

Podsumowanie​

Rekord PTR jest kluczowym elementem DNS, zwłaszcza dla serwerów pocztowych. Niemniej jednak, nie można go skonfigurować bez zgody właściciela adresu IP. Jeśli potrzebujesz utworzyć rekord PTR, skontaktuj się ze swoim dostawcą usług hostingowych, aby sprawdzić, czy istnieje możliwość jego konfiguracji. Prawidłowe ustawienie rekordu pomoże uniknąć problemów z dostarczaniem wiadomości e-mail i zwiększy wiarygodność twojego serwera.

Chcesz skutecznie przekierować użytkowników i wyszukiwarki na nowy adres URL? Przekierowanie 301 to twój najlepszy przyjaciel! Pomaga zachować pozycje SEO i uniknąć błędów 404. W tym artykule pokażemy, jak szybko i łatwo skonfigurować przekierowanie 301 w plikach .htaccess i na serwerach nginx.

Czym jest przekierowanie 301 i dlaczego jest potrzebne?​

Przekierowanie 301 to stałe przeniesienie z jednego adresu URL na inny. Jest niezbędne, gdy:

• Zmieniasz adres strony i chcesz zachować dotychczasowe pozycje w wyszukiwarkach.
• Łączysz kilka adresów URL w jeden.
• Chcesz uniknąć błędów 404 i utraty ruchu.

Jak skonfigurować przekierowanie 301 w .htaccess (Apache)​

1. Znajdź lub utwórz plik.htaccess

Plik.htaccess zazwyczaj znajduje się w katalogu głównym (roboczym) twojej strony. Jeśli go nie ma, utwórz nowy.

2. Dodaj następujący kod przekierowania

• Dla jednego URL:

Redirect 301 /old-page https://yoursite.com/new-page

• Dla przekierowania całej strony:

RewriteEngine On

RewriteCond %{HTTP_HOST} ^oldsite\.com$ [NC]

RewriteRule ^(.*)$ https://newsite.com/$1 [L,R=301]

Zamień oldsite.com i newsite.com na odpowiednio starą i nową domenę twojej strony. 

3. Zapisz plik

Zmiany zostaną zastosowane natychmiast.

Jak skonfigurować przekierowanie 301 w Nginx​

1. Otwórz plik konfiguracyjny nginx swojej strony

Połącz się z serwerem przez SSH i otwórz odpowiedni plik w edytorze tekstowym nano:

sudo nano /etc/nginx/sites-available/your-site.com.conf

Zamień yoursite.com na domenę swojej witryny. 

Jeśli nie można znaleźć takiego pliku, można znaleźć lokalizację pliku konfiguracyjnego za pomocą polecenia:

sudo grep -irl name /etc/nginx

2. Dodaj reguły przekierowania do bloku server

• Dla jednego URL:

server {

listen 80;

server_name oldsite.com;

return 301 https://newsite.com/new-page;

}

• Dla przekierowania całej strony:

server {

listen 80;

server_name oldsite.com;

return 301 https://newsite.com$request_uri;

}

3. Zapisz zmiany i zastosuj je

Zapisz plik za pomocą skrótu klawiaturowego "Ctrl + o" i zamknij edytor nano za pomocą "Ctrl + x". Następnie wprowadź zmiany poleceniem:

sudo systemctl reload nginx

Jak sprawdzić, czy przekierowanie działa?​

Po skonfigurowaniu upewnij się, że przekierowanie 301 działa:

• Otwórz stary URL w przeglądarce.

Przejdź na stary URL i upewnij się, że zostałeś przekierowany na nowy adres.

• Skorzystaj z narzędzi online do testowania przekierowań, na przykład Redirect Checker.

Nowoczesne protokoły HTTP/2 i HTTP/3 mogą znacząco przyspieszyć ładowanie stron, poprawić doświadczenie użytkowników i zwiększyć widoczność w wyszukiwarkach. Nie wszystko jest jednak takie proste: mają one zarówno plusy, jak i minusy. Przyjrzyjmy się, czym są, jakie zalety i wady niosą oraz jak je skonfigurować na swoim serwerze.

Czym są HTTP/2 i HTTP/3?​

HTTP/2 to zaktualizowana wersja protokołu HTTP/1.1, która umożliwia równoczesne ładowanie zasobów witryny, a nie pojedynczo. Dzięki temu czas odpowiedzi jest krótszy, a obciążenie serwera mniejsze.

HTTP/3 to jeszcze bardziej zaawansowana wersja, oparta na protokole QUIC działającym na UDP. Umożliwia bardziej stabilne połączenia, szczególnie w trudnych warunkach sieciowych.

Zalety​

1. HTTP/2

• Jednoczesne pobieranie zasobów strony (multipleksowanie).
• Zmniejszenie opóźnień dzięki kompresji nagłówków.
• Oszczędność transferu.

2. HTTP/3

• Szybkie nawiązywanie połączeń bez opóźnień.
• Odporność na utratę pakietów (szczególnie istotne dla internetu mobilnego).
• Świetna wydajność w niestabilnych sieciach.

Włączenie tych protokołów przyspieszy ładowanie strony, zwiększy jej wygodę dla użytkowników i przyniesie korzyści SEO.

Wady​

1. Kompatybilność

• Protokoły HTTP/2 i HTTP/3 nie są obsługiwane przez starsze przeglądarki i urządzenia. Na przykład niektóre wersje przeglądarki Internet Explorer i starsze urządzenia z systemem Android nie będą w stanie korzystać z tych protokołów.
• HTTP/3 korzysta z UDP, które może być blokowane przez niektóre firewalle lub filtry sieciowe.

2. Złożoność konfiguracji

• Nieprawidłowa konfiguracja HTTP/2 może obniżyć wydajność. Na przykład, jeśli nie używasz priorytetyzacji strumieni.
• HTTP/3 wymaga najnowszej wersji Nginx, OpenSSL i obsługi protokołu QUIC, co może być problematyczne na starszych serwerach.

3. Zasobożerność

• HTTP/3 wymaga więcej zasobów serwera, zwłaszcza przy dużej liczbie połączeń.

4. Zależność od HTTPS

• HTTP/2 działa wyłącznie przez HTTPS, co zwiększa koszty związane z instalacją i utrzymaniem certyfikatów.

5. HTTP/1.1 a wydajność HTTP/2/3

• HTTP/2 i HTTP/3 nie wykluczają wsparcia dla HTTP/1.1. Chociaż może to nieznacznie obniżyć wydajność, nie powoduje poważnych problemów, ponieważ HTTP/1.1 jest używane tylko przez klientów, którzy nie obsługują nowszych protokołów.

Jak włączyć HTTP/2 i HTTP/3 w Nginx?​

1. Sprawdzenie kompatybilności

Połącz się z serwerem przez SSH.

Sprawdź aktualną wersję Nginx:

sudo nginx -v

Aby włączyć HTTP/3, potrzebna jest wersja 1.25.0 lub wyższa.

Sprawdź wersję OpenSSL:

openssl version

Do pracy z HTTP/3 wymagany jest OpenSSL w wersji 3.0.0 lub wyższej, ponieważ wcześniejsze wersje nie obsługują QUIC.

Ponadto przed wprowadzeniem jakichkolwiek zmian należy upewnić się, że konfiguracja nginx jest wolna od błędów:

nginx -t

Jeśli wszystko jest w porządku (wiadomości typu warn można zignorować), zobaczysz komunikaty:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

2.  Konfiguracja HTTP/2

Otwórz plik konfiguracyjny witryny w edytorze tekstowym:

sudo nano /etc/nginx/sites-available/your-site.conf

Dodaj do linii listen 443 ssl dyrektywę http2 i dodaj linię http2 on do bloku server, aby uzyskać coś takiego jak poniżej:

server {

listen 443 ssl http2;

server_name example.com;

  

ssl_certificate /path/to/fullchain.pem;

ssl_certificate_key /path/to/privkey.pem;

  

http2 on;


rest of your config file

}

Zrestartuj serwer WWW, aby zastosować zmiany:

systemctl restart nginx

3. Konfiguracja HTTP/3

Podobnie jak w poprzednim kroku, otwórz plik konfiguracyjny swojej witryny i zmodyfikuj go w następujący sposób:

server {

listen 443 ssl http2;

listen 443 quic reuseport;

server_name example.com;

  

ssl_certificate /path/to/fullchain.pem;

ssl_certificate_key /path/to/privkey.pem;

  

http2 on;

  

ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;

add_header Alt-Svc 'h3=":443"; ma=86400';


rest of your config file

}

Gdzie:

• listen 443 quic reuseport; — aktywuje HTTP/3 (QUIC) na porcie 443 i poprawia wydajność przy dużej liczbie połączeń.
• ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3; — określa wersje protokołu TLS.  Dla większego bezpieczeństwa zaleca się stosowanie tylko TLSv1.2 i TLSv1.3.
• add_header Alt-Svc 'h3=":443"; ma=86400'; — informuje przeglądarki, że serwer obsługuje HTTP/3, i przechowuje tę informację przez 24 godziny.

Po wprowadzeniu zmian należy przeprowadzić dodatkową weryfikację, aby sprawdzić zgodność wersji Nginx z użytymi dyrektywami oraz wykryć ewentualne błędy składni, używając polecenia:

nginx -t

Jeśli wszystko jest w porządku (wiadomości typu warn można zignorować), zobaczysz komunikaty:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Zrestartuj serwer Nginx, aby zastosować zmiany:

systemctl restart nginx

Podsumowanie​

HTTP/2 i HTTP/3 to krok w przyszłość, który przyspiesza ładowanie stron, poprawia SEO i zwiększa komfort użytkowników. Pamiętaj jednak o kompatybilności, zasobożerności i ewentualnych trudnościach w konfiguracji.

Jeśli większość twoich użytkowników korzysta z nowoczesnych przeglądarek, rozpocznij od wdrożenia HTTP/2. HTTP/3 włącz, gdy będziesz gotów zaktualizować oprogramowanie serwera i upewnisz się, że twoja infrastruktura wspiera ten protokół.

Jeśli wolisz nie konfigurować tych protokołów ręcznie, możesz wybrać serwer z bezpłatnym panelem FASTPANEL, gdzie włączenie obsługi protokołów HTTP/2 i HTTP/3 dla Twojej witryny jest proste i wygodne.

Podczas wynajmu serwera wybór dysku ma kluczowe znaczenie dla wydajności projektów, niezawodności przechowywania danych i kosztów wynajmu. Warto zrozumieć różnice między HDD, SSD i NVMe, aby dokonać najlepszego wyboru do swoich potrzeb.

HDD: trwałość i stabilność​

Dyski twarde (HDD) to tradycyjne nośniki, które od lat stosuje się w centrach danych do przechowywania dużych ilości danych. Choć nie są tak szybkie jak SSD, zapewniają długą żywotność przy umiarkowanym obciążeniu.

HDD zazwyczaj mają żywotność wynoszącą od 20 000 do 25 000 godzin. W praktyce wiele HDD w centrach danych funkcjonuje przez około 3-5 lat, w zależności od stopnia intensywności użytkowania.

Dyski HDD charakteryzują się dużą wrażliwością na nagłe przerwy w zasilaniu, ponieważ zawierają ruchome części (np. głowice zapisu), co może prowadzić do uszkodzenia danych. W przypadku nieoczekiwanego wyłączenia ryzyko utraty danych jest większe niż w przypadku SSD.

Zalety HDD:​

• Trwałość: Możliwość pracy przez długi czas przy umiarkowanym obciążeniu.
• Koszt: Tańsze od SSD i NVMe w przeliczeniu na 1 TB danych.
• Duża pojemność: Świetne do przechowywania dużych ilości danych, gdy szybkość dostępu nie jest priorytetem.

SSD: szybciej, ale z ograniczonymi zasobami​

Dyski półprzewodnikowe (SSD) to szybkie i niezawodne nośniki danych, idealne dla serwerów, gdzie kluczowa jest wydajność. Jednak żywotność SSD, mierzona liczbą cykli zapisu, jest ograniczona. Dla SATA SSD wynosi ona 300–500 pełnych cykli zapisu, co przy umiarkowanym użytkowaniu pozwala teoretycznie na pracę przez około 5 lat. Przy intensywnym zapisie, typowym dla wielu witryn internetowych, żywotność SSD znacznie się skraca.

Dyski SSD są bardziej odporne na nagłe przerwy w zasilaniu, ponieważ nie posiadają ruchomych części. Jednak intensywny zapis może szybko wyczerpać ich zasoby, zwłaszcza w przypadku tańszych modeli.

Zalety SSD:​

• Wysoka prędkość: Idealne dla serwerów wymagających dużej wydajności.
• Odporność na nagłe przerwy w zasilaniu: Bardziej wytrzymałe na uszkodzenia sprzętowe przy niespodziewanym wyłączeniu.

NVMe: maksymalna szybkość, ale mniejsza trwałość​

NVMe (Non-Volatile Memory Express) to nowoczesna alternatywa dla SATA SSD, charakteryzująca się jeszcze większą wydajnością. Oferują znacznie wyższe prędkości odczytu i zapisu, co czyni je doskonałym wyborem dla serwerów przetwarzających ogromne ilości danych lub realizujących złożone operacje obliczeniowe.

Jednak żywotność NVMe jest krótsza w porównaniu z dyskami SATA SSD. Wysokie prędkości zapisu sprawiają, że nośniki NVMe zużywają się szybciej, szczególnie w warunkach stałego obciążenia.

Chociaż, podobnie jak SSD, NVMe są mniej podatne na uszkodzenia podczas nagłych przerw w zasilaniu, ich trwałość jest mniejsza niż w przypadku HDD ze względu na intensywną eksploatację.

Zalety NVMe:​

• Maksymalna prędkość: Idealne rozwiązanie dla serwerów obsługujących duże ilości danych.
• Wysoka wydajność: Odpowiedni do zadań wymagających dużego obciążenia.

Jaki typ dysku wybrać?​

• HDD: jeśli priorytetem są trwałość i niskie koszty, a intensywny zapis danych nie jest kluczowy, HDD będzie idealnym wyborem. To tańsze rozwiązanie, które zapewnia stabilną wydajność przez wiele lat.
• SSD: gdy zależy ci na szybkim zapisie danych i umiarkowanym obciążeniu, postaw na dysk SSD. Oferuje on dobrą prędkość przy niższym zużyciu niż NVMe.
• NVMe: dla serwerów o bardzo wysokich wymaganiach dotyczących prędkości idealnym wyborem będzie NVMe. Należy jednak pamiętać o krótszej żywotności i wyższej cenie.

Wybór dysku zależy od twoich potrzeb. Jeśli priorytetem są długowieczność i cena, zdecyduj się na HDD. Jeśli liczy się wysoka wydajność, najlepszym rozwiązaniem będzie SSD lub NVMe.

Ponadto oferujemy serwery dostosowane do Twoich potrzeb i budżetu, zapewniając idealne dopasowanie do każdego wymagania.

Certyfikat SSL — dziś niezbędne narzędzie dla każdej strony internetowej. Zapewnia bezpieczeństwo transmisji danych między serwerem a użytkownikiem. Istnieją różne typy certyfikatów, w tym darmowe (najczęściej oferowane przez dostawców takich jak Let's Encrypt i ZeroSSL) oraz płatne. Przyjrzyjmy się, czym się różnią i kiedy warto zdecydować się na certyfikat płatny.

Czym jest darmowy certyfikat SSL od Let's Encrypt lub ZeroSSL?​

Let's Encrypt — darmowy, zautomatyzowany serwis, który oferuje certyfikaty SSL dla stron internetowych. Jest idealny dla prostych projektów, takich jak blogi czy małe sklepy.

ZeroSSL — podobne narzędzie, które również oferuje darmowe certyfikaty, ale z dodatkowymi opcjami.

Zalety darmowych certyfikatów:​

1. Bezpłatność: To ich największy plus. Let's Encrypt i ZeroSSL dostarczają certyfikaty SSL całkowicie za darmo, co czyni je świetnym rozwiązaniem dla większości użytkowników, którzy nie potrzebują zaawansowanego poziomu zaufania.
2. Wsparcie dla współczesnych przeglądarek: Certyfikaty Let's Encrypt i ZeroSSL są akceptowane przez wszystkie nowoczesne przeglądarki. Dzięki temu użytkownicy nie zobaczą ostrzeżeń o braku zabezpieczeń przy odwiedzaniu strony.
3. Certyfikaty typu Wildcard: Let's Encrypt i ZeroSSL obsługują certyfikaty typu Wildcard, które pozwalają chronić wszystkie subdomeny pojedynczej domeny.

Wady:​

1. Ograniczone wsparcie: W razie problemów z certyfikatem użytkownik musi je rozwiązywać samodzielnie, ponieważ darmowe certyfikaty nie oferują wsparcia technicznego.
2. Krótki okres ważności: Certyfikaty Let's Encrypt i ZeroSSL są ważne tylko przez 90 dni. Wymagają ustawienia automatycznego odnawiania, co zazwyczaj wymaga znajomości terminala i podstawowych zasad działania serwerów.
3. Poziom zaufania i niezawodności: W przeciwieństwie do płatnych certyfikatów, Let's Encrypt i ZeroSSL nie oferują rozszerzonej walidacji (EV), co może ograniczać poziom zaufania strony u niektórych użytkowników i wyszukiwarek.

Różnice między ZeroSSL a Let's Encrypt:​

• ZeroSSL oferuje bardziej przyjazny interfejs użytkownika oraz płatne certyfikaty z dodatkowymi funkcjami (np. przedłużenie ważności do 1 roku).
• Let's Encrypt jest całkowicie darmowy, ale wymaga skonfigurowania automatyzacji odnawiania.

Czym są płatne certyfikaty SSL?​

Płatne certyfikaty SSL są oferowane przez wielu dostawców, takich jak DigiCert, GlobalSign, Comodo i inni. Zawierają one dodatkowe funkcje i udogodnienia, które sprawdzają się w przypadku bardziej wymagających projektów, przetwarzających wrażliwe dane osobowe.

Zalety płatnych certyfikatów:​

1. Długoterminowe rozwiązanie: Płatne certyfikaty są zazwyczaj ważne od 1 do 3 lat. Jest to wygodne rozwiązanie, jeśli nie chcesz często odnawiać swojego certyfikatu i wolisz rozwiązanie długoterminowe.
2. Rozszerzona walidacja (EV SSL): Certyfikaty płatne często oferują rozszerzoną weryfikację, która wymaga dokładniejszego sprawdzenia firmy kupującej certyfikat. Dzięki temu zwiększa się poziom zaufania użytkowników do strony.
3. Wsparcie techniczne i gwarancje: W przypadku płatnych certyfikatów użytkownik otrzymuje wsparcie techniczne oraz ubezpieczenie na wypadek problemów z certyfikatem. Jeśli dane klientów zostaną skradzione z powodu błędów w certyfikacie, można liczyć na rekompensatę. 
4. Lepsza optymalizacja SEO: Wiele wyszukiwarek promuje w wynikach wyszukiwania strony z certyfikatami SSL. Płatne certyfikaty mogą dodatkowo zwiększyć wiarygodność strony w oczach wyszukiwarek, co wspiera SEO.

Kiedy wybrać płatny certyfikat SSL?​

1. Jeśli twoja strona internetowa obsługuje poufne informacje lub płatności: Płatne certyfikaty z rozszerzoną walidacją (EV) są szczególnie przydatne w przypadku witryn obsługujących dane osobowe lub transakcje finansowe. Pomagają one budować zaufanie użytkowników.
2. W przypadku projektów obejmujących wiele stron: Płatne certyfikaty mogą chronić wiele witryn lub subdomen, co jest idealnym rozwiązaniem dla witryn korporacyjnych lub dużych witryn komercyjnych.
3. Jeśli potrzebujesz dodatkowego wsparcia: Dzięki płatnym certyfikatom można uzyskać pomoc od zespołu wsparcia, co jest ważne dla firm, które nie chcą samodzielnie zajmować się kwestiami technicznymi.
4. Aby usprawnić SEO: Płatne certyfikaty mogą poprawić pozycje w wyszukiwarkach.
5. Do długotrwałego użytku: Płatne certyfikaty działają dłużej i nie trzeba ich często odnawiać, co jest wygodne w przypadku dużych stron i projektów.

Podsumowanie​

Certyfikaty darmowe od Let's Encrypt lub ZeroSSL stanowią doskonałe rozwiązanie dla większości małych stron internetowych i blogów. Zapewniają podstawowy poziom bezpieczeństwa i są idealne dla witryn, które nie potrzebują zaawansowanej weryfikacji ani dodatkowych funkcji.

Jeśli jednak twoja strona wymaga bardziej zaawansowanych opcji, takich jak ochrona wielu domen czy rozszerzone wsparcie techniczne, warto rozważyć wybór płatnego certyfikatu. W takiej sytuacji zapraszamy do zapoznania się z naszymi dostępnymi ofertami.

Journald — system rejestrowania używany w nowoczesnych systemach operacyjnych opartych na Linuksie do rejestrowania zdarzeń systemowych. Jego zadaniem jest zbieranie informacji o działaniu usług, aplikacji oraz procesów systemowych, co ułatwia administratorom monitorowanie stanu systemu i diagnozowanie problemów.  

W odróżnieniu od tradycyjnych dzienników tekstowych, journald zapisuje dane w formacie binarnym. Pozwala to na przechowywanie logów w bardziej kompaktowej formie i efektywne zarządzanie nimi, ale jednocześnie takich dzienników nie można po prostu otworzyć w edytorze tekstu. Do ich przeglądania i analizy potrzebne są specjalne narzędzia.

W tym artykule omówimy, jak przeglądać dzienniki zapisane przez journald oraz jak je wyczyścić, aby odzyskać miejsce na dysku.

Jak przeglądać logi journal?​

Do odczytu logów użyj polecenia journalctl:

• Wszystkie logi:

sudo journalctl

• Logi od ostatniego uruchomienia:

sudo journalctl -b

• Logi konkretnej usługi:

sudo journalctl -u nginx

• Logi z określonego dnia:

sudo journalctl --since "2024-11-01" --until "2024-11-02"

• Wyświetlanie ostatnich n-wpisów (np. ostatnich 100):

sudo journalctl -n 100

• Filtrowanie według poziomów ważności (np. dla błędów):

sudo journalctl -p err

• Podgląd logów w odwrotnej kolejności, zaczynając od najnowszych (przydatne, gdy chcesz szybko zobaczyć najnowsze wpisy dziennika):

sudo journalctl -r

• Podgląd logów w czasie rzeczywistym (analogicznie do tail -f):

sudo journalctl -f

Te opcje można ze sobą łączyć. Na przykład, wyświetl wszystkie błędy usługi nginx dla 10 listopada 2024 r., pokazując tylko 10 ostatnich wpisów:

sudo journalctl -u nginx --since "2024-11-10" --until "2024-11-10 23:59:59" -n 10

Jak wyczyścić journal​

Jeśli logi zajmują zbyt dużo miejsca, można je wyczyścić za pomocą następujących poleceń:

• Czyszczenie starych logów (np. starszych niż 7 dni):

sudo journalctl --vacuum-time=7d

• Czyszczenie logów, które przekraczają określoną wielkość (np. 1 GB):

sudo journalctl --vacuum-size=1G

• Całkowite usunięcie wszystkich dzienników:

sudo journalctl --vacuum-files=0

Jak zmniejszyć rozmiar journal?​

Domyślnie Journald może zajmować dużo miejsca na dysku, jeśli logi nie są ograniczone. Aby ograniczyć maksymalny rozmiar dziennika, otwórz plik konfiguracyjny journald.conf:

sudo nano /etc/systemd/journald.conf

W tym pliku możesz skonfigurować następujące parametry:

• SystemMaxUse — maksymalny rozmiar dla wszystkich dzienników:

SystemMaxUse=1G

• RuntimeMaxUse — maksymalny rozmiar dla tymczasowych dzienników:

RuntimeMaxUse=500M

• MaxRetentionSec — maksymalny czas przechowywania dzienników:

MaxRetentionSec=1month

Ustaw odpowiednie wartości dla twojego systemu i potrzeb, a następnie zapisz plik za pomocą kombinacji klawiszy Ctrl + O i zamknij edytor klawiszami Ctrl + X. 

Aby zastosować zmiany, uruchom ponownie usługę journald:

sudo systemctl restart systemd-journald

Można także skonfigurować przechowywanie dzienników w pamięci RAM lub całkowicie je wyłączyć. Obie opcje jednak nie są zalecane w środowisku produkcyjnym, ponieważ dziennik zawiera kluczowe informacje diagnostyczne. Dbanie o jego aktualność i poprawność ma istotne znaczenie dla prawidłowego monitorowania oraz diagnozowania procesów na serwerze.

Jeśli nadal chcesz włączyć przechowywanie dziennika w pamięci RAM, ustaw następującą wartość w pliku /etc/systemd/journald.conf:

Storage=volatile

Aby całkowicie wyłączyć rejestrowanie, ustaw:

Storage=none

Boty wyszukiwarek (crawlers) to specjalne programy, które indeksują strony w Internecie. Są one potrzebne wyszukiwarkom do znajdowania, indeksowania i wyświetlania stron w wynikach wyszukiwania. Jednak nie wszystkie boty są pożyteczne!

Niektóre niechciane boty mogą:

• Zbierać dane bez twojej zgody.
• Nadmiernie obciążać serwer, powodując spowolnienia.
• Szukać luk w zabezpieczeniach twojej witryny.

Jeśli chcesz ochronić swoją witrynę przed takimi botami, czas skonfigurować Nginx! Pokażemy ci, jak szybko i skutecznie je zablokować, wykorzystując odpowiednie ustawienia.

Po co konfigurować Nginx, jeśli istnieje plik robots.txt?​

Plik robots.txt to narzędzie umożliwiające kontrolowanie zachowania botów wyszukiwarek. Pozwala określić, które strony nie powinny być przez nie indeksowane. Korzystanie z tego pliku jest bardzo proste, wystarczy w katalogu głównym witryny utworzyć plik typu:

User-agent: BadBot  

Disallow: /  

Jest jednak istotny problem: zawartość pliku robots.txt ma jedynie charakter zalecenia, a nie obowiązującej reguły. Rzetelne boty respektują ten plik, ale wiele z nich po prostu go ignoruje.

Konfiguracja z Nginx, w przeciwieństwie do robots.txt, pozwala fizycznie zablokować dostęp niechcianym botom, co gwarantuje rezultaty w 100% przypadków. 

Jak Nginx blokuje niechciane boty: użycie odpowiedzi 444​

W przeciwieństwie do pliku robots.txt, który jedynie sugeruje botom, jak się zachowywać, Nginx umożliwia fizyczne blokowanie ich dostępu. Jednym ze sposobów na osiągnięcie tego celu jest wykorzystanie specjalnej odpowiedzi serwera o kodzie 444.

Kod odpowiedzi 444 — to wewnętrzny mechanizm Nginx, który zamyka połączenie z klientem bez wysyłania żadnej odpowiedzi. Jest to skuteczna metoda ignorowania niechcianych zapytań i minimalizowania obciążenia serwera.

Konfiguracja blokady​

Krok 1: Jak rozpoznać niechciane boty?​

Niechciane boty można zidentyfikować na podstawie ich User-Agent, czyli parametru przesyłanego przez każdego klienta odwiedzającego stronę. Dla przykładu, niektóre z nich wyglądają tak:

    AhrefsBot     SemrushBot     MJ12bot

Aby znaleźć podejrzane User-Agent w logach dostępowych Nginx (jeśli twoja witryna korzysta z PHP-FPM), możesz użyć komendy:

sudo grep -i bot /var/log/nginx/access.log

W przypadku logów Apache (jeśli witryna używa modułu Apache lub FastCGI jako interpretera PHP), użyj:

• Dla Ubuntu/Debian:

sudo grep -i bot /var/log/apache2/access.log

• Dla CentOS/AlmaLinux/RockyLinux:

sudo grep -i bot /var/log/httpd/access.log

Jeśli korzystasz z panelu sterowania, takiego jak FASTPANEL, każda witryna będzie miała swój własny oddzielny plik logów. Można je analizować osobno lub wszystkie naraz za pomocą polecenia typu:

• Jeśli witryna korzysta z modułu Apache lub FastCGI jako obsługi PHP:

sudo cat /var/www/*/data/logs/*-backend.access.log |  grep -i bot | tail -500

• Jeśli twoja strona korzysta z PHP-FPM:

sudo cat /var/www/*/data/logs/*-frontend.access.log |  grep -i bot | tail -500

Powyższe polecenia wyświetlą 500 ostatnich zapytań do wszystkich twoich stron, gdzie parametr User-Agent zawiera słowo bot. Przykładowy wpis z logów może wyglądać tak:

IP - [03/Nov/2022:10:25:52 +0300] "GET link HTTP/1.0" 301 811 "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; [email protected])"

lub

IP - [24/Oct/2022:17:32:37 +0300] "GET link HTTP/1.0" 404 469 "-" "Mozilla/5.0 (compatible; BLEXBot/1.0; +http://webmeup-crawler.com/)"

User-Agent bota znajduje się pomiędzy fragmentami “compatible;” i “/numer.wersji“ w nawiasach. Tak więc w powyższych przykładach User-agent to „BLEXBot” i „DotBot”.

Przeanalizuj uzyskane informacje i zapisz User-agent najbardziej aktywnych botów w celu dalszych ustawień blokowania. 

Krok 2: Tworzenie pliku blokady botów​

1. Połącz się z serwerem przez SSH.
2. Przed przystąpieniem do pracy upewnij się, że w bieżącej konfiguracji Nginx nie ma żadnych błędów:

nginx -t

Jeśli wszystko jest w porządku, otrzymasz odpowiedź:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Jeśli w danych wyjściowych występują błędy, zapoznaj się z ich zawartością i popraw je w pliku, na który wskazują.

1. Utwórz osobny plik z listą botów do zablokowania:

sudo nano /etc/nginx/conf.d/block_bots.conf

Dodaj następujący kod do pliku:

    map $http_user_agent $block_bot {

        default 0;

        ~*AhrefsBot 1;

        ~*SemrushBot 1;

        ~*MJ12bot 1;

    }

  

    server {

        if ($block_bot) {

            return 444;

        }
    }

Tutaj tworzymy mapę, która określa, który bot powinien zostać zablokowany.

Analogicznie, wymień User-agent botów, które chcesz zablokować. Każdy bot powinien być wymieniony w nowym wierszu, a na końcu wiersza należy podać znak; jako separator.

Po zakończeniu tworzenia listy naciśnij skrót „Ctrl + O”, aby zapisać plik, a następnie „Ctrl + X”, aby wyjść z edytora nano. 

Krok 3: Zastosowanie zmian​

Po wprowadzeniu zmian w konfiguracji należy sprawdzić poprawność konfiguracji Nginx, aby upewnić się, że nie zawiera błędów składniowych:

sudo nginx -t

Jeśli wszystko jest w porządku, otrzymasz odpowiedź:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Jeśli w danych wyjściowych występują błędy, zapoznaj się z ich zawartością i popraw je w pliku, na który wskazują.

Następnie załaduj ponownie konfigurację Nginx, aby zastosować wprowadzone zmiany:

sudo systemctl reload nginx

Jeśli w przyszłości będziesz chciał dodać nowych botów do pliku block_bots.conf,musisz każdorazowo powtórzyć powyższy krok. 

Podsumowanie​

Teraz wiesz, jak łatwo zablokować niechciane boty na swoim serwerze za pomocą Nginx!  Monitoruj logi i w razie potrzeby dodawaj nowe boty do pliku block_bots.conf.

Pamiętaj, aby blokować tylko szkodliwe boty, aby nie zaszkodzić indeksowaniu swojej witryny w użytecznych wyszukiwarkach, takich jak Google czy Bing.

Zarządzanie logami jest kluczowym aspektem administracji serwerem. Logi, które nie są regularnie rotowane, mogą szybko zapełnić dysk, spowalniając działanie serwera i powodując nieprzewidywalne błędy. W tym artykule wyjaśnimy, jak skonfigurować i używać logrotate do automatycznego czyszczenia i rotacji logów na serwerze.

Czym jest logrotate i dlaczego warto go używać?​

Logrotate to narzędzie przeznaczone do automatycznego zarządzania logami. Pomaga w:

• Czyszczeniu starych logów — automatycznie usuwa lub archiwizuje przestarzałe logi.
• Oszczędzaniu miejsca na dysku — kompresuje i usuwa niepotrzebne logi.

Rotacja logów pozwala uniknąć sytuacji, w której logi gromadzą się, prowadząc do przepełnienia dysku, co może spowodować awarie systemu i utratę danych. Logrotate automatycznie archiwizuje stare logi i zwalnia miejsce na nowe dane.

Jak działa logrotate?​

Kiedy logrotate jest aktywowany, automatycznie wykonuje następujące kroki:

1. Rotacja logów — jest to proces, w którym stare logi są przemianowywane i zapisywane, a w ich miejsce tworzone są nowe pliki.
2. Kompresja — stare logi mogą zostać skompresowane do formatu .gz, aby zaoszczędzić miejsce.
3. Usuwanie — przestarzałe logi mogą zostać usunięte, jeśli nie są już potrzebne.

Przykład: plik dziennika o nazwie access.log może zostać przemianowany na access.log.1, następnie skompresowany do access.log.1.gz, a po upływie określonego czasu przechowywania, usunięty.

Jak skonfigurować logrotate?​

1. Instalacja logrotate​

Logrotate jest zwykle domyślnie instalowany na większości systemów Linux. Aby sprawdzić czy faktycznie już go masz, wpisz:

sudo logrotate --version

Jeśli logrotate nie jest zainstalowany, użyj menedżera pakietów.

• Dla Debiana/Ubuntu użyj:

sudo apt update && sudo apt install logrotate

• Dla CentOS/RockyLinux/AlmaLinux:

sudo yum install logrotate

2. Konfiguracja logrotate​

Konfiguracja logrotate jest zwykle przechowywana w /etc/logrotate.conf. Plik ten określa ogólne parametry dla wszystkich logów na serwerze. Aby skonfigurować rotację poszczególnych logów, można utworzyć oddzielne pliki konfiguracyjne dla różnych serwisów w folderze /etc/logrotate.d/.

Przykład standardowej konfiguracji dla Nginx:

/var/log/nginx/*.log {
	daily          # Logs are rotated daily
	missingok      # Do not display an error if the log is missing
	rotate 7       # Keep 7 archived files
	compress       # Compress old logs
	delaycompress  # Delay compression until the next rotation
	notifempty     # Do not rotate empty files
	create 0640 www-data adm  # Create new logs with specific permissions
}

3. Ważne parametry konfiguracyjne​

• daily/weekly/monthly — jak często log będzie rotowany (codziennie, co tydzień lub co miesiąc).
• rotate [N] — liczba archiwów logów, które mają być przechowywane.
• compress — kompresja archiwów logów (zwykle w formacie .gz).
• missingok — brak logów nie powoduje pokazania błędu.
• notifempty — nie rotuj pustych plików.
• create — stwórz nowe logi z uprawnieniami.

4. Uruchamianie logrotate​

Logrotate jest zwykle uruchamiany automatycznie za pomocą cron. Można jednak uruchomić go ręcznie, jeśli trzeba sprawdzić konfigurację lub wykonać rotację teraz:

sudo logrotate -f /etc/logrotate.conf

5. Sprawdzanie, czy logrotate działa​

Aby upewnić się, że logrotate działa poprawnie, sprawdź ostatnie wpisy w logu:

sudo journalctl -u logrotate -n 10