Migrace webu bez výpadku: průvodce krok za krokem se zálohou, DNS a testováním

Migrace webu: proč se všichni bojí a proč zbytečně

Klient přenášel e-shop ze sdíleného hostingu na VPS. Všechno zkopíroval, přepnul DNS — a dalších 6 hodin polovina návštěvníků viděla starý server a druhá polovina nový. Objednávky zadané v tomto období jednoduše zmizely — skončily ve staré databázi, kterou už nikdo neobsluhoval.

Příčina byla banální: TTL na DNS záznamech byl nastavený na výchozí hodnotu — 86400 sekund (24 hodin). Kdyby dva dny před migrací snížil TTL na 300 sekund (5 minut), přepnutí by trvalo pár minut, ne půl dne.

Migrace webu není složitá operace. Je to sekvence jednoduchých kroků, kde každý závisí na předchozím. Problémy vznikají když se kroky přeskakují, spěchá se, nebo se začíná s DNS místo se zálohou.

Důvodů k přechodu je mnoho: starý hosting je pomalý, nezvládá provoz, neposkytuje root přístup, nebo jednoduše stojí příliš za to co nabízí. Ať je důvod jakýkoliv — samotný proces migrace je pro všechny stejný. V tomto průvodci — přesný sled kroků, který umožňuje přenést web s nulovým výpadkem. Žádná magie, žádné drahé nástroje — jen správné pořadí a pozornost k detailům.

Krok 1: Příprava na migraci

90 % problémů při migraci je důsledkem špatné přípravy. Přenos souborů trvá minuty, ale obnova po ztrátě dat hodiny nebo dny. Viděli jsme případy, kdy klienti přišli o týdny práce jen proto, že si před začátkem neudělali zálohu — předpokládali, že „nic se nestane." Vždycky se něco stane. Otázka je jen, zda máte plán B.

Kompletní záloha

Jako první — vytvořte kompletní zálohu aktuálního webu. To je vaše pojistka. Pokud se něco pokazí v jakékoliv fázi — vrátíte se za pár minut. Bez zálohy se každá chyba stává nevratnou: špatný konfig, přepsaná tabulka, přepsaný soubor — a není odkud obnovit.

Co zahrnout do zálohy:

• Soubory webu — celý adresář public_html nebo www, včetně .htaccess a konfiguračních souborů
• Databáze — kompletní dump přes mysqldump nebo phpMyAdmin
• E-mailové účty — pokud je e-mail na stejném hostingu
• SSL certifikáty — pokud máte placený certifikát, uložte klíč a certifikát
• Cron úlohy — zkopírujte rozvrh úloh, snadno se na to zapomíná

# Záloha souborů přes tar
tar -czf backup_site_$(date +%Y%m%d).tar.gz /var/www/html/
# Záloha databáze
mysqldump -u root -p --single-transaction --routines mydb > backup_db_$(date +%Y%m%d).sql

Snížení DNS TTL

Toto je nejdůležitější krok přípravy a je třeba ho udělat 24–48 hodin PŘED migrací. Přejděte do DNS panelu vašeho doménového registrátora a změňte TTL pro A záznam z aktuální hodnoty (obvykle 3600 nebo 86400) na 300 sekund (5 minut).

Proč? TTL určuje jak dlouho DNS resolvery po celém světě cachují vaši IP adresu. Pokud TTL = 86400 (24 hodin), po změně IP adresy část uživatelů ještě den uvidí starý server — protože jejich DNS provider si starou adresu uložil do cache a nebude kontrolovat novou, dokud TTL nevyprší. Pokud TTL = 300 (5 minut) — DNS provideři kontrolují záznamy každých 5 minut a přepnutí proběhne téměř okamžitě.

Příklad: váš aktuální TTL = 14400 (4 hodiny). Změníte ho na 300. Ale musíte počkat těch 4 hodin, aby se stará hodnota TTL „vyplavila" ze všech cache. Teprve potom se nový TTL = 300 stane aktivním. Proto je třeba tento krok udělat 24–48 hodin před migrací — abyste měli 100% jistotu.

Inventura

Před přenosem sestavte seznam toho, co musí fungovat po migraci. Zní to samozřejmě, ale právě „samozřejmé" věci se zapomínají. Udělejte to v textovém souboru nebo tabulce — nespoléhejte na paměť:

• Verze PHP a rozšíření (zkontrolujte přes php -v a php -m na starém serveru)
• Verze MySQL/MariaDB
• Externí služby: platební brány, API integrace, CDN
• Přesměrování (.htaccess nebo Nginx konfig)
• Poštovní záznamy (MX, SPF, DKIM) — pokud e-mail jde přes hosting

Krok 2: Přenos souborů a databáze

Záloha hotová, TTL snížený, inventura připravená — čas přenášet data. Starý hosting pokračuje v normálním provozu a obsluhuje živé návštěvníky. Na novém serveru nastavíme kopii, otestujeme, a teprve když vše funguje perfektně — přepneme DNS. Zlaté pravidlo: dokud jste neověřili vše na novém serveru — na DNS nesahejte.

Soubory

Pro malé weby (do několika gigabajtů) postačí SCP nebo SFTP přes grafického klienta typu FileZilla. Pro velké projekty — rsync, který zobrazuje průběh, kopíruje pouze změněné soubory a pokračuje po přerušení spojení (místo začínání od nuly). Rsync je nejspolehlivější nástroj pro přenos souborů mezi servery, používá se i v korporátních migracích:

# Přímý přenos mezi servery (pokud máte SSH přístup k oběma)
rsync -avz --progress /var/www/html/ user@new-server:/var/www/html/
# Nebo přes lokální stroj (dva kroky)
scp -r user@old-server:/var/www/html/ ./site-backup/
scp -r ./site-backup/ user@new-server:/var/www/html/

Věnujte pozornost právům přístupu po kopírování — nemusí se zachovat. Po přenosu spusťte na novém serveru:

chown -R www-data:www-data /var/www/html/
find /var/www/html/ -type d -exec chmod 755 {} \;
find /var/www/html/ -type f -exec chmod 644 {} \;

Tím se nastaví standardní práva: adresáře 755, soubory 644, vlastník www-data (pro Nginx a Apache).

Databáze

Přenos databáze je nejkritičtější fáze. Chyba zde znamená buď ztrátu dat, nebo nefunkční web. Standardní postup — dump na starém serveru, přenos souboru, import na novém:

# Na starém serveru — vytvoříme dump
mysqldump -u root -p --single-transaction mydb > mydb.sql
# Přeneseme soubor na nový server
scp mydb.sql user@new-server:/tmp/
# Na novém serveru — importujeme
mysql -u root -p mydb < /tmp/mydb.sql

Příznak --single-transaction je kriticky důležitý pro InnoDB tabulky — umožňuje konzistentní dump bez blokování databáze. Bez něj se během dumpu mohou zapsat nová data a dump bude nekonzistentní.

Pro velké databáze (10+ GB) použijte kompresi při přenosu — zkrátí čas 3–5× a ušetří šířku pásma:

mysqldump -u root -p --single-transaction mydb | gzip | ssh user@new-server "gunzip | mysql -u root -p mydb"

Konfigurace na novém serveru

Po zkopírování souborů zkontrolujte a aktualizujte konfigurace. To je jeden z nejčastějších zdrojů chyb — soubory jsou na novém serveru, ale aplikace se stále pokouší připojit k databázi na starém:

• wp-config.php (WordPress) — nové údaje pro připojení k databázi: host, název databáze, uživatel, heslo
• .env (Laravel, Node.js atd.) — connection stringy k databázi a externím službám
• Práva přístupu — ověřte, že webový server má přístup k souborům: chown -R www-data:www-data /var/www/html/
• Verze PHP — na novém serveru může být jiná verze, zkontrolujte kompatibilitu

Specifika pro WordPress

WordPress je nejpopulárnější CMS a při migraci má několik specifických nuancí. V databázi jsou uloženy absolutní URL adresy webu (v tabulkách wp_options, wp_posts, wp_postmeta). Pokud se doména nemění — žádný problém. Ale pokud jste přenášeli na dočasnou doménu pro testování — je třeba provést hledání a nahrazení URL přes WP-CLI:

wp search-replace 'temp-domain.com' 'your-domain.com' --all-tables

Také ověřte, že na novém serveru jsou nainstalovaná všechna PHP rozšíření, která vyžadují vaše pluginy. Nejčastěji: php-mysql, php-curl, php-gd, php-mbstring, php-xml. Chybějící rozšíření může rozbít konkrétní plugin bez viditelných chyb — web bude fungovat, ale nějaká funkce tiše přestane.

Po migraci přejděte do administrace WordPress → Nastavení → Trvalé odkazy → klikněte „Uložit změny" (bez úprav). Tím se přegenerují pravidla přesměrování URL a často to opraví chyby 404 na interních stránkách.

Migrace z cPanel nebo DirectAdmin

Pokud váš stávající hosting používá cPanel — proces přenosu lze zjednodušit přes vestavěnou zálohu. Přejděte do cPanel → Backup → Generate Full Backup. Tím se vytvoří archiv se všemi soubory, databázemi, e-mailovými účty, cron úlohami a konfigy v jednom souboru.

Pokud nový server také má cPanel — tento archiv lze importovat jako celek. Pokud nový server nemá panel (čistý VPS s Nginx) — archiv bude třeba rozbalit ručně a přenést soubory a databázi zvlášť, jak je popsáno výše.

DirectAdmin má podobnou funkci: Panel → Admin Backup / Transfer. Stejný postup: kompletní záloha na starém → přenos → import na novém. Hlavní věc — ujistěte se, že verze panelů jsou kompatibilní, jinak import nemusí projít.

Pro servery bez ovládacích panelů (čistý Linux s Nginx nebo Apache) — použijte rsync + mysqldump jak je popsáno výše. To je nejuniverzálnější metoda, která funguje mezi jakýmikoliv servery nezávisle na panelech a konfiguracích.

Pokud nemáte SSH přístup ke starému hostingu

Na některých sdílených hostinzích je SSH zakázáno. V takovém případě jsou k dispozici alternativní metody přenosu souborů a databáze:

Soubory — stáhněte přes správce souborů v panelu hostingu (cPanel File Manager) nebo přes FTP/SFTP klienta (FileZilla, WinSCP). Pro velké weby to může trvat výrazně déle než rsync, ale funguje to vždy.

Databáze — exportujte přes phpMyAdmin (obvykle dostupný v panelu hostingu). Vyberte databázi → záložka „Export" → formát SQL → klikněte „Go." Soubor se stáhne do počítače. Poté ho importujte na novém serveru přes phpMyAdmin nebo příkazovou řádku.

Tato metoda je pomalejší než rsync + mysqldump, ale umožňuje přenést web i z nejvíce omezeného sdíleného hostingu.

Krok 3: Testování na novém serveru

Soubory a databáze přeneseny, konfigurace aktualizovány — ale DNS stále směřuje na starý server. To je ideální moment pro testování: skuteční uživatelé pokračují v práci se starým serverem jako obvykle a vy máte kolik chcete času na ověření všeho na novém. Nespěchejte — lepší strávit hodinu navíc testováním, než pak opravovat problémy pod tlakem živého provozu.

Testování přes soubor hosts

Abyste viděli web na novém serveru před změnou DNS — přidejte záznam do souboru hosts na svém počítači:

# Windows: C:\Windows\System32\drivers\etc\hosts
# macOS/Linux: /etc/hosts
198.51.100.25  example.com
198.51.100.25  www.example.com

Nahraďte 198.51.100.25 IP adresou nového serveru a example.com vaší doménou. Nyní váš prohlížeč bude otevírat web z nového serveru, zatímco všichni ostatní návštěvníci vidí starý. To umožňuje plně otestovat web v reálných podmínkách — se správnou doménou, SSL a všemi konfigy — bez rizika pro živé uživatele.

Co zkontrolovat

Projděte si kompletní kontrolní seznam — každý vynechaný bod je potenciální problém po přepnutí DNS. Kontrolujte nejen „jestli se stránka otevře," ale i funkcionalitu závislou na databázi, souborovém systému a externích službách:

• Hlavní stránka a všechny hlavní sekce se načítají bez chyb
• Formuláře fungují — registrace, kontaktní formulář, vyhledávání
• Administrace je přístupná a funkční
• Obrázky se zobrazují (častý problém — hardcodované absolutní cesty)
• HTTPS funguje (pokud jste už nastavili SSL na novém serveru)
• Pro e-commerce: košík, pokladna, platební brána
• E-mail se odesílá z nového serveru (otestujte přes kontaktní formulář)

Krok 4: Přepnutí DNS a finální synchronizace

Testování proběhlo úspěšně — čas přepnout provoz. Ale nejdříve si projděte finální kontrolní seznam. Každý vynechaný bod je riziko problémů po přepnutí:

Je tu nuance, které se často nevěnuje pozornost: mezi momentem vytvoření dumpu databáze a momentem přepnutí DNS uplynul čas. Pokud je web aktivní — za tu dobu mohly na starém serveru přibýt nové objednávky, komentáře, registrace. Ty je třeba synchronizovat.

Finální synchronizace

Bezprostředně před přepnutím DNS proveďte finální rsync a čerstvý dump databáze. Rsync s příznakem --delete smaže soubory na novém serveru, které už na starém neexistují — to garantuje úplnou shodu:

# Dohrát pouze změněné soubory
rsync -avz --delete --progress user@old-server:/var/www/html/ /var/www/html/
# Čerstvý dump databáze
mysqldump -u root -p --single-transaction mydb > final_dump.sql
mysql -u root -p mydb < final_dump.sql

Pro weby s vysokou aktivitou (e-commerce, fóra, SaaS) je tento krok kriticky důležitý. Mezi prvním přenosem databáze a momentem přepnutí DNS mohlo uplynout několik hodin nebo dokonce dní — za tu dobu na starém serveru přibyly nové objednávky, komentáře, registrace. Pokud jednoduše přepnete DNS bez finální synchronizace — tato data se ztratí.

Pro vysoce vytížené projekty doporučujeme tento přístup: přepněte web na starém serveru do režimu údržby (maintenance mode) na 10–15 minut, proveďte finální dump, importujte na nový server, ověřte — a teprve potom přepněte DNS. 15 minut plánovaného výpadku je výrazně lepší než ztracené objednávky nebo duplicitní data.

Změna DNS

Aktualizujte A záznam vaší domény na IP adresu nového serveru v panelu doménového registrátora. Pokud jste předem snížili TTL na 300 sekund — většina uživatelů uvidí nový server do 5–10 minut. Nejlepší čas pro přepnutí je noc nebo časné ráno pracovního dne, kdy je provoz minimální.

Monitoring propagace

DNS propagace není okamžitý proces. Různé DNS resolvery po celém světě se aktualizují různou rychlostí. I s TTL 300 sekund mohou někteří provideři cachovat záznamy déle. Stav propagace napříč regiony a providery můžete zkontrolovat na bezplatných službách jako dnschecker.org nebo whatsmydns.net — ukazují, jakou IP adresu vidí DNS servery v různých zemích.

Během propagace může část provozu směřovat na starý server, část na nový. Proto je důležité udržovat oba servery aktivní a synchronizované do úplného dokončení procesu. Neprovádějte změny obsahu webu, dokud propagace neskončí — jinak budou změny viditelné pouze části návštěvníků.

Krok 5: Kontrola po migraci

DNS přepnutý, provoz směřuje na nový server — ale práce ještě není hotová. Prvních 24–48 hodin je kritické období. Sledujte error logy, kontrolujte rychlost načítání (nový server by měl být minimálně stejně rychlý jako starý) a reagujte na jakékoliv stížnosti uživatelů.

SEO kontrola

Migrace může poškodit SEO pokud se změnily URL adresy nebo zmizely stránky. Vyhledávače jsou na takové změny velmi citlivé — i dočasná nedostupnost stránek může vést ke ztrátě pozic, které se budovaly měsíce. Nezapomeňte:

• Zkontrolujte Google Search Console na chyby indexace během týdne po migraci
• Ujistěte se, že robots.txt a sitemap.xml jsou dostupné a správné na novém serveru
• Pokud se změnily URL — nastavte 301 přesměrování ze starých adres na nové. V Nginx:

  # V konfiguraci Nginx
  rewrite ^/old-page$ /new-page permanent;

• Ověřte, že canonical tagy směřují na správné URL
• Odešlete aktualizovanou sitemap přes Google Search Console — to urychlí reindexaci

Rychlost načítání je další SEO faktor, který stojí za kontrolu. Pokud je nový server pomalejší než starý (například kvůli jiné lokaci datového centra nebo slabší konfiguraci), může to negativně ovlivnit pozice. Zkontrolujte přes Google PageSpeed Insights nebo GTmetrix a porovnejte výsledky s tím, co bylo na starém hostingu.

Kontrola funkčnosti

Během prvního týdne po migraci pravidelně kontrolujte error logy na novém serveru. Problémy, které se neprojevily při testování, se mohou objevit pod reálnou zátěží — více provozu, více současných připojení k databázi, více požadavků na souborový systém. Monitorujte:

# Nginx — chyby
tail -f /var/log/nginx/error.log
# Apache — chyby
tail -f /var/log/apache2/error.log
# PHP — chyby (pokud je logování nastaveno)
tail -f /var/log/php-fpm/error.log

Pokud vidíte chyby 502 Bad Gateway nebo 504 Gateway Timeout — obvykle to znamená, že PHP-FPM nebo backend nestíhá zpracovávat požadavky. Možná bude třeba zvýšit počet PHP-FPM workerů nebo zvýšit limity paměti.

SSL certifikát

Pokud používáte Let's Encrypt (nejběžnější varianta pro většinu webů) — je třeba vygenerovat nový certifikát na novém serveru. Starý certifikát je vázaný na starý server a nepřenese se automaticky:

sudo certbot --nginx -d example.com -d www.example.com

Certbot automaticky nakonfiguruje Nginx a bude certifikát obnovovat každých 90 dní. Pokud máte placený certifikát (např. EV nebo Wildcard) — přeneste privátní klíč a soubor certifikátu na nový server a nastavte cesty v konfiguraci Nginx nebo Apache.

E-mail

Pokud byl e-mail na starém hostingu (velmi běžná konfigurace pro malé weby) — ujistěte se, že MX záznamy směřují na správný poštovní server. To je nejčastější příčina „zmizelých" e-mailů po migraci: DNS už směřuje na nový server, ale e-mail na něm není nastavený — zprávy se jednoduše odrážejí.

Pokud je e-mail na externí službě (Google Workspace, Zoho Mail, Microsoft 365) — MX záznamy se nemění a vše bude fungovat jako dříve. Ale zkontrolujte SPF a DKIM záznamy — mohou obsahovat IP adresu starého serveru a e-maily z nového serveru budou končit ve spamu.

Kdy můžete smazat starý hosting

Ne dříve než 72 hodin po přepnutí DNS — to je maximální doba propagace pro většinu DNS providerů. Ještě lepší — počkejte týden, ujistěte se, že vše běží stabilně, a teprve potom rušte. Ušetřených $10–20 měsíčně za starý hosting nestojí za riziko ztráty dat. Někteří poskytovatelé smažou všechny soubory okamžitě po zrušení — bez varování a bez možnosti obnovy.

Typy migrace: porovnání přístupů

Složitost migrace závisí na typu webu, velikosti databáze a počtu integrací. Jednoduchý landing page se přenese za 15 minut, zatímco high-load e-commerce s vlastními integracemi může zabrat celý pracovní den.

Obecné pravidlo: čím více dynamického obsahu a externích integrací — tím více pozornosti vyžaduje testování. Statický web nebo landing page — soubory zkopírujete a vše funguje. E-shop s platebními bránami, e-mailovými kampaněmi, CRM integracemi — každý z těchto systémů je třeba po přenosu ověřit zvlášť.

7 chyb, které dělají migraci bolestivou

Tyto chyby jsme sesbírali z reálných zkušeností — většina z nich vypadá na papíře očividně, ale pravidelně se opakuje i u zkušených administrátorů. Obvykle kvůli spěchu nebo přesvědčení, že „já si to stejně pamatuju."

Pokud si nejste jistí svými schopnostmi nebo je web pro byznys kritický (e-commerce, SaaS) — svěřte migraci profesionálům. Cena chyby při migraci e-shopu s obratem byť jen $1000 denně může převýšit jakoukoliv cenu migrační služby. Hostiserver provádí bezplatnou migraci pro všechny nové klienty — a to je jeden z nejsilnějších argumentů pro to, abyste to nedělali sami.

Často kladené dotazy