Migrácia PHP aplikácie zo zdieľaného hostingu na VPS

Kompletný technický sprievodca presunom PHP aplikácie zo zdieľaného hostingu Websupport na vlastný VPS s distribuciu Ubuntu Server. Tento návod pokrýva informácie od zistenia verzií (PHP, databáza, webserver) cez správne dimenzovanie a identické nasadenie prostredia až po prenos dát, HTTPS certifikát, ladenie výkonu a prevádzku nemanažovaného servera.

Cieľová platforma: Ubuntu Server 24.04 LTS
Stack: Nginx + Apache + PHP-FPM + MariaDB
Náročnosť: pokročilá
Predpokladaný čas: pol dňa – 1 deň

Zo zdieľaného hostingu na VPS: čo sa mení

Predtým, než sa pustíte do príkazov, je dôležité chápať povahu tejto zmeny. Neprechádzate len na výkonnejší „balík“ – prechádzate z plne manažovaného prostredia na nemanažované. To je najväčší rozdiel celej migrácie.

Na zdieľanom hostingu Websupport za vás poskytovateľ riešil takmer všetko „pod kapotou“: aktualizácie operačného systému a webového stacku, bezpečnostné záplaty, ochranu pred útokmi, monitoring dostupnosti, zálohovanie aj základné ladenie výkonu. Vy ste sa starali len o svoju aplikáciu.

Na nemanažovanom VPS dostávate dedikované zdroje a plnú kontrolu (root prístup, ľubovoľné verzie softvéru, vlastná konfigurácia), ale zároveň preberáte plnú zodpovednosť za celý server – od jadra systému po zálohy. Nie je to nič, čo by sa nedalo zvládnuť, no treba s tým počítať od začiatku, nie až keď niečo prestane fungovať.

Čo získavate

• Vyhradené vCPU, RAM a NVMe disk len pre vašu aplikáciu.
• Ľubovoľné verzie PHP, databázy a webservera; vlastné rozšírenia a moduly.
• Väčšie limity (pamäť skriptu, počet procesov, veľkosť uploadu, cache).
• Možnosť škálovať vertikálne (viac zdrojov) aj horizontálne (viac serverov).
• Nástroje ako Redis, Varnish, vlastný cron, systemd služby, CI/CD.

Čo preberáte na seba

• Aktualizácie OS a všetkých balíkov (vrátane bezpečnostných).
• Zálohovanie dát a overovanie obnovy.
• Monitoring dostupnosti a vyťaženia (CPU, RAM, disk).
• Bezpečnosť: firewall, ochrana pred útokmi, hardening.
• Ladenie výkonu a riešenie incidentov.

TIP: V celom návode nájdete odporúčania Managed → Unmanaged, ktoré upozorňujú na body, kde niečo, čo za vás doteraz riešil Websupport, teraz musíte zabezpečiť sami. Ak zistíte, že správa servera je nad vaše časové alebo personálne možnosti, Websupport ponúka doplnkovú službu Správa servera, v rámci ktorej aktualizácie, monitoring, zálohy aj ladenie preberú administrátori Websupportu.

1. Analýza súčasného prostredia a príprava

Cieľom migrácie je postaviť na VPS prostredie, ktoré je s pôvodným identické alebo lepšie. To sa dá len vtedy, keď presne viete, čo dnes beží. Najprv teda zistíte verzie a konfiguráciu, až potom staviate.

1.1 Zistenie verzie PHP

Verziu PHP na zdieľanom hostingu zistíte vo WebAdmine (sekcia hostingu → nastavenia PHP), alebo priamo z aplikácie krátkym skriptom. Vytvorte súbor info.php v koreni webu:

<?php
phpinfo();

Otvorte https://mojadomena.sk/info.php. Z výstupu si zapíšte: verziu PHP, zapnuté rozšírenia (Loaded Extensions), SAPI (FPM/CGI/Apache module), a hodnoty ako memory_limit, upload_max_filesize, post_max_size, max_execution_time, date.timezone. Tie budete na VPS replikovať.

TIP: info.php okamžite po odčítaní zmažte. Necháva uniknúť citlivé informácie o serveri, ktoré využívajú útočníci. Nikdy ho nenechávajte na produkčnom serveri.

Ak máte SSH/shell prístup, funguje aj:

# verzia CLI PHP a zoznam modulov
php -v
php -m
# hodnoty konfigurácie, ktoré chcete preniesť
php -i | grep -Ei 'memory_limit|upload_max|post_max|max_execution|timezone|opcache

TIP: PHP 8.1 je EOL a beží bez bezpečnostných záplat. Skok na 8.5 je väčší ako minor upgrade – medzi verziami pribudli deprecations a zmeny správania. Než prostredie ostro nasadíte, preverte kompatibilitu:

• Aktualizujte CMS/framework a všetky pluginy, témy a knižnice na verzie, ktoré deklarujú podporu cieľového PHP (napr. WordPress, Joomla, Laravel, Symfony majú maticu podporovaných verzií).
• Ak používate Composer, spustite composer why-not php 8.5 a composer update na testovacej kópii.
• Skontrolujte migračné príručky PHP (Migration Guide) pre 8.2, 8.3, 8.4, 8.5 – zmeny sú kumulatívne.
• Otestujte na staging kópii so zapnutým display_errors a log_errors ešte pred prepnutím produkcie.

1.2 Zistenie databázy a jej verzie

Zdieľaný hosting Websupport používa relačné databázy MariaDB/MySQL. Verziu a znakovú sadu zistíte cez phpMyAdmin (úvodná stránka zobrazuje verziu servera), alebo SQL dotazom:

SELECT VERSION();
SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';

-- veľkosť databázy (MB) podľa schém - dôležité pre sizing bufferov
SELECT table_schema AS db,
       ROUND(SUM(data_length + index_length)/1024/1024, 1) AS size_mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY size_mb DESC;

TIP: Staršie MariaDB/MySQL databázy sú vo väčšine prípadov plne kompatibilné s novšími verziami – dump zo staršej verzie novšia bez problémov naimportuje. Napriek tomu import otestujte na testovacej DB. Pri prechode z veľmi starých verzií (napr. MySQL 5.x s utf8/latin1) dbajte na správne kódovanie – cieľom by malo byť utf8mb4.

1.3 Webserver, .htaccess a cron

Zdieľaný hosting beží na Apache s podporou .htaccess. Zistite, či ho aplikácia využíva (SEO/pekné URL, presmerovania, hlavičky, ochrana priečinkov). To ovplyvní architektúru na VPS:

• Apache na VPS zachová .htaccess bez úprav (potrebné mod_rewrite a AllowOverride All).
• Nginx .htaccess nepozná – pravidlá treba prepísať do konfigurácie servera.
• V tomto návode použijeme kombináciu oboch: Nginx vpredu (rýchly, statika, TLS, rate‑limit) a Apache s mod_php-fpm vzadu (spracuje .htaccess).

Nezabudnite na plánované úlohy (cron). Na hostingu ich spravoval WebAdmin; na VPS si ich nastavíte sami cez crontab -e. Vypíšte si všetky existujúce cron úlohy a ich časovanie.

1.4 Ďalšie závislosti aplikácie

• Odosielanie e‑mailov: ako aplikácia posiela poštu? (funkcia mail(), lokálne SMTP, externá služba). Na VPS to budete musieť vyriešiť.
• Rozšírenia PHP: zo zoznamu z info.php si pripravte, čo doinštalovať (mysqli/pdo_mysql, gd/imagick, curl, mbstring, intl, zip, bcmath, xml…).
• Externé služby a API kľúče: platobné brány, CDN, SMTP, reCAPTCHA – overte IP whitelisty (mení sa vám IP servera!).
• Veľkosť dát: celkový objem súborov (du -sh) a databázy – vstup pre sizing disku.

TIP: Ešte pred čímkoľvek si vytvorte aktuálnu zálohu súborov aj databázy. Ideálne postavte staging kópiu (lokálne alebo na testovacom VPS) s presne tými verziami, aké plánujete nasadiť. Celú migráciu si tak nacvičíte „nanečisto“ a chyby (chýbajúce rozšírenie, zlé cesty, nekompatibilita) odhalíte bez výpadku produkcie.

2. Zmeranie súčasnej záťaže a sizing na X‑násobok

Najčastejšia otázka pri VPS znie: „akú konfiguráciu si mám vybrať?“ Odpoveď nie je odhad, ale meranie. V tejto sekcii najprv zistíte, koľko toho web zvláda teraz, a potom to prepočítate na cieľový X‑násobok s rozumnou rezervou.

TIP: Ako minimum pre produkčný VPS odporúčame 4 vCPU, 2 GB RAM a 25 GB SSD. Je to dobrý štart, keď nemáte istotu. Nižšie parametre sú vhodné len pre vývoj/test. Parametre (vCPU, RAM, disk) sa dajú kedykoľvek navýšiť, takže sa netreba báť začať menej a rásť podľa meraní.

2.1 Krok A – zmerajte, čo web zvláda teraz

Zbierajte tieto štyri skupiny údajov. Časť nájdete v štatistikách WebAdmin (návštevnosť, prenos dát, počet DB dotazov), zvyšok dopočítate z logov a databázy.

Návštevnosť a špičkové zaťaženie z access logu

Ak máte prístup k access logu (na hostingu cez WebAdmin/FTP, na akejkoľvek kópii lokálne), zistíte reálny počet požiadaviek za sekundu v špičke. To je kľúčové číslo – priemer klame, dimenzujete na špičku.

# Počet požiadaviek za jednotlivé sekundy - nájde najsilnejšiu špičku (req/s)
awk '{print $4}' access.log | cut -d: -f2-4 | sort | uniq -c | sort -rn | head

# Počet požiadaviek za minútu (prehľadnejšie pre menšie weby)
awk '{print $4}' access.log | cut -d: -f2-3 | sort | uniq -c | sort -rn | head

# Podiel dynamických (PHP) vs. statických požiadaviek - dôležité pre sizing PHP-FPM
grep -c '\.php' access.log
wc -l < access.log

Pre pohodlnejšiu analýzu odporúčame nástroj GoAccess (sudo apt install goaccess), ktorý z logu vygeneruje interaktívny report vrátane špičiek, top URL a stavových kódov.

Odhad súbežnosti (concurrency)

Počet naozaj súčasne bežiacich požiadaviek odhadnete z priepustnosti a doby odozvy podľa Little’s law:

# Little's law - priemerná súbežnosť súbežné požiadavky ≈ špička (req/s) × priemerná doba odozvy (s) # Príklad: 30 req/s v špičke, priemerná odozva PHP 0,2 s 30 × 0,2 = 6 súbežných PHP workerov v priemere (špičkovo viac → rátajte 2-3×)

Databázová záťaž a veľkosť

Z už poznáme veľkosť databázy. Doplňte informáciu o „ťažkých“ dotazoch – tie určujú, koľko RAM sa oplatí dať databáze (buffer pool by mal ideálne pokryť tzv. working set, teda aktívne používané dáta a indexy).

Aktuálne systémové metriky

Ak beží aplikácia už na nejakom serveri, kde máte prístup, sledujte htop, free -h, iostat. Na zdieľanom hostingu tento pohľad nemáte – tam sa oprite o návštevnosť a typ aplikácie (jednoduchý web vs. e‑shop s množstvom pluginov).

2.2 Krok B – nájdite strop záťažovým testom

Najspoľahlivejšie zistíte hranicu výkonu záťažovým testom. Spustite ho mimo špičky, ideálne proti staging kópii (nie proti živej produkcii). Postupne zvyšujte súbežnosť a sledujte, kedy prudko stúpne odozva alebo začnú chyby (HTTP 502/503).

# Apache Bench - 1000 požiadaviek, 50 súbežných
ab -n 1000 -c 50 https://staging.mojadomena.sk/


# wrk - 30 s test, 8 vlákien, 100 spojení (moderná alternatíva)
wrk -t8 -c100 -d30s https://staging.mojadomena.sk/


# k6 - realistický scenár s postupným rastom (ramp-up)
# k6 run zatazovy-test.js

Príklad k6 skriptu zatazovy-test.js, ktorý „vybudí“ systém rastúcou záťažou, aby ste našli bod zlomu:

import http from 'k6/http';
import { check, sleep } from 'k6';


export const options = {
  stages: [
    { duration: '1m', target: 20 },   // rozbeh na 20 VUs
    { duration: '2m', target: 100 },  // rast na 100 VUs
    { duration: '2m', target: 200 },  // hľadáme strop
    { duration: '1m', target: 0 },    // dobeh
  ],
  thresholds: {
    http_req_duration: ['p(95)<800'], // 95 % odpovedí pod 800 ms
    http_req_failed: ['rate<0.01'],   // menej ako 1 % chýb
  },
};


export default function () {
  const res = http.get('https://staging.mojadomena.sk/');
  check(res, { 'status 200': (r) => r.status === 200 });
  sleep(1);
}

TIP: Ak testujete stále rovnakú URL, môžete merať iba cache (Nginx/CDN/stránkový cache plugin), ktorá PHP takmer nezaťaží. Server potom v reálnej prevádzke na nekešované požiadavky spadne. Do testu preto zahrňte aj náhodné/nekešované URL (napr. s parametrom ?nocache=${__ITER}), prihlásené relácie a POST požiadavky, aby ste videli skutočné zaťaženie PHP a databázy.

Počas testu sledujte na cieľovom serveri metriky – v druhom termináli:

htop                 # CPU jadrá, RAM, swap, load average
free -h              # využitie a swapovanie pamäte
iostat -x 2          # %util diskov (I/O bottleneck)
watch -n1 'ss -s'    # počet spojení

Výsledkom je strop: napr. „do ~80 súbežných je odozva do 300 ms, nad ~150 prudko rastie a objavujú sa 503“. Zapíšte si, ktorý zdroj sa vyčerpal ako prvý (CPU na 100 %, RAM/swap, pm.max_children, disk %util). To určí, ktorý parameter navyšovať.

2.3 Krok C – prepočet na X‑násobok s rezervou

Teraz preveďte namerané hodnoty na cieľovú konfiguráciu. Vždy počítajte s rezervou 20-30 % – server nemá dlhodobo bežať na 100 % CPU ani plnej RAM.

RAM – zvyčajne limitujúci zdroj

RAM sa delí medzi PHP‑FPM, databázu a operačný systém. Postup:

# 1) Pamäť pre PHP-FPM RAM_PHP = cieľová súbežnosť workerov × priemerná pamäť 1 procesu (priemer procesu zmeriate na VPS príkazom nižšie; typicky 30-120 MB) # 2) Pamäť pre databázu (InnoDB buffer pool ≈ working set, max ~veľkosť DB) RAM_DB = innodb_buffer_pool_size + ~20-30 % réžia DB servera # 3) Operačný systém a démoni RAM_OS = 1-2 GB # 4) Spolu + rezerva RAM_VPS = (RAM_PHP + RAM_DB + RAM_OS) × 1,25 # 25 % rezerva

Priemernú pamäť jedného PHP procesu zmeriate priamo na bežiacom serveri:

# Priemerná RSS pamäť PHP-FPM procesov (číslo verzie prispôsobte)
ps --no-headers -o "rss,cmd" -C php-fpm8.6 \
  | awk '{ sum+=$1 } END { printf ("%d MB\n", sum/NR/1024) }'

vCPU

• Ak bol pri strope CPU‑bound (jadrá na 100 %), škáluje počet jadier približne lineárne s cieľovým X‑násobkom (+ rezerva).
• Väčšina PHP webov je však I/O‑bound (procesy čakajú na DB, disk, sieť) – potom rozhoduje počet workerov a RAM, nie čistý CPU. Napriek tomu dajte databáze aj PHP dosť jadier na paralelizmus.
• Praktický štart: 4 vCPU (odporúčané minimum WS). Pri e‑shopoch a vyššej súbežnosti 6-8 vCPU. Priemerné VPS na infraštruktúre Websupportu má okolo 4 vCPU / 8 GB RAM.

Disk a IOPS

• Veľkosť = súbory webu + databáza + logy + zálohy + rezerva. Držte aspoň 20-30 % voľného miesta.
• Websupport VPS bežia na rýchlom SSD/NVMe úložisku, takže IOPS zvyčajne nie sú úzkym miestom bežných PHP webov.
• Disk sa dá dodatočne navýšiť (rozšírenie volume). Zaplnený disk je najčastejší dôvod, prečo VPS spadne – preto ho monitorujte.

TIP: Predtým, než kúpite 2× väčší VPS, over­te, či problém nevyrieši ladenie a caching. Zapnutý OPcache, správne pm.max_children, väčší InnoDB buffer pool, jeden chýbajúci index alebo stránkový cache dokážu zdvihnúť priepustnosť násobne bez zmeny hardvéru. Sizing a optimalizácia idú ruka v ruke – po vyladení spravte záťažový test znova a uvidíte reálnu kapacitu.

2.4 Kompletný príklad výpočtu

Web má v špičke ~30 req/s, priemernú odozvu PHP 0,2 s, databázu 2 GB a chceme zvládnuť 5× vyššiu návštevnosť.

Krok	Výpočet	Výsledok
Súbežnosť teraz	30 req/s × 0,2 s	~6 workerov (priemer)
Cieľ 5×	6 × 5, +rezerva na špičku	~30-40 workerov
RAM pre PHP	35 workerov × ~50 MB	~1,8 GB
RAM pre DB	buffer pool ~3 GB (DB 2 GB + rast) + réžia	~3,5 GB
RAM pre OS	—	~1,5 GB
RAM spolu + 25 %	(1,8 + 3,5 + 1,5) × 1,25	~8,5 GB → volíme 8-12 GB
vCPU	web prevažne I/O‑bound, 5× súbežnosť + DB	4-6 vCPU
Disk	súbory + DB + logy + zálohy + rezerva	50-80 GB SSD

Výsledok: napr. VPS s 6 vCPU / 12 GB RAM / 80 GB SSD s pohodlnou rezervou na 5× rast. Keby ste chceli 10× a viac, oplatí sa už uvažovať o oddelení databázy na samostatný VPS a horizontálnom škálovaní.

2.5 Kedy rozdeliť záťaž (horizontálne škálovanie)

Pri produkčných nasadeniach odporúčame umiestniť každú súčasť aplikácie na samostatný server – typicky oddeliť aplikáciu a databázu. Získate lepšiu izoláciu a každý komponent škálujete zvlášť. Pri vyššom X‑násobku zvážte:

• Databázu na vlastný VPS – uvoľní RAM pre PHP a naopak; DB dostane celý buffer pool.
• Viac web serverov za Load Balancer vo Virtuálnom dátovom centre (VDC) – horizontálne pridávanie kapacity.
• Redis/Memcached pre session a object cache, aby web servery zdieľali stav.

Pre jednoduchosť ale v tomto návode staviame jeden VPS so všetkými službami; rozdelenie je logickým ďalším krokom, keď narazíte na strop jedného stroja.

3. Objednanie a základná príprava VPS

Pri objednávke VPS zvolíte operačný systém. Návod predpokladá čistý Ubuntu Server 24.04 LTS (najnovšia LTS), aby sme prešli všetky kroky. Aplikácie inštalujeme priamo do systému v konkrétnych verziách – nie do kontajnerov.

TIP: Websupport pri objednávke ponúka aj 1‑klik obrazy s predinštalovaným LAMP (Apache) alebo LEMP (Nginx) stackom. Ušetria čas, no my volíme minimal Ubuntu, aby ste mali plnú kontrolu nad verziami a konfiguráciou. Ak si zvolíte predpripravený obraz, časti inštalácie preskočíte.

3.1 Prvé prihlásenie a bezpečné základy

Po zriadení VPS dostanete IP adresu (resp. hostname v tvare nazov.vps.wbsprt.com) a prihlasovacie údaje. Pripojte sa cez SSH:

ssh root@IP_ADRESA           # prvé prihlásenie (alebo neprivilegovaný účet)
passwd                       # zmena predvoleného hesla na silné

Odporúčame prejsť na prihlasovanie cez SSH kľúč a vytvoriť neprivilegovaného používateľa so sudo:

# na svojom počítači vygenerujte kľúč (ak ešte nemáte)
ssh-keygen -t ed25519 -C "vas@email.sk"


# na serveri vytvorte používateľa a pridajte ho do sudo
adduser web
usermod -aG sudo web


# skopírujte verejný kľúč používateľovi (z vášho počítača)
ssh-copy-id web@IP_ADRESA

TIP: Zabezpečenie prístupu bolo na hostingu vecou Websupportu. Na VPS je na vás. Po overení kľúča odporúčame v /etc/ssh/sshd_config zakázať prihlásenie heslom (PasswordAuthentication no) a priame prihlásenie roota (PermitRootLogin prohibit-password), potom sudo systemctl restart ssh.

3.2 Aktualizácia systému, čas a swap

# načítanie metadát a aktualizácia balíkov
sudo apt update
apt list --upgradable
sudo apt upgrade -y
# ak sa aktualizovalo jadro (kernel), reštartujte
sudo reboot

# správna časová zóna (dôležité pre logy a cron)
sudo timedatectl set-timezone Europe/Bratislava
date

Synchronizáciu času zabezpečuje systemd-timesyncd (NTP), na Ubuntu je aktívna. Ak má VPS menej RAM, vytvorte si poistný swap (bráni pádu procesov pri prudkej špičke – nesmie však slúžiť ako náhrada RAM):

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
# databázový server nech radšej swapuje čo najmenej
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf

3.3 Fireewall (UFW) a ochrana pred brute‑force

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status verbose

Port 3306 (MariaDB) neotvárajte – databáza má počúvať len na localhost. Nainštalujte Fail2Ban, ktorý po opakovaných neúspešných prihláseniach automaticky blokuje IP útočníka:

sudo apt install fail2ban -y
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

TIP: Sieť Websupport VPS je na úrovni dátacentra chránená proti základným (volumetrickým) DDoS útokom. To vás však nezbavuje potreby chrániť aplikačnú vrstvu (firewall, rate‑limit, Fail2Ban).

3.4 Automatické bezpečnostné aktualizácie

Keďže OS udržiavate vy, zapnite automatické inštalovanie bezpečnostných záplat:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure --priority=low unattended-upgrades

TIP: Prvé kroky s Linux VPS (aktualizácie, čas, SSH, základ)

4. Inštalácia stacku v presných verziách

Postavíme presne definované prostredie: MariaDB ako databáza, PHP‑FPM 8.5 v konkrétnej verzii z overeného PPA, Apache ako backend (kvôli .htaccess) a Nginx vpredu ako reverzné proxy. Všetko natívne v systéme, nie v kontajneroch.

Cieľová architektúra

# Tok požiadavky Internet ──▶ Nginx :80/:443 ──▶ Apache :8080 ──▶ PHP-FPM (socket) ──▶ MariaDB (localhost) (TLS, statika, (.htaccess, (spracovanie (dáta) rate-limit, cache) mod_rewrite) PHP skriptov)

Prečo takto: Nginx vpredu je extrémne rýchly na statiku, TLS a obmedzovanie záťaže; Apache vzadu bez úprav zvládne vaše pôvodné .htaccess pravidlá; PHP‑FPM je moderný a efektívny spôsob behu PHP (výkonnejší a flexibilnejší než starý mod_php). Ak .htaccess nepoužívate, Apache môžete vynechať a Nginx pripojiť priamo na PHP‑FPM (LEMP) – vtedy preskočte časti s Apache.

4.1 Databázový server – MariaDB

sudo apt install mariadb-server -y
mariadb --version               # overte verziu (napr. 10.11 LTS / 11.x)
sudo systemctl enable --now mariadb
sudo mysql_secure_installation  # nastaví root heslo, odstráni test DB a anon. účty

MariaDB štandardne počúva len na 127.0.0.1:3306 – presne to chceme. Vytvorte databázu a samostatného používateľa pre aplikáciu (znaková sada utf8mb4):

sudo mariadb

CREATE DATABASE nazov_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'uzivatel_db'@'localhost' IDENTIFIED BY 'SilneHeslo123!';
GRANT ALL PRIVILEGES ON nazov_db.* TO 'uzivatel_db'@'localhost';
FLUSH PRIVILEGES;
EXIT;

TIP: Použite rovnaké názvy DB a používateľa ako na hostingu – ušetríte úpravy v konfigurácii aplikácie. Heslo si bezpečne uložte (správca hesiel), budete ho potrebovať.

4.2 PHP‑FPM v konkrétnej verzii (PPA ondrej/php)

Ubuntu v základných repozitároch ponúka len jednu verziu PHP. Pre konkrétnu verziu a možnosť súbežne držať viac verzií použite overený repozitár ondrej/php:

sudo apt install software-properties-common -y
sudo add-apt-repository ppa:ondrej/php -y
sudo apt update

Nainštalujte PHP‑FPM a rozšírenia, ktoré ste si vypísali z info.php na začiatku tohoto návodu.

sudo apt install -y \
  php8.5-fpm php8.5-cli php8.5-mysql php8.5-xml php8.5-mbstring \
  php8.5-curl php8.5-gd php8.5-intl php8.5-zip php8.5-bcmath php8.5-opcache

php8.5 -v
sudo systemctl enable --now php8.5-fpm

Zosúlaďte kľúčové hodnoty php.ini s pôvodným hostingom (súbor /etc/php/8.5/fpm/php.ini):

memory_limit = 256M
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 60
date.timezone = Europe/Bratislava

; OPcache - zásadné zrýchlenie behu PHP (kešuje skompilovaný bytecode)
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 1

Reštartnite php-fpm:

sudo systemctl restart php8.5-fpm

TIP: OPcache eliminuje opakovanú kompiláciu PHP skriptov – v testoch znižuje čas spracovania aj o desiatky percent. Na produkcii ho majte vždy zapnutý a s dostatočnou pamäťou. JIT naopak vo webových aplikáciách zvyčajne neprináša zisk a pridáva pamäťovú réžiu – ponechajte ho vypnutý, ak nemáte konkrétny CPU‑náročný dôvod.

4.3 Apache ako backend + PHP‑FPM,

Apache nainštalujeme tak, aby počúval na internom porte 8080 (Nginx bude vpredu na 80/443) a PHP posielal do PHP‑FPM cez FastCGI:

sudo apt install apache2 -y
# moduly pre PHP-FPM cez FastCGI a pre .htaccess
sudo a2enmod proxy_fcgi setenvif rewrite headers
sudo a2enconf php8.5-fpm
# Apache nech počúva len lokálne na 8080 (Nginx je vpredu)
sudo sed -i 's/^Listen 80$/Listen 127.0.0.1:8080/' /etc/apache2/ports.conf

Vytvorte VirtualHost pre doménu (koreň webu /var/www/mojadomena.sk) v súbore /etc/apache2/sites-available/mojadomena.sk.conf

<VirtualHost 127.0.0.1:8080>
    ServerName mojadomena.sk
    ServerAlias www.mojadomena.sk
    DocumentRoot /var/www/mojadomena.sk

    <Directory /var/www/mojadomena.sk>
        AllowOverride All          # aby fungovali vaše .htaccess pravidlá
        Require all granted
    </Directory>

    # zachovaj reálnu IP návštevníka predanú Nginxom
    RemoteIPHeader X-Forwarded-For

    ErrorLog  ${APACHE_LOG_DIR}/mojadomena_error.log
    CustomLog ${APACHE_LOG_DIR}/mojadomena_access.log combined
</VirtualHost>

Následne spustite:

sudo a2enmod remoteip
sudo a2ensite mojadomena.sk.conf
sudo a2dissite 000-default.conf
sudo mkdir -p /var/www/mojadomena.sk
sudo apache2ctl configtest && sudo systemctl reload apache2

4.4 Nginx ako reverzné proxy vpredu

Nginx prevezme porty 80/443, obslúži statiku a TLS a dynamiku pošle na Apache (8080). Nginx aj Apache tak bežia na jednom serveri bez potreby druhej IP.

sudo apt install nginx -y

Upravte /etc/nginx/sites-available/mojadomena.sk

server {
    listen 80;
    listen [::]:80;
    server_name mojadomena.sk www.mojadomena.sk;
    root /var/www/mojadomena.sk;

    # obmedzenie tempa požiadaviek (základná ochrana, viď zóna nižšie)
    limit_req zone=perip burst=20 nodelay;

    # statiku obslúži priamo Nginx (rýchlejšie, odľahčí Apache/PHP)
    location ~* \.(?:css|js|jpg|jpeg|png|gif|webp|svg|ico|woff2?|ttf|mp4)$ {
        expires 30d;
        access_log off;
        add_header Cache-Control "public";
        try_files $uri @backend;
    }

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host              $host;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    location @backend {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Definujte rate‑limit zónu v hlavnej konfigurácii (v bloku http { }):

Súbor /etc/nginx/conf.d/ratelimit.conf

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

Následne:

sudo ln -s /etc/nginx/sites-available/mojadomena.sk /etc/nginx/sites-enabled/
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx

Otestujte beh PHP – dočasne vytvorte info skript, načítajte v prehliadači a hneď zmažte:

echo '<?php phpinfo();' | sudo tee /var/www/mojadomena.sk/info.php
# otvorte http://IP_ADRESA/info.php - SAPI musí byť FPM/FastCGI
sudo rm /var/www/mojadomena.sk/info.php   # ihneď zmazať!

TIP: Nginx ako reverzné proxy pred Apache na jednom Ubuntu serveri

5. Prístup k súborom (FTP/SFTP) a správa databázy cez GUI

Na hostingu ste mali FTP účty a phpMyAdmin „hotové“. Na VPS si prístup pripravíte sami – bezpečne.

5.1 SFTP namiesto FTP

Každý VPS s bežiacim SSH automaticky podporuje SFTP – šifrovaný prenos súborov cez rovnaké prihlasovacie údaje. Nepotrebujete inštalovať žiadny FTP server. Vo FileZilla zadajte:

Pole	Hodnota
Hostiteľ	sftp://IP_ADRESA
Port	22
Používateľ / kľúč	váš SSH účet (web) a SSH kľúč
Cieľový priečinok	/var/www/mojadomena.sk

TIP: Ak potrebujete klasické FTP účty (napr. pre klienta s obmedzením do jedného priečinka), dá sa doinštalovať vsftpd alebo ProFTPD. Bezpečnejší a bez ďalšej konfigurácie je však SFTP – uprednostnite ho, kým nemáte konkrétny dôvod pre FTP.

5.2 phpMyAdmin alebo Adminer

Na správu databázy cez webové rozhranie máte dve praktické možnosti:

phpMyAdmin

Plnohodnotné rozhranie. Inštalácia: sudo apt install phpmyadmin. Je to častý terč útokov – vždy zabezpečte.

Adminer

Jediný PHP súbor, ľahké nasadenie a menší útočný povrch. Stačí ho stiahnuť do priečinka mimo hlavného webu a otvoriť v prehliadači.

# Adminer do samostatného, chráneného priečinka
sudo mkdir -p /var/www/dbadmin
sudo curl -L https://www.adminer.org/latest.php -o /var/www/dbadmin/index.php

TIP: phpMyAdmin/Adminer nikdy nenechávajte verejne prístupné bez ochrany. Minimálne: (1) silné DB heslá, (2) HTTP autentifikácia pred rozhraním (htpasswd + Nginx auth_basic), (3) obmedzenie na vaše IP (allow/deny), ideálne (4) prístup len cez SSH tunel na localhost. Vzdialené otvorenie portu 3306 na internet neodporúčame.

6. Prenos súborov webu a databázy

Presun obsahu má dve časti – súbory a databázu. Kľúčové je zachovať štruktúru, kódovanie a práva.

6.1 Prenos súborov

Zo starého hostingu stiahnite všetky súbory vrátane skrytých (napr. .htaccess, .env). Najefektívnejšie je rsync (ak máte SSH na oboch stranách), inak FTP stiahnutie a SFTP nahratie:

# Priamy prenos medzi servermi (spustené na VPS), ak je SSH Shell na starom hostingu:
rsync -avz --progress user@stary-hosting:/cesta/k/webu/ /var/www/mojadomena.sk/

# Alternatíva: archív na starom serveri, prenos, rozbalenie na VPS
# (na starom serveri) tar czf web.tar.gz -C /cesta/k/webu .
# (na VPS)            scp user@stary-hosting:~/web.tar.gz .
# (na VPS)            tar xzf web.tar.gz -C /var/www/mojadomena.sk

6.2 Export databázy zo starého hostingu

Vo WebAdmine použite Export databázy (vygeneruje .sql), alebo mysqldump. Pre InnoDB použite --single-transaction, aby ste dostali konzistentný dump bez zamykania tabuliek:

mysqldump -h mariadbXX.r.wbsprt.com -u uzivatel -p \
  --single-transaction --quick --default-character-set=utf8mb4 \
  --routines --triggers --events \
  nazov_db > zaloha.sql

# rýchlejšie pri veľkých DB - komprimovaný dump
mysqldump -h HOST -u USER -p --single-transaction nazov_db | gzip > zaloha.sql.gz

Údaje o DB serveri hostingu (hostname, používateľ) nájdete vo WebAdmine v sekcii databáz.

6.3 Import databázy na VPS

Preneste .sql na VPS (SFTP) a naimportujte do databázy vyššie vytvorenej:

# komprimovaný dump rozbaľte za behu
zcat zaloha.sql.gz | mysql -u uzivatel_db -p nazov_db
# alebo nekomprimovaný
mysql -u uzivatel_db -p nazov_db < zaloha.sql

Možné problémy pri importe

• „MySQL server has gone away“ / veľký dump: zvýšte max_allowed_packet na oboch stranách. V /etc/mysql/mariadb.conf.d/50-server.cnf nastavte napr. max_allowed_packet = 256M a reštartujte MariaDB.
• Zlé kódovanie (otázniky, „Å¾Ăˇ“): dump aj import robte s –default-character-set=utf8mb4. Ak pôvodná DB bola v latin1 uložená ako „double‑encoded“ UTF‑8, riešte cielenou konverziou, nie len zmenou charsetu.
• Nekompatibilné definície (staré verzie): pri prechode z veľmi starých MySQL použite pri exporte –compatible alebo postupný upgrade.

6.4 Práva a vlastníctvo súborov

Webserver (Apache/PHP‑FPM) beží ako používateľ www-data. Nastavte vlastníctvo tak, aby mal prístup a zápisové priečinky boli zapisovateľné – nikdy nepoužívajte chmod 777:

sudo chown -R www-data:www-data /var/www/mojadomena.sk
# adresáre 755, súbory 644
sudo find /var/www/mojadomena.sk -type d -exec chmod 755 {} \;
sudo find /var/www/mojadomena.sk -type f -exec chmod 644 {} \;
# aby ste vedeli súbory spravovať aj vy, pridajte sa do skupiny www-data
sudo usermod -aG www-data web

7. Konfigurácia aplikácie na novom serveri

Po prenose dát treba aplikáciu „napojiť“ na nové prostredie – hlavne na lokálnu databázu.

7.1 Databázové prístupy

Na hostingu bola databáza na vzdialenom serveri (napr. mariadbXX.r.wbsprt.com). Teraz beží lokálne, takže host bude localhost (resp. 127.0.0.1). Upravte konfiguračný súbor aplikácie:

Systém	Súbor	Kľúč
WordPress	wp-config.php	DB_HOST, DB_NAME, DB_USER, DB_PASSWORD
Joomla	configuration.php	$host, $db, $user, $password
Laravel/Symfony	.env	DB_HOST, DB_DATABASE, DB_USERNAME, DB_PASSWORD
PrestaShop	app/config/parameters.php	database_host, database_name…

wp-config.php (príklad):
define( 'DB_HOST', 'localhost' );      // predtým mariadbXX.r.wbsprt.com
define( 'DB_NAME', 'nazov_db' );
define( 'DB_USER', 'uzivatel_db' );
define( 'DB_PASSWORD', 'SilneHeslo123!' );

7.2 URL a cesty

• Doména sa nemení → aplikácia používa rovnaké URL, netreba zásah (testovanie cez hosts, viď sekcia 9).
• Absolútne cesty v konfigu (napr. /data/.../web/uploads) prepíšte na nové (/var/www/mojadomena.sk/uploads). Väčšina moderných aplikácií používa relatívne cesty / __DIR__, takže zásah často netreba.
• WordPress: URL sú v databáze – nemeňte ich ručne, na test použite hosts. Prípadnú zmenu domény riešte cez WP‑CLI search-replace (serializované dáta).

7.3 Odosielanie e‑mailov

TIP: Na hostingu fungovala funkcia mail() a doručiteľnosť riešil Websupport. Na čistom VPS žiadny mail server nie je. Najspoľahlivejšie je posielať cez externú SMTP službu (napr. transakčný SMTP účet) priamo z aplikácie. Pre doručiteľnosť z vlastnej domény nastavte DNS záznamy SPF, DKIM a DMARC, inak správy skončia v spame. Lokálny Postfix v „send‑only“ režime je možný, ale bez korektných DNS záznamov nespoľahlivý.

7.4 Debug a chybové logy

Počas oživovania dočasne zapnite chyby a sledujte logy – najčastejšie problémy sú chýbajúce PHP rozšírenie, zlá cesta k uploadu, zle vyplnené DB údaje či práva na zápis:

sudo tail -f /var/log/apache2/mojadomena_error.log
sudo tail -f /var/log/nginx/error.log
sudo tail -f /var/log/php8.5-fpm.log

V php.ini (len dočasne, na produkcii vypnúť): display_errors = On, error_reporting = E_ALL. Cron úlohy z hostingu nastavte cez crontab -e.

8. Nasadenie HTTPS certifikátu (Let’s Encrypt)

Na hostingu ste mali Let’s Encrypt certifikát automaticky. Na VPS si ho nastavíte pomocou Certbota. Keďže vpredu beží Nginx, použijeme Nginx plugin.

TIP: Certifikát aj jeho automatickú obnovu za vás doteraz riešil hosting. Na VPS ho vydáte, nasadíte a obnovu overíte vy (Certbot to však zautomatizuje).

8.1 Podmienka: doména musí smerovať na VPS

Let’s Encrypt overuje vlastníctvo domény cez HTTP výzvu na porte 80. Doména preto musí smerovať na VPS – buď už prepnutým DNS A záznamom, alebo dočasne cez hosts. Nginx musí obsluhovať doménu na porte 80.

8.2 Inštalácia a vydanie certifikátu

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d mojadomena.sk -d www.mojadomena.sk

Certbot automaticky: overí doménu (cez /.well-known/acme-challenge/), vystaví certifikát, upraví konfiguráciu Nginx a opýta sa na presmerovanie HTTP → HTTPS – zvoľte áno (možnosť „Redirect“), nech sú návštevníci vždy na HTTPS. Certifikáty sa uložia do /etc/letsencrypt/live/mojadomena.sk/.

Apache je za Nginxom

TLS ukončuje Nginx; Apache vzadu ostáva na HTTP (127.0.0.1:8080). Aby aplikácia vedela, že požiadavka prišla cez HTTPS, Nginx posiela hlavičku X-Forwarded-Proto (nastavené v 4.4). V aplikácii prípadne nastavte, aby tejto hlavičke dôverovala (trusted proxy).

8.3 Automatická obnova

Certifikáty platia 90 dní; Certbot pridá časovú úlohu, ktorá ich obnoví automaticky. Overte „nanečisto“:

sudo certbot renew --dry-run
systemctl list-timers | grep certbot

8.4 Sprísnenie TLS a HSTS (voliteľné, odporúčané)

Do server bloku (HTTPS) v Nginx pridajte hlavičku HSTS a moderné TLS nastavenia:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

Kvalitu nasadenia si overte na SSL Labs (ssllabs.com/ssltest) alebo otvorením https://mojadomena.sk/ a kontrolou zámku v prehliadači.

9. Finálne testovanie a prepnutie DNS

Web na VPS otestujte ešte pred zmenou DNS. Chyby sa ladia oveľa pokojnejšie, keď ich nevidia návštevníci.

9.1 Testovanie cez súbor hosts

Na svojom počítači dočasne nasmerujte doménu na IP VPS pridaním riadka do hosts (C:\Windows\System32\drivers\etc\hosts na Windows, /etc/hosts na Linux/macOS):

Súbor hosts:

123.45.67.89   mojadomena.sk www.mojadomena.sk

9.2 Kontrolný zoznam pred prepnutím

• Logy (Nginx, Apache, PHP‑FPM, aplikácia) nehlásia chyby.
• Funguje upload súborov, odoslanie formulára/e‑mailu, prihlásenie, kľúčové funkcie.
• HTTPS beží bez varovaní, presmerovanie z HTTP funguje.
• Stránky sa generujú svižne.
• Zálohovanie a monitoring sú pripravené.

TIP: 1-2 dni pred migráciou znížte TTL DNS A záznamu (napr. na 300 s). Prepnutie sa potom prejaví rýchlo a máte možnosť sa v prípade problému rýchlo vrátiť. Po úspešnom prepnutí TTL zase zdvihnite.

9.3 Finálna synchronizácia dát

Ak od exportu DB pribudli na starom webe nové dáta (príspevky, objednávky), spravte tesne pred prepnutím nový export a import, aby ste neprišli o čerstvý obsah. Na starom webe ideálne po tomto momente „zmrazte“ zápisy (údržbový režim).

9.4 Prepnutie DNS

V DNS správe domény (u Websupportu vo WebAdmin → Domény → DNS záznamy) upravte A záznam (prípadne AAAA pre IPv6) na IP adresu VPS a uložte. Propagácia zvyčajne trvá minúty až (výnimočne) hodiny.

Počas propagácie

• Časť návštevníkov ešte môže trafiť starý server – nechajte starý hosting 1-2 dni aktívny ako poistku.
• Overte šírenie cez whatsmydns.net a načítanie na viacerých sieťach (mobil, iný ISP).
• Skontrolujte, či sa všetky prvky (obrázky, skripty) načítavajú cez správne URL a nič neodkazuje na starý server.
• Až keď v logoch VPS vidíte všetku prevádzku a všetko funguje, môžete starý hosting deaktivovať.

10. Optimalizácia výkonu na VPS (PHP + databáza)

Najväčšia výhoda VPS: konfiguráciu vyladíte na mieru vašej aplikácii. Predvolené hodnoty sú konzervatívne a nevyužívajú výkon, ktorý máte k dispozícii. Cieľom je využiť dostupnú RAM efektívne, ale nikdy ju nepresiahnuť – inak server začne swapovať a dramaticky spomalí.

TIP: Optimalizácia je iteratívny proces. Zmeňte jednu vec, spustite záťažový test z sekcie 2, zmerajte dopad, až potom pokračujte. Nepreberajte slepo hodnoty z internetu – riaďte sa tým, čo ukazujú reálne metriky vášho servera.

10.1 Rozdelenie pamäte medzi PHP a databázu

Keď na jednom VPS beží web aj databáza, RAM si musia rozdeliť. Hrubé rozdelenie pre orientáciu (upravte podľa toho, či je aplikácia viac PHP‑náročná alebo DB‑náročná):

# Príklad rozpočtu RAM na VPS s 8 GB Operačný systém a démoni ....... ~1,5 GB InnoDB buffer pool (MariaDB) ... ~3,0 GB # nech pokryje working set PHP-FPM (workery) .............. ~2,5 GB Rezerva / cache OS ............. ~1,0 GB

10.2 Ladenie PHP‑FPM (počet procesov)

Kľúčový parameter je pm.max_children v /etc/php/8.5/fpm/pool.d/www.conf – maximálny počet paralelných PHP procesov. Priveľa procesov zaplní RAM (swap → OOM killer), primálo zbytočne obmedzí súbežnosť.

Ako vypočítať pm.max_children

pm.max_children = RAM vyhradená pre PHP ÷ priemerná pamäť 1 procesu # Príklad: 2,5 GB pre PHP, 1 proces ~60 MB 2560 MB ÷ 60 MB ≈ 42 → s rezervou ~20 % nastavíme pm.max_children = 34

Priemernú pamäť procesu ste zmerali v druhej sekcii tohto návodu. Odporúčaná konfigurácia pool‑u:

Súbor /etc/php/8.5/fpm/pool.d/www.conf

pm = dynamic
pm.max_children = 34
pm.start_servers = 8
pm.min_spare_servers = 6
pm.max_spare_servers = 12
pm.max_requests = 500          ; poistka proti memory leakom - proces sa po 500 req obnoví

; stavová stránka pre monitoring PHP-FPM
pm.status_path = /fpm-status

• pm = dynamic – udržiava pool pripravených procesov (bezpečná voľba pre premenlivú záťaž). ondemand šetrí RAM pri veľmi nízkej návštevnosti.

• pm.max_requests pravidelne recykluje procesy – bráni postupnému nárastu pamäte kvôli únikom.

sudo systemctl restart php8.5-fpm

TIP: Ak sa v logu PHP‑FPM objavuje hláška o dosiahnutí pm.max_children, vytvára sa fronta a odozva rastie – ak to RAM dovolí, hodnotu zvýšte. Ak RAM nie je ani pri špičke využitá, môžete pridať procesy. Rozhodujte podľa merania, nie odhadu.
Zdroj: Ladenie výkonu PHP s PHP‑FPM

10.3 Ladenie MariaDB

Najväčší dopad na výkon má veľkosť InnoDB buffer poolu – RAM, ktorú DB použije na cache dát a indexov. Čím viac dát sa zmestí do RAM, tým menej sa číta z disku. Konfigurácia je v /etc/mysql/mariadb.conf.d/50-server.cnf:

[mysqld]
# Najdôležitejšie: nech pokryje aktívne dáta + indexy (working set).
# Ak DB beží samostatne, dajte 60-70 % RAM; ak zdieľa server s PHP, menej.
innodb_buffer_pool_size = 3G


# Redo log - väčší = menej flushov pri zápisoch (MariaDB 10.11+)
innodb_log_file_size = 512M


# Bezpečné vs. rýchle: 1 = plná ACID odolnosť (default), 2 = rýchlejšie zápisy
innodb_flush_log_at_trx_commit = 1


# Priamy zápis na disk, obchádza cache OS (vhodné, keď má buffer pool RAM)
innodb_flush_method = O_DIRECT


# Prispôsobenie rýchlemu SSD/NVMe úložisku Websupportu
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000


# Log pomalých dotazov - nájde neindexované/ťažké dotazy
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Následne:

sudo systemctl restart mariadb

Ďalšie body:

• Query cache vypnite (query_cache_type = 0). Pri zápisovej záťaži skôr škodí zamykaním; moderné verzie ju už neodporúčajú.
• max_connections držte len tak vysoko, koľko reálne treba (každé spojenie stojí pamäť). Orientačne o niečo viac než pm.max_children.
• Po pár dňoch analyzujte slow.log – opakované pomalé dotazy zvyčajne vyrieši chýbajúci index, nie väčší hardvér.

TIP: Skript MySQLTuner (sudo apt install mysqltuner) po dni prevádzky vypíše odporúčania na základe reálnej štatistiky (napr. či je buffer pool plný a číta sa z disku, koľko dočasných tabuliek padá na disk). Berte ho ako inšpiráciu, meňte parametre postupne.
Zdroj: Ladenie výkonu MySQL/MariaDB/Percona

10.4 Caching na úrovni aplikácie

OPcache

Už je zapnutý. Uistite sa, že opcache.memory_consumption stačí na všetky skripty (skontrolujte cez OPcache status).

Redis / Memcached

sudo apt install redis-server php8.5-redis. Ideálne na object cache a session – výrazne odľahčí databázu (obzvlášť WordPress/WooCommerce).

Nginx microcache

Krátky (1-10 s) cache odpovedí pre neprihlásených návštevníkov nárazovo znásobí priepustnosť pri špičkách a náporoch.

CDN

Cloudflare / BunnyCDN odľahčia statiku a absorbujú časť útokov. Bonus: skryjú pôvodnú IP servera.

10.5 Priebežné sledovanie a doladenie

Pod reálnou záťažou sledujte, či niektorý zdroj nedochádza. Nástroje:

htop                 # CPU, RAM, load average
free -h              # swap used má byť ~0
iostat -x 2          # %util disku (I/O bottleneck)
vmstat 2             # si/so stĺpce = swapovanie (nesmie byť trvalé)

Symptóm	Pravdepodobná príčina	Riešenie
Dochádza RAM / swapuje	priveľa PHP procesov alebo veľký buffer pool	znížiť pm.max_children/buffer_pool, alebo pridať RAM
CPU trvalo na 100 %	CPU‑náročný kód/plugin, málo jadier	profilovať aplikáciu, pridať vCPU
Disk %util vysoké	malý buffer pool → veľa čítaní z disku	zväčšiť buffer pool, doplniť indexy
Odozva rastie, 503	dosiahnutý pm.max_children	zvýšiť (ak RAM dovolí), zapnúť cache

Po vyladení zopakujte záťažový test – uvidíte reálnu novú kapacitu a či pre ďalší rast postačí ladenie, alebo bude treba upgrade (viac RAM/jadier), prípadne rozdelenie záťaže (DB na samostatný VPS, viac web serverov za Load Balancer).

TIP: V našej báze znalostí nájdete aj htop manuál.

11.Prevádzka nespravovavného (unmanaged) VPS

Toto je jadro prechodu managed → unmanaged. Na zdieľanom hostingu sa o operačný systém, aktualizácie, zálohy a bezpečnosť staral Websupport. Na vlastnom VPS je server váš – aj zodpovednosť zaň. Nasledujúce oblasti nie sú jednorazové, tvoria trvalú rutinu prevádzky.

Čo bolo predtým samozrejmé a teraz je na vás

Bezpečnostné záplaty OS, aktualizácie PHP/DB, zálohovanie a jeho testovanie, monitoring dostupnosti, obrana proti útokom, sledovanie expirácií. Nič z toho sa nedeje automaticky „samo“ – musíte to nastaviť a udržiavať. Dobrou správou je, že väčšina sa dá zautomatizovať a Websupport ponúka pomocné služby (snapshoty, monitoring, platená správa servera).

11.1 Aktualizácie systému

Bezpečnostné aktualizácie riešte automaticky (nastaven cez unattended-upgrades). Väčšie zásahy robte ručne a s rozvahou:

sudo apt update && sudo apt upgrade      # pravidelne (napr. týždenne)
sudo apt autoremove                       # upratanie starých balíkov
cat /var/run/reboot-required 2>/dev/null  # treba reštart po update jadra?

11.2 Zálohovanie (3‑2‑1)

Zlaté pravidlo: 3 kópie dát, na 2 rôznych médiách, 1 mimo servera. Záloha, ktorú ste nikdy neobnovili, nie je záloha.

Automatický dump databázy

Súbor /usr/local/bin/db-backup.sh

#!/bin/bash
STAMP=$(date +%F)
DEST=/var/backups/db
mkdir -p "$DEST"
mysqldump --single-transaction --quick --routines --triggers \
  mojadomena_db | gzip > "$DEST/mojadomena_$STAMP.sql.gz"
# zmaž zálohy staršie ako 14 dní
find "$DEST" -name '*.sql.gz' -mtime +14 -delete

Následne:

sudo chmod +x /usr/local/bin/db-backup.sh
sudo crontab -e
# denne o 3:15:
15 3 * * * /usr/local/bin/db-backup.sh

Súbory aplikácie zálohujte podobne (tar priečinka /var/www) a kópie prenášajte mimo servera (iný VPS, objektové úložisko, lokálny disk cez rsync/scp).

TIP: Websupport umožňuje robiť snapshoty celého virtuálneho servera – rýchle obnovenie celého stroja po zlom update. Snapshot je skvelý doplnok, ale nenahrádza dump databázy mimo servera. Kombinujte oboje. Viac na Zálohovanie virtuálneho servera

Otestujte obnovu

Aspoň raz skúšobne obnovte databázu aj súbory na testovacom serveri. Až úspešná obnova potvrdí, že zálohy sú použiteľné. Najhorší čas na zistenie, že záloha je poškodená, je počas reálneho výpadku.

11.3 Monitoring

Na zdieľanom hostingu dostupnosť strážil Websupport. Teraz musíte vy vedieť o probléme skôr než návštevníci. Sledujte minimálne: dostupnosť webu (HTTP), CPU, RAM, voľné miesto na disku (plný disk = pád DB aj webu), beh služieb (nginx, apache2, php8.5‑fpm, mariadb) a platnosť SSL certifikátu.

Nástroj	Na čo
Websupport Monitoring	Dostupnosť a základné metriky priamo od poskytovateľa, s notifikáciami
Netdata	Detailný real‑time dashboard servera, inštalácia na pár minút
Zabbix / Grafana + Prometheus	Robustný monitoring a história metrík pre náročnejšie nasadenia
UptimeRobot	Externé sledovanie dostupnosti zvonku + alerty (e‑mail/SMS)

TIP: Viac o službe Websupport Monitoring

11.4 Bezpečnosť a hardening

• Aktualizujte aplikáciu (jadro CMS, pluginy, knižnice cez composer update). Neaktualizovaný plugin je najčastejšia vstupná brána útoku.
• Firewall a Fail2Ban už bežia. Zvážte pridanie Fail2Ban filtra na webové logy (opakované 401/404, pokusy o login).
• SSH len cez kľúč, root login zakázaný, silné heslá do DB a administrácie.
• phpMyAdmin/Adminer chránený a neverejný; port 3306 nikdy von.
• Pravidelne kontrolujte logy (/var/log/auth.log, logy web servera) na neobvyklú aktivitu.

11.5 Ochrana proti DDoS

Obrana funguje vo vrstvách:

Infraštruktúra

Websupport poskytuje ochranu proti objemovým (L3/L4) útokom na úrovni siete. To je základ, ktorý sami nezaistíte.

Aplikačná vrstva

Rate‑limiting v Nginxe (limit_req), mod_evasive pre Apache, ochrana prihlasovacích formulárov.

CDN / proxy

Cloudflare a pod. absorbujú útok pred serverom, filtrujú L7 a skryjú pôvodnú IP. Účinná prvá línia.

11.6 Pravidelná údržba a upratovanie

• Rotácia logov (logrotate) – aby logy nezaplnili disk. Väčšina balíkov ju nastaví, občas skontrolujte.
• Čistenie starých cache, dočasných súborov, neaktuálnych záloh.
• Sledovanie expirácií: doména, SSL certifikát (auto‑obnova beží, ale kontrolujte), platené API kľúče. Zapíšte si termíny.
• Dokumentujte si konfiguráciu a zásahy – budúce „ja“ (alebo kolega) poďakuje.

Nechcete to riešiť sami?

Ak na správu servera nemáte kapacity, Websupport ponúka službu Správu servera – prevádzku, aktualizácie a dohľad prevezmeme za vás. Kompromis medzi plnou kontrolou unmanaged VPS a bezstarostnosťou manažovaného riešenia.

Zhrnutie

Presunuli sme aplikáciu zo zdieľaného hostingu na vlastný VPS: zmerali sme reálnu záťaž a nadimenzovali server na X‑násobok, postavili identické (a novšie) prostredie na čistom Ubuntu, preniesli dáta, zabezpečili HTTPS, vyladili výkon a prevzali prevádzku vrátane záloh, monitoringu a bezpečnosti. Máte plnú kontrolu aj plnú zodpovednosť nad VPS.

Užitočné zdroje

• Zálohovanie virtuálneho servera

• Prvé kroky s Linux VPS

• Odporúčané minimálne parametre produkčného VPS

• Ubuntu Server – kompletný prehľad informácií o systéme

• Nginx a Apache na jednom Ubuntu serveri

• Správa služieb na virtuálnom serveri s Ubuntu

• Ladenie výkonu MySQL / MariaDB / Percona