Jak vytvořit kopii webu pro vývoj a testování (staging)

Chcete vyzkoušet aktualizaci WordPressu, otestovat nový plugin nebo udělat zásadní úpravu webu bez rizika, že zákazníkům přestane fungovat e-shop? K tomu slouží staging prostředí — oddělená kopie vašeho webu, na které můžete bezpečně experimentovat, aniž by se cokoliv dotklo produkce.

Staging je plnohodnotná kopie webu se všemi soubory a databází, typicky umístěná na subdoméně (například staging.example.cz). Když na stagingu uděláte úpravu, v produkci se nic nestane. Teprve až si ověříte, že všechno funguje, můžete změny přenést zpět.

Typické situace, kdy se staging vyplatí: aktualizace jádra WordPressu nebo PrestaShopu, testování nového pluginu na produkčních datech, vývoj redesignu pro klienta, QA před migrací na novou verzi PHP nebo před přechodem na jinou distribuci. Ve všech těchto případech platí jednoduché pravidlo — raději udělat kopii a otestovat tam, než opravovat ostrý web po půlnoci.

V tomto článku vás provedeme třemi cestami, jak kopii webu vytvořit: webhostingovým nástrojem v Zákaznickém portálu, staging prostředím ve VPS Centru V3 (včetně nahrání změn zpět do produkce) a klonovacími nástroji ve VPS Centru V2. Každé rozhraní to řeší trochu jinak, ale cíl je stejný — bezpečně oddělená kopie, na které se nedá nic rozbít.

Rychlý přehled pro pokročilé

Tato část slouží pouze pro ověření pro velmi zkušené uživatele, kteří si chtějí pouze ověřit postup a nepotřebují číst celý článek. Pro všechny ostatní doporučujeme pokračovat další sekcí.

  1. Webhosting (Zákaznický portál): Detail domény → Instalátor CMS → u instalace tlačítko Klonovat subdoménu
    vybrat zdrojovou subdoménu, vyplnit prefix nové, zaškrtnout Zkopírovat databáziVytvořit kopii.
  2. VPS Centrum V3 — vytvoření staging prostředí: detail subdomény → Staging+ Nová dev stage → vyplnit název, zaškrtnout Kopírovat databázi, vybrat zdrojovou databázi → Vytvořit staging.
  3. VPS Centrum V3 — nahrání změn do produkce (Deploy): u staging řádku Deploy → zvolit Co obnovit + Způsob nahrání databáze → zapnout Vytvořit snapshot před nahránímNahrát do produkce.
  4. VPS Centrum V2: u domény v sekci FTP tlačítko Klonovat ftp + v sekci Databáze u konkrétní databáze dropdown Nástroje → Klonovat. Ruční úprava wp-config.php nebo ekvivalentu.
  5. Po vytvoření kopie: zkontrolovat URL v databázi (siteurl, home u WordPressu), aktivovat SSL certifikát pro subdoménu, zakázat duplicitní cron úlohy.

Co je dobré vědět předem

Na přípravu a provedení si vyhraďte 10–20 minut u UI nástrojů (Zákaznický portál, VPS Centrum V3 staging). U postupu přes SSH počítejte s 30–90 minutami podle velikosti webu a databáze.

Pozor: Před jakýmkoliv zásahem do produkčního webu (zejména před funkcí Deploy, která přepisuje produkci daty ze stagingu) vždy udělejte zálohu. Většina nástrojů v tomto článku má vestavěnou bezpečnostní funkci (automatický snapshot před nahráním), ale doporučujeme mít i nezávislou zálohu mimo server.

Co budete potřebovat

  • Přístup do Zákaznického portálu (pro webhosting) nebo do VPS Centra (pro VPS) s oprávněním spravovat domény, databáze a subdomény.
  • Dostatek volného místa na disku — staging je plnohodnotná kopie, takže potřebujete zhruba dvojnásobek prostoru, který zabírá produkční web.
  • U alternativního postupu přes SSH: aktivovaný SSH přístup k serveru. Pokud s SSH teprve začínáte, doporučujeme nejprve náš návod Jak se připojit k serveru přes SSH.

Jak zjistíte verzi VPS Centra

Verze VPS Centra je viditelná v rozhraní — u VPS Centra V3 v pravém dolním rohu obrazovky, u VPS Centra V2 v patičce stránky (dole vlevo, vedle odkazů na API a Dokumentaci). Pokud číslo začíná „3.“ (například v3.2.0), používáte VPS Centrum V3. Pokud „2.“ (například v2.66), je to VPS Centrum V2. Pokud jste na webhostingu, máte Zákaznický portál a VPS Centrum se vás netýká.

Rozdíl mezi verzemi je v tomto článku zásadní — VPS Centrum V3 nabízí plnohodnotné staging prostředí s obousměrným workflow (Diff, Sync, Deploy, Snapshot, Rollback), zatímco VPS Centrum V2 umí jen jednorázové klonování souborů a databáze bez navazujícího deployment workflow.

Webhosting (Zákaznický portál) — klonování subdomény

Pokud máte web na webhostingu u Váš Hosting, máte k dispozici nejjednodušší cestu — nástroj Klonovat subdoménu v Instalátoru CMS. Ten zkopíruje soubory webu, volitelně vytvoří i samostatnou kopii databáze a u běžných CMS (WordPress a další, pokud nástroj najde konfigurační soubor) automaticky přepíše přístupové údaje k databázi i URL v nastavení webu. Celý proces trvá několik minut.

Postup krok za krokem:

  1. Přihlaste se do Zákaznického portálu na portal.vas-hosting.cz.
  2. U domény, jejíž web chcete klonovat, klikněte na Detail.
  3. V detailu domény otevřete sekci Instalátor CMS.
  4. U instalace CMS, kterou chcete klonovat, klikněte na Klonovat subdoménu.
  5. Otevře se dialog Klonování subdomény. V dropdownu Subdoména vyberte zdrojovou subdoménu, ze které se bude klonovat (obvykle www).
  6. Do pole Nová subdoména zadejte prefix subdomény (například staging). Hlavní doména se automaticky doplní jako sufix — výsledkem bude staging.example.cz.
  7. Zaškrtněte Zkopírovat databázi. Doporučujeme vždy zaškrtnout — bez kopie by klon sdílel databázi s produkcí, takže jakákoliv úprava v admin rozhraní nebo v obsahu by se projevila i na ostrém webu (přesný opak toho, proč si staging vytváříte).
  8. V dropdownu Databáze, která se zkopíruje vyberte zdrojovou databázi (obvykle portál automaticky nabídne databázi přiřazenou k webu).
  9. V poli Název nové databáze nechte automaticky vygenerovaný název, nebo klikněte na Generovat název pro jiný návrh. Předvyplněný sufix (např. _50618) je unikátní identifikátor, který brání kolizi s existujícími databázemi — ponechte ho.
  10. Klikněte na Vytvořit kopii.
Zákaznický portál, sekce Instalátor CMS, tlačítko Klonovat subdoménu

Pozor: Pokud portál v dialogu zobrazí červené varování ve znění „Na webu jsme nedetekovali konfigurační soubor s údaji k připojení do databáze“, znamená to, že nástroj nenašel soubor typu wp-config.php (WordPress), configuration.php (Joomla) nebo ekvivalentní. Po klonování se přístupové údaje k nové databázi nepřepíšou automaticky — klon bude připojený k databázi produkce, dokud ručně neupravíte konfigurační soubor. Ruční úpravu popisujeme v sekci
Co udělat po vytvoření kopie. Pokud varování nevidíte, portál konfigurační soubor našel a přepíše ho automaticky.

Co se během klonování stane:

  • Vytvoří se nová subdoména (například staging.example.cz) s vlastním webrootem.
  • Zkopírují se všechny soubory webu z produkční domény na subdoménu.
  • Pokud jste zaškrtli Zkopírovat databázi, vytvoří se nová databáze s vlastními přihlašovacími údaji a do ní se naimportují data zdrojové databáze.
  • Pokud portál detekoval konfigurační soubor webu (u WordPressu wp-config.php), automaticky v něm přepíše přístupové údaje na novou databázi. U WordPressu zároveň v tabulce wp_options přepíše hodnoty siteurl a home na novou URL subdomény.
  • Pokud konfigurační soubor nebyl detekován, přepis musíte provést ručně (viz varování níže).
Zákaznický portál, sekce Instalátor CMS, tlačítko Klonovat subdoménu

Indikátor úspěchu: Po dokončení se zobrazí zpráva o úspěšném vytvoření klonu a nová subdoména je v seznamu subdomén u dané domény. Otevřete ji v prohlížeči — měli byste vidět funkční kopii webu na nové adrese.

Po klonování vás čekají ještě drobné kroky (aktivace SSL certifikátu pro subdoménu, zabránění duplicitním cron úlohám) — jsou popsané v sekci Co udělat po vytvoření kopie níže.

VPS Centrum V3 — staging prostředí

Pokud máte VPS spravovaný přes VPS Centrum V3, máte k dispozici plnohodnotné staging prostředí s obousměrným workflow. Umožní vám nejen vytvořit kopii webu na subdoméně, ale také porovnat staging s produkcí, synchronizovat data a nahrát dokončené změny zpět do produkce. Navíc nabízí snapshoty — body obnovení produkce, které lze využít jako pojistku před rizikovou úpravou.

Správa verzí ve VPS Centru V3 je aktuálně v režimu beta. Funkce není vždy plně stabilní. Před použitím vždy udělejte nezávislou zálohu dat a počítejte s tím, že některé akce (zejména Deploy do produkce) mohou v ojedinělých případech selhat. Záložní postup přes SSH najdete v sekci Alternativní klonování přes SSH.

Jak staging prostředí ve V3 funguje

Staging je oddělená subdoména s vlastní kopií souborů a databází. Mezi produkcí a stagingem fungují tři operace:

  • Sync (produkce → staging) — přepíše staging aktuálními produkčními daty. Užitečné, když chcete na čerstvé kopii začít novou úpravu.
  • Deploy (staging → produkce) — nahraje změny ze stagingu do produkce. Toto je způsob, jak po dokončení úprav přenést výsledek na ostrý web.
  • Diff — zobrazí, zda se databáze stagingu liší od produkce. Užitečné před Deploy — vidíte, jestli je co nahrávat.

Navíc lze kdykoliv u produkční verze vytvořit snapshot — zmrazený stav, ke kterému se lze vrátit pomocí funkce Rollback. Staging workflow tak tvoří kompletní vývojový cyklus: vytvořit kopii → upravit → porovnat → nahrát zpět, plus pojistku pro případ, že se něco pokazí.

Funkce funguje jak pro weby postavené na WordPressu, tak pro weby bez WordPressu. U WordPress webů navíc nástroj automaticky upraví přístupové údaje k databázi ve wp-config.php. U non-WordPress webů pouze zkopíruje soubory a databázi — případné úpravy konfigurace si musíte udělat sami.

Vytvoření staging prostředí ve V3

  1. Ve VPS Centru V3 otevřete sekci Domény a klikněte na doménu, jejíž web chcete klonovat.
  2. V levém panelu detailu domény rozbalte Subdomény a vyberte subdoménu (obvykle www).
  3. V panelu subdomény klikněte na položku Staging.
  4. Zobrazí se obrazovka Správa verzí s aktuální produkční verzí. V pravém horním rohu klikněte na + Nová dev stage.
  5. V dialogu Nová dev stage vyplňte Název staging prostředí — pod tímto názvem vznikne subdoména (například název stage vytvoří subdoménu stage.example.cz).
  6. Ponechte zaškrtnuté Kopírovat databázi, pokud chcete kopii včetně dat.
  7. V dropdownu Zdrojová databáze vyberte databázi, ze které se bude kopírovat. VPS Centrum automaticky předvyplní aktivní databázi produkce.
  8. Volitelně vyplňte Poznámku (například „Před aktualizací WordPressu“).
  9. Klikněte na Vytvořit staging.
VPS Centrum V3, Správa verzí, tlačítko Nová dev stage

Co se během vytváření stane:

  • Vytvoří se nová subdoména (například stage.example.cz).
  • Zkopírují se všechny soubory z webrootu produkce do webrootu nové subdomény.
  • Pokud jste zaškrtli Kopírovat databázi, vytvoří se nová databáze s názvem odvozeným od zdrojové (například zdrojová saldova_cz → staging saldova_cz_stage).
  • U WordPress webů se ve wp-config.php automaticky přepíšou přístupové údaje na novou databázi.
Dialog Nová dev stage s vyplněnými údaji

Indikátor úspěchu: Nahoře se zobrazí zelená zpráva „Staging prostředí [název] bylo úspěšně vytvořeno“ a ve Správě verzí se objeví nový řádek se staging prostředím. U WordPress webů má řádek badge Aktivní a WordPress.

Správa verzí po vytvoření staging prostředí

Po vytvoření stagingu ho můžete otevřít tlačítkem Otevřít u staging řádku. Od této chvíle na něm můžete dělat libovolné úpravy — soubory, databázi, pluginy — bez dopadu na produkci.

Práce se staging prostředím

U aktivního staging řádku máte k dispozici čtyři tlačítka:

  • Otevřít — otevře staging subdoménu v novém panelu prohlížeče. Zde testujete výsledek úprav.
  • Diff — zobrazí dialog Rozdíl v databázi. Pokud je databáze stagingu totožná s produkcí, uvidíte zelené hlášení „Databáze staging prostředí odpovídá produkční verzi.“ V opačném případě uvidíte, že se liší.
  • Sync — přepíše staging aktuálními produkčními daty. Užitečné, když jste na stagingu něco zkoušeli a chcete začít nanovo s čerstvou kopií produkce.
  • Deploy — nahraje změny ze stagingu zpět do produkce (popsáno v další sekci).
Staging řádek v seznamu verzí s akčními tlačítky

Synchronizace ze stagingu s produkcí (Sync):

  1. U staging řádku klikněte na Sync.
  2. V dialogu Synchronizovat staging vyberte, co synchronizovat: Vše (soubory i databázi) pro kompletní obnovení stagingu z produkce, Pouze soubory pro přepis jen souborů (databáze stagingu zůstane) nebo Pouze databázi pro přepis jen databáze (soubory stagingu zůstanou).
  3. Klikněte na Synchronizovat.

Indikátor úspěchu: Zpráva „Staging prostředí [název] bylo úspěšně synchronizováno“.

Důležité: Sync přepisuje staging, ne produkci. Je to bezpečná operace — data v produkci zůstanou nedotčena. Opačný směr (ze stagingu do produkce) se dělá přes Deploy.

Nahrání změn ze stagingu zpět do produkce (Deploy)

Když máte na stagingu dokončené úpravy a chcete je přenést do produkce, použijete funkci Deploy. Na rozdíl od Sync jde o zápis do produkce, takže si u něj dávejte pozor.

  1. U staging řádku klikněte na Deploy.
  2. V dialogu Deploy do produkce nastavte parametry (detailní popis voleb najdete pod tímto postupem).
  3. Klikněte na Nahrát do produkce.

Volby v dialogu Deploy do produkce:

  • Co obnovit — tři možnosti: Vše (soubory i databázi) pro přenos kompletních změn, Pouze soubory když chcete zachovat produkční databázi beze změny, nebo Pouze databázi pro přenos jen databáze.
  • Způsob nahrání databáze — dvě možnosti:
    • Kopírování (mysqldump) — kompletní kopie databáze včetně procedur, triggers a views. Spolehlivější, ale pomalejší. Během kopírování může být krátký výpadek, než se databáze přepne.
    • Atomic swap (přejmenování tabulek) — rychlejší přepnutí s minimálním výpadkem. Vhodné pro větší databáze, kde by mysqldump trval dlouho. Procedury, triggery a views se nemusí přenést.
  • Vytvořit snapshot před nahránímdůrazně doporučujeme ponechat zaškrtnuté. Před samotným Deploy se automaticky vytvoří snapshot aktuální produkce, takže v případě problémů lze změny vrátit zpět pomocí Rollback.
  • Smazat soubory, které nejsou ve staging — volitelný cleanup. Pokud zaškrtnete, odstraní se z produkce všechny soubory, které na stagingu neexistují. Hodí se, když jste na stagingu mazali staré soubory a chcete stejný stav v produkci.
Dialog Deploy do produkce s nastavenými volbami

Indikátor úspěchu: Zpráva „Staging prostředí [název] bylo úspěšně nahráno do produkce“. Produkční web obsahuje změny ze stagingu.

Pozor: Pokud se Deploy nepodaří nebo zobrazí chybu, funkce je v beta režimu — doporučujeme zopakovat akci, případně použít Alternativní klonování přes SSH.

Snapshoty a rollback produkce

Snapshot je zmrazený stav produkce — soubory (a volitelně databáze) v daném okamžiku, ke kterému se lze kdykoliv vrátit. Na rozdíl od staging prostředí není snapshot určen k práci — slouží čistě jako pojistka pro případ, že se něco pokazí.

Kdy se hodí vytvořit snapshot ručně:

  • Před ruční úpravou produkční databáze (SQL dotazem, úpravou přes phpMyAdmin).
  • Před aktualizací jádra CMS nebo klíčového pluginu přímo na produkci.
  • Před jakýmkoliv zásahem, u kterého si nejste jistí výsledkem.
  • Před migrací webu na jinou verzi PHP.

Vytvoření snapshotu:

  1. Ve Správě verzí u produkčního řádku (www.example.cz) klikněte na Snapshot.
  2. V dialogu Nový snapshot rozhodněte, zda chcete Zálohovat databázi (doporučujeme ponechat zaškrtnuté).
  3. Vyplňte Poznámku (například „Před aktualizací WP“).
  4. Klikněte na Vytvořit snapshot.
Dialog vytvoření snapshotu produkce

Obnovení produkce ze snapshotu (Rollback):

Pokud se po zásahu do produkce ukáže, že je něco špatně, můžete se vrátit ke snapshotu:

  1. Ve Správě verzí u snapshot řádku klikněte na Rollback.
  2. V dialogu Rollback do produkce vyberte Co obnovit a Způsob nahrání databáze (volby jsou stejné jako u Deploy).
  3. Doporučujeme ponechat zaškrtnuté Vytvořit snapshot před nahráním — i rollback je zásah do produkce a pojistka navíc neškodí.
  4. Klikněte na Obnovit ze snapshotu.

Mazání snapshotů: U snapshot řádku klikněte na kebab menu (tři tečky) → Smazat. Staré snapshoty stojí místo na disku, takže je dobré je po čase čistit.

Alternativní klonování přes SSH

Staging funkce ve VPS Centru V3 pokrývá většinu běžných scénářů, ale existují situace, kdy budete chtít klonování vyřešit ručně přes SSH:

  • Vlastní konfigurace — web má specifickou strukturu, kterou UI nástroj nezvládne (symlinky, externí úložiště, custom CMS s atypickou konfigurací).
  • Automatizace přes skript — potřebujete klonování provádět pravidelně nebo jako součást CI/CD pipeline.
  • Klonování na jiný server — UI nástroj pracuje jen v rámci jednoho VPS. Pokud cíl leží jinde, SSH je jediná cesta.
  • Fallback pro výjimečné situace — funkce Správa verzí je aktuálně v beta režimu. Ve vzácných případech může UI nástroj selhat a SSH je pak bezpečná alternativa.

Postup přes SSH (zkrácená verze):

Použité placeholdery v příkazech níže: DOMENA = hlavní doména (např. saldova.cz), STAGE_NAME = název staging subdomény bez hlavní domény (např. staging pro subdoménu staging.saldova.cz), UZIVATEL_SUBDOMENY = systémový uživatel staging subdomény (zjistíte v kroku 7). Ve všech příkazech tyto placeholdery nahraďte reálnými hodnotami.

Krok 1 — Připojte se k serveru přes SSH

Přihlaste se na server jako root. Pokud s SSH teprve začínáte, podívejte se na článek
Jak se připojit na SSH pomocí WinSCP v nápovědě, případně na Kompletní průvodce SSH na blogu.

Krok 2 — Přidejte novou subdoménu ve VPS Centru

Ve VPS Centru otevřete Domény, klikněte na doménu, ke které chcete přidat subdoménu, a v Přehledu domény klikněte vpravo nahoře na tlačítko + Přidat subdoménu. Vytvořte subdoménu (například stage.example.cz). Tím se automaticky vytvoří webroot a doménový uživatel.

Krok 3 — Zkopírujte soubory

Přeneste soubory z webrootu produkce do webrootu nové subdomény příkazem rsync. Nahraďte DOMENA svou hlavní doménou (např. example.cz) a STAGE_NAME názvem staging subdomény bez domény (např. stage pro subdoménu stage.example.cz):

rsync -av /www/hosting/DOMENA/www/ /www/hosting/DOMENA/STAGE_NAME/

Přepínač -a zachová práva a časové značky, -v vypíše průběh. Lomítko na konci zdrojové cesty je důležité — kopíruje se obsah adresáře, ne samotný adresář.

Struktura webrootů ve VPS Centru V3: Subdomény se vytvářejí jako podadresáře hlavní domény. Například pro doménu example.cz jsou typické cesty: hlavní web v /www/hosting/example.cz/www/, staging v /www/hosting/example.cz/stage/, dev v /www/hosting/example.cz/dev/. Přesné cesty si ověřte ve VPS Centru v detailu domény v sekci Subdomény — každá subdoména má uvedený svůj webroot.

Krok 4 — Vytvořte novou databázi

Ve VPS Centru otevřete Databáze → Nová databáze. Poznamenejte si přístupové údaje hned při vytvoření — heslo nelze později v rozhraní zobrazit.

Krok 5 — Exportujte a naimportujte databázi

Nejprve vyexportujte produkční databázi do SQL souboru. Nahraďte STARY_NAZEV_DATABAZE názvem vaší produkční databáze:

mariadb-dump STARY_NAZEV_DATABAZE > /tmp/dump.sql

Poté obsah naimportujte do nové databáze — NOVY_NAZEV_DATABAZE je název databáze vytvořené v kroku 4:

mariadb NOVY_NAZEV_DATABAZE < /tmp/dump.sql

Krok 6 — Upravte připojení k databázi v konfiguraci webu

Kde se uloží přístupy k databázi, závisí na tom, jakou aplikaci provozujete:

  • WordPress — soubor wp-config.php v kořenovém adresáři (typicky /www/hosting/DOMENA/STAGE_NAME/wp-config.php), konstanty DB_NAME, DB_USER, DB_PASSWORD, DB_HOST.
  • PrestaShop — soubor app/config/parameters.php, klíče database_name, database_user, database_password, database_host.
  • Joomla — soubor configuration.php, proměnné $db, $user, $password, $host.
  • Laravel, Symfony a další PHP frameworky — obvykle soubor .env v kořenovém adresáři s proměnnými DB_DATABASE, DB_USERNAME, DB_PASSWORD, DB_HOST. Některé projekty mají přístupy ve config/database.php nebo v config/packages/doctrine.yaml.
  • Vlastní aplikace / custom build — zkontrolujte konfigurační soubor, který si projekt přinesl. Typicky to bývá .env, config.php, config.ini, settings.php nebo soubor v adresáři config/. Pokud má projekt verzovací systém, v git repozitáři najdete v .gitignore pravidla, která bývají dobrým vodítkem (konfigurační soubory s citlivými údaji se obvykle ignorují).

Ať už jde o jakýkoliv případ, přepište čtyři základní údaje z kroku 4 — název nové databáze, uživatelské jméno, heslo a (pokud se liší od localhost) hostname databázového serveru. Pokud si nejste jistí, kde se přístupy ukládají, kontaktujte vývojáře projektu nebo naši podporu.

Krok 7 — Nastavte správné vlastnictví souborů a zjistěte doménového uživatele

Soubory musí patřit doménovému uživateli staging subdomény. Tečky v názvu domény se v názvu uživatele nahrazují pomlčkou — pro stage.example.cz je uživatel stage-example-cz. Přesné jméno uživatele zjistíte v terminálu příkazem:

ls -la /www/hosting/DOMENA/STAGE_NAME/

Ve třetím sloupci výpisu je jméno uživatele — poznamenejte si ho, budete ho potřebovat v následujícím kroku. Pak spusťte:

chown -R UZIVATEL_SUBDOMENY:UZIVATEL_SUBDOMENY /www/hosting/DOMENA/STAGE_NAME/

Kde UZIVATEL_SUBDOMENY je systémový uživatel staging subdomény (z předchozího příkazu), DOMENA je hlavní doména a STAGE_NAME je název staging subdomény.

Krok 8 — Upravte URL v konfiguraci nebo databázi

Pokud má aplikace URL uloženou v databázi nebo konfiguraci, je potřeba ji přepsat na adresu staging subdomény. Jinak bude aplikace přesměrovávat na produkční doménu.

  • WordPress — hodnoty siteurl a home v tabulce wp_options. Upravit můžete přes phpMyAdmin, nebo přes WP-CLI. Pokud používáte WP-CLI, je potřeba ho spustit pod doménovým uživatelem staging subdomény (ne jako root — WP-CLI to explicitně zakazuje, protože by se případné vytvořené soubory staly vlastnictvím roota a PHP-FPM by k nim ztratilo přístup). UZIVATEL_SUBDOMENY jste si poznamenali v kroku 7:
su -s /bin/bash UZIVATEL_SUBDOMENY -c "wp --path=/www/hosting/DOMENA/STAGE_NAME option update siteurl https://stage.example.cz"
su -s /bin/bash UZIVATEL_SUBDOMENY -c "wp --path=/www/hosting/DOMENA/STAGE_NAME option update home https://stage.example.cz"

Přepínač –path říká WP-CLI, kde je WordPress nainstalovaný — bez něj by nástroj hledal instalaci v aktuálním adresáři. Přepínač -s /bin/bash je nutný proto, že doménový uživatel má v systému nastavený nologin shell (účet není určený k interaktivnímu přihlášení, jen pro běh PHP-FPM).

  • PrestaShop — hodnoty PS_SHOP_DOMAIN a PS_SHOP_DOMAIN_SSL v tabulce ps_configuration (prefix tabulky může být jiný).
  • Joomla — URL se obvykle řeší DNS záznamem, v konfiguraci se nemusí měnit; pokud je live_site v configuration.php vyplněné, přepište ho.
  • Laravel — proměnná APP_URL v souboru .env v kořenovém adresáři.
  • Symfony — obvykle v .env proměnná jako APP_BASE_URL nebo v config/packages/*.yaml.
  • Vlastní aplikace / custom build — záleží na implementaci. Pokud aplikace generuje odkazy dynamicky z hlavičky HTTP (např. $_SERVER[‚HTTP_HOST‘] v PHP), URL se přepisovat nemusí. Pokud má aplikace URL zadrátovanou v configu nebo v databázi, najděte odpovídající hodnotu a přepište ji. Dobrým indikátorem je, že se staging po otevření přesměrovává na produkční doménu — pak URL v configu/databázi je.

Detailní postup pro zálohu a obnovu databáze najdete v článku Jak zálohovat databáze.

VPS Centrum V2 — klonování souborů a databáze

VPS Centrum V2 nenabízí plnohodnotné staging prostředí s obousměrným workflow jako V3, ale má jednorázové klonovací nástroje pro soubory i databázi. Po klonování máte funkční kopii webu na subdoméně, ale nahrání změn zpět do produkce si musíte udělat ručně (kopírování souborů, import databáze).

Tip: Pokud plánujete staging používat pravidelně a plně využívat deployment workflow (Diff, Sync, Deploy, Rollback), zvažte upgrade na VPS Centrum V3. Nové funkce jsou součástí V3 a na V2 nejsou k dispozici. Kontaktujte podporu pro informace o přechodu.

Klonování ve V2 lze provést dvěma způsoby:

  • Klonovat web — kombinovaný nástroj, který v jednom kroku zkopíruje soubory i (volitelně) databázi. Doporučená cesta pro většinu případů.
  • Klonovat databázi samostatně — pokud potřebujete jen kopii databáze bez souborů (například pro testování SQL migrace).

Klonování webu (soubory + volitelně databáze)

  1. Ve VPS Centru V2 v pravém zeleném panelu vyberte z dropdownu doménu, jejíž web chcete klonovat.
  2. V menu pod dropdownem klikněte na FTP.
  3. V horní liště sekce FTP (vedle tlačítek Vytvořit Účet a Seznam Účtů) klikněte na Klonovat ftp.
  4. Otevře se obrazovka Klonovat web s formulářem:
    • Vyberte subdoménu ke klonování — z dropdownu vyberte zdrojovou subdoménu (obvykle www).
    • Vyberte kam chcete subdoménu naklonovat — máte dvě možnosti:
      • Zaškrtněte Vytvořit novou subdoménu a zadejte název nové subdomény (například staging). VPS Centrum ji vytvoří během klonování.
      • Nebo nechte checkbox prázdný a z dropdownu vyberte existující subdoménu, do které se má klon nahrát. Pozor: v tomto případě bude obsah cílové subdomény přepsán.
    • Klonovat db — zaškrtněte Klonovat db s ftp, pokud chcete v jednom kroku zkopírovat i databázi (vytvoří se nová databáze s kopií dat). Doporučujeme zaškrtnout — bez kopie databáze klon nebude plnohodnotně funkční (sdílel by databázi s produkcí).
  5. Klikněte na Klonovat.
VPS Centrum V2, formulář Klonovat web s vyplněnými údaji

Pozor: Pokud klonujete do existující subdomény (bez zaškrtnutí „Vytvořit novou subdoménu“), bude obsah cílové subdomény přepsán soubory ze zdroje. VPS Centrum přímo doporučuje: „Pokud vyberete doménu, která existuje, bude přepsána. Prosíme vymažte raději ručně obsah složky.“ Před klonováním tedy obsah cílové subdomény vymažte, nebo si ho zazálohujte.

Indikátor úspěchu: Po dokončení úlohy (VPS Centrum V2 akce zařazuje do fronty, dokončení může chvíli trvat) uvidíte v sekci Příkazy na zpracování stav hotovo. Soubory jsou ve webrootu cílové subdomény. Pokud jste zaškrtli klonování DB, v sekci Databáze se objeví nová databáze s přístupovými údaji.

Klonování samotné databáze

Pokud potřebujete jen kopii databáze bez souborů:

  1. V menu pravého panelu klikněte na Databáze.
  2. U databáze, kterou chcete klonovat, klikněte ve sloupci Nastavení na dropdown Nástroje a vyberte Klonovat.
  3. Vyplňte název nové databáze. VPS Centrum vytvoří kopii s obsahem zdrojové.
  4. Potvrďte klonování.

Indikátor úspěchu: V seznamu databází se objeví nová databáze s přístupovými údaji. Ty si poznamenejte, budete je potřebovat pro konfiguraci klonu.

Ruční úpravy po klonování

Na rozdíl od webhostingu a V3 nástroj neupravuje konfigurační soubory ani URL v databázi automaticky. Po klonování musíte ručně:

  1. Upravit konfigurační soubor webu (u WordPressu wp-config.php, u jiných CMS odpovídající soubor) — přepsat přístupové údaje na novou databázi. Detailní přehled míst, kde se přístupy ukládají u různých CMS a frameworků, najdete v sekci SSH Krok 6.
  2. U WordPressu upravit URL v databázi — hodnoty siteurl a home v tabulce wp_options. Jak upravit najdete v sekci Co udělat po vytvoření kopie.

Co udělat po vytvoření kopie

Ať už jste kopii vytvořili jakoukoliv cestou, po dokončení vás čekají ještě tři drobné kroky, aby byl staging plně funkční a nedošlo ke konfliktům s produkcí.

Zkontrolovat URL v databázi

U WordPressu jsou v databázi v tabulce wp_options dvě klíčové hodnoty — siteurl (URL administrace) a home (veřejná URL webu). Pokud zůstanou nastavené na produkční doménu, WordPress bude na stagingu přesměrovávat zpět na produkci.

Jak ověřit a upravit:

  • Webhosting (Zákaznický portál) a VPS Centrum V3 (Nová dev stage) — URL se u WordPressu upravují automaticky. Výjimka pro webhosting: pokud portál při klonování zobrazil varování, že nedetekoval konfigurační soubor, přístupové údaje k databázi ani URL se nepřepsaly — musíte je upravit ručně stejným způsobem jako u V2 (viz níže).
  • VPS Centrum V2 a SSH postup — upravte ručně přes phpMyAdmin (Databáze → phpMyAdmin), tabulka wp_options, řádky siteurl a home. Alternativně přes SSH s nástrojem WP-CLI — spustit je nutné pod doménovým uživatelem staging subdomény (WP-CLI nelze spustit jako root). Detailní postup s přesnými příkazy najdete v SSH Krok 8.

U jiných CMS, frameworků nebo custom buildů je místo uložení URL jiné — detailní přehled podle technologie (PrestaShop, Joomla, Laravel, Symfony, custom aplikace) najdete v SSH postupu výše v kroku „Upravte URL v konfiguraci nebo databázi“.

Aktivovat SSL certifikát pro subdoménu

Jestli nová subdoména získá SSL certifikát automaticky, nebo ho musíte aktivovat ručně, závisí na nastavení vaší hlavní domény:

  • Pokud máte zapnutou volbu „Automaticky vystavovat SSL certifikát na nově zjištěné subdomény“ (v detailu domény → SSL certifikáty → Https nastavení), VPS Centrum každou minutu kontroluje nové subdomény a změny v DNS. Jakmile detekuje, že staging subdoména existuje a směřuje na správnou IP, vystaví certifikát automaticky — nemusíte nic dělat.
  • Pokud automatické vystavení nemáte zapnuté, musíte certifikát aktivovat ručně.

Kompletní postup aktivace SSL na všech rozhraních (včetně toho, jak zapnout automatické vystavení) najdete v článku Jak aktivovat SSL certifikát a zapnout HTTPS.

Důležité: Před aktivací SSL (ručně i automaticky) se ujistěte, že subdoména správně směřuje na server (A záznam v DNS). Bez toho certifikát nevystavíte. Dialog Https nastavení ve V3 vám případné problémy s DNS přímo vypíše — například „Subdoména stage směřuje na IP 185.66.36.11, ale měla by směřovat na IP 37.235.108.159″.

Zabránit duplicitním procesům

Pokud má produkční web nastavené cron úlohy (pravidelné odesílání e-mailů, generování reportů, synchronizace s externími službami, WordPress WP-Cron), na stagingu poběží souběžně s produkcí. To může způsobit duplicitní e-maily zákazníkům, dvojí volání API, konflikty v externích systémech.

Jak to ošetřit:

  • Cron úlohy ve VPS Centru — v sekci Crony u staging domény smažte nebo deaktivujte úlohy, které nechcete duplikovat. U VPS Centra V3 má každá doména vlastní cron úlohy, takže cron na staging doméně neovlivní produkci (a naopak).
  • WordPress WP-Cron — pokud máte WP-Cron nahrazený systémovým cronem (doporučený přístup pro produkci, viz článek Snížení zátěže CPU úpravou WP-Cronu), ujistěte se, že na stagingu neběží další systémový cron pro WP-Cron.
  • API integrace — pokud web komunikuje s externí službou (platební brána, účetní systém, ERP), na stagingu použijte testovací/sandbox údaje, nikdy ne produkční API klíče. Jinak se mohou vytvořit duplicitní transakce.

Řešení problémů

Staging subdomény se nezobrazuje

Symptom: Po vytvoření staging prostředí se subdoména neotevře — v prohlížeči chyba This site can’t be reached nebo DNS_PROBE_FINISHED_NXDOMAIN.

Příčina: DNS záznam subdomény zatím nestihl zpropagovat, nebo nebyl vytvořen.

Řešení: Počkejte 5–15 minut a zkuste znovu. Pokud problém trvá, ověřte ve VPS Centru, že subdoména má A záznam směřující na IP serveru (Domény → doména → DNS). U VPS Centra V3 se subdoména vytváří s DNS záznamy automaticky; u SSH postupu si A záznam musíte přidat sami.

Vytvoření stagingu nebo Deploy selhal u WordPressu

Symptom: Při vytváření staging prostředí nebo při Deploy do produkce se operace nedokončí a zobrazí se chybová hláška (např. 500 Internal Server Error nebo jiná chyba vrácená z interního endpointu).

Příčina: Nejčastější příčinou u WordPress webů je nedokončená instalace — WordPress je na serveru nasazený, ale neproběhlo dokončení přes webový průvodce (vytvoření admin účtu, nastavení názvu webu, připojení databáze). Funkce Správa verzí u WordPressu očekává plně funkční instalaci včetně přístupu do databáze a kompletního nastavení v tabulce wp_options.

Řešení:

  1. Dokončete instalaci WordPressu — otevřete produkční web v prohlížeči a projděte WordPress instalační průvodce (zadání názvu webu, vytvoření admin účtu a hesla, nastavení e-mailu administrátora).
  2. Ověřte, že se na produkci lze přihlásit do administrace (wp-admin) a že web běžně funguje.
  3. Zkuste staging operaci znovu.
  4. Pokud problém přetrvává i po dokončené instalaci, funkce je v beta režimu — nahrajte změny přes SSH postupem v sekci Alternativní klonování přes SSH a nahlaste chybu podpoře.

Po otevření stagingu se zobrazuje produkční URL

Symptom: Subdoména stage.example.cz se otevře, ale prohlížeč okamžitě přesměruje na produkční example.cz. Nebo se na stagingu zobrazují odkazy vedoucí na produkci.

Příčina: URL v databázi (u WordPressu siteurl a home) zůstaly nastavené na produkční doménu.

Řešení: Upravte URL v databázi přes phpMyAdmin (tabulka wp_options, řádky siteurl a home) nebo přes SSH pomocí WP-CLI. Konkrétní příkazy (spuštěné pod doménovým uživatelem) najdete v SSH Krok 8.

Pokud používáte webhosting nebo VPS Centrum V3 Nová dev stage, tato úprava by měla proběhnout automaticky — pokud se tak nestalo, je to chyba, kterou doporučujeme nahlásit podpoře.

Cron úlohy běží souběžně na stagingu i v produkci

Symptom: Zákazníci dostávají duplicitní e-maily, externí integrace vrací chyby „duplicate transaction“, logy ukazují dvojí volání stejného endpointu.

Příčina: Cron úlohy se zkopírovaly z produkce na staging a nyní běží na obou místech současně.

Řešení: Ve VPS Centru u staging domény otevřete sekci Crony a deaktivujte nebo smažte úlohy, které nechcete duplikovat. Pokud má web integraci na externí systémy (platby, účetnictví), použijte na stagingu testovací/sandbox přístupové údaje.

SSL certifikát na subdoméně chybí

Symptom: Při otevření subdomény přes HTTPS prohlížeč zobrazí chybu certifikátu (NET::ERR_CERT_AUTHORITY_INVALID) nebo WordPress přesměruje na produkci, protože v databázi má nastavenou HTTPS URL, která bez certifikátu nefunguje.

Příčina: Možností je několik:

  1. Automatické vystavení není zapnuté — pokud nemáte v nastavení domény zaškrtnutou volbu „Automaticky vystavovat SSL certifikát na nově zjištěné subdomény“, certifikát se musí aktivovat ručně.
  2. DNS subdomény nesměřuje na správnou IP — automatické i ruční vystavení vyžaduje, aby A záznam subdomény ukazoval na IP serveru. Pokud subdoména směřuje jinam, certifikát nelze vystavit.
  3. DNS se ještě nepropagoval — pokud byla subdoména právě vytvořená, DNS může propagovat až několik desítek minut.

Řešení:

Po opravě DNS počkejte několik minut a aktivujte certifikát (pokud máte zapnuté automatické vystavení, vystaví se sám). Detailní postup najdete v článku Jak aktivovat SSL certifikát a zapnout HTTPS.

Otevřete v detailu domény sekci SSL certifikáty a klikněte na Https nastavení. Dialog vypíše konkrétní problém — například „Subdoména stage směřuje na IP 185.66.36.11, ale měla by směřovat na IP 37.235.108.159″. Podle toho upravte DNS záznam.


Pokud problém přetrvává nebo narazíte na situaci, kterou zde nepopisujeme, kontaktujte naši podporu — rádi vám pomůžeme. U funkce Správa verzí v beta režimu nám případně pomůžete s reportem chyby, kterou můžeme opravit.


Staging prostředí je jeden z nástrojů, který odlišuje profesionální správu webu od amatérské — umožní vám testovat změny bez rizika výpadku produkce. Pokud správu serveru raději přenecháte nám, podívejte se na naše Managed servery. Kompletní správu včetně staging workflow, nasazení změn a monitoringu řešíme za vás.

Pomohl vám tento článek?

Podobné články