Hetzner je dlouhodobě oblíbenou volbou pro cenově dostupný evropský hosting, ale nehodí se pro každou firmu. Pokud vám účet někdy bez varování označili, měli jste potíže získat fakturaci ve vašem jazyce, nebo prostě chcete poskytovatele blíže středoevropskému a východoevropskému trhu, tento průvodce vás provede migrací vašeho VPS nebo dedikovaného serveru na MMITech s minimálním výpadkem.

Za poslední rok jsme pomohli desítkám zákazníků přejít z Hetzneru. Postup je přímočarý, pokud dodržíte správné pořadí, a většinu zátěží lze přepnout za méně než hodinu skutečné nedostupnosti.

Kdy má migrace z Hetzneru smysl

Hetzner je schopný poskytovatel. Migrace stojí za váš čas, pokud platí jedno či více z následujícího:

  • Zažili jste náhlé pozastavení účtu nebo zadržení, často spuštěné automatickou detekcí zneužití na sdílených podsítích.
  • Potřebujete fakturaci ve slovinštině, chorvatštině, češtině nebo maďarštině, případně daňovou dokumentaci odpovídající vašim místním účetním požadavkům.
  • Vaši zákazníci jsou v regionu střední a východní Evropy a latence k Falkensteinu nebo Helsinkám poškozuje výkon.
  • Chcete podporu ve vlastním časovém pásmu s odezvou v minutách, ne v pracovních dnech.
  • Potřebujete blokové nebo objektové úložiště se stejnou redundancí postavenou na Cephu bez placení samostatných doplňků.
  • Konsolidujete více poskytovatelů a chcete jediný fakturační vztah pro VPS, dedikované servery, Nextcloud úložiště a domény.

Pokud se nic z toho netýká vás, zůstat je platná volba. Pokud platí byť jen jedno, čtěte dál.

Kontrolní seznam před migrací

Než cokoliv objednáte na naší straně, zdokumentujte, co máte na Hetzneru. Hodina strávená zde ušetří čtyři hodiny později.

  1. Zinventarizujte všechny služby běžící na serveru. Webový server, databáze, cron úlohy, mail, fronty zpráv, on-prem workery, monitorovací agenty, koncové body VPN. Jednoduchý systemctl list-units --type=service --state=running je dobrý začátek.
  2. Vypište všechny domény a DNS záznamy. Poznamenejte si aktuální TTL a kde je DNS hostován. Pokud je DNS v Hetzner Console, budete muset migrovat i ten nebo jej nejprve přesunout k třetí straně, jako je Cloudflare.
  3. Zdokumentujte velikosti a typy databází. MySQL, MariaDB, PostgreSQL, Redis, MongoDB. Poznamenejte si verze, protože povýšení verzí během migrace násobí riziko.
  4. Poznamenejte si všechny otevřené porty firewallu a všechna pravidla Hetzner Cloud Firewall. Tato se nemigrují automaticky.
  5. Identifikujte externí služby, které mají vaši aktuální IP na seznamu povolených. Platební brány, SMTP relaye, partneři přes API, monitorovací služby. Každou bude potřeba po přepnutí aktualizovat.
  6. Zkontrolujte zdroje SSL certifikátů. Let's Encrypt certifikáty se snadno znovu generují. Placené certifikáty mohou být svázány s aktuální IP nebo hostname.
  7. Před začátkem vytvořte zálohu. Pořiďte úplný snapshot nebo export. Pokud se během migrace něco pokazí, máte známý dobrý bod obnovy.

Krok 1: Objednání MMITech VPS

Objednejte si VPS, který odpovídá nebo mírně překračuje vaše aktuální specifikace na Hetzneru. Pokud používáte řadu Hetzner CX nebo CCX, naše plány Cloud VPS se čistě mapují na stejný profil RAM a CPU. Pokud provozujete CPU intenzivní zátěže jako kompilaci, kódování videa nebo velké databáze, řada AMD VPS nabízí výrazně lepší jednovláknový výkon na jádrech Ryzen.

Zvolte stejnou verzi operačního systému, kterou používáte na Hetzneru. Migrace z Ubuntu 22.04 na Ubuntu 22.04 je přímočará. Přechod mezi hlavními verzemi během migrace hostitele je recept na překvapení. Vyřešte to jako samostatný projekt.

Po nasazení dokončete základní hardening, než cokoliv zkopírujete:

# Aktualizace systému
apt update && apt upgrade -y

# Vytvoření ne-root uživatele
adduser deploy
usermod -aG sudo deploy

# Zkopírování SSH klíče
mkdir -p /home/deploy/.ssh
cp ~/.ssh/authorized_keys /home/deploy/.ssh/
chown -R deploy:deploy /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

# Zakázání root SSH a autentizace heslem
sed -i 's/^#PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sed -i 's/^#PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart ssh

Krok 2: Snižte DNS TTL před migrací

Tento krok většina lidí přeskočí a později ho lituje. Nejméně 24 až 48 hodin před přepnutím snižte TTL u každého DNS záznamu, který budete měnit.

Pokud vaše záznamy mají aktuálně TTL 3600 nebo 14400 sekund, snižte je na 300. Tak se při přepnutí DNS propagace dokončí během 5 minut místo 4 hodin. Po ověření migrace TTL vraťte zpět na 3600.

Pokud je váš DNS v Hetzner Console a plánujete ho přesunout, udělejte to nyní. Přesuňte DNS na Cloudflare nebo jiného poskytovatele, dokud stále ukazuje na IP Hetzneru. Tím máte v čase přepnutí o jednu proměnnou méně.

Krok 3: Počáteční synchronizace dat

Pro většinu serverů je rsync přes SSH správným nástrojem. Trik spočívá ve dvou průchodech: první průchod při běžícím zdroji, pak finální delta synchronizace po zastavení služeb při přepnutí.

Z vašeho nového MMITech VPS stáhněte data z Hetzneru:

# Synchronizace webových rootů
rsync -avz --progress \
  -e "ssh -i /root/.ssh/id_ed25519" \
  root@stara-hetzner-ip:/var/www/ \
  /var/www/

# Synchronizace aplikačních adresářů
rsync -avz --progress \
  -e "ssh -i /root/.ssh/id_ed25519" \
  root@stara-hetzner-ip:/opt/ \
  /opt/

# Synchronizace domovských adresářů
rsync -avz --progress \
  -e "ssh -i /root/.ssh/id_ed25519" \
  root@stara-hetzner-ip:/home/ \
  /home/

# Synchronizace konfigurací
rsync -avz --progress \
  -e "ssh -i /root/.ssh/id_ed25519" \
  root@stara-hetzner-ip:/etc/ \
  /etc/hetzner-backup/

/etc/ stáhněte do samostatného adresáře, nepřepisujte svou čerstvou instalaci. Budete ho používat jako referenci pro konfigurace služeb, ne jako podklad ke slepému kopírování.

U Docker hostitelů synchronizujte /var/lib/docker/volumes/ a své compose soubory. Nezkoušejte kopírovat /var/lib/docker/ jako celek, ta cesta není bezpečně přenositelná.

Krok 4: Správně migrujte databáze

Databáze vyžadují přístup dump-a-obnova, ne kopírování souborů. Kopírování surových databázových souborů mezi běžícími instancemi vede k poškození dat častěji než ne.

Pro MariaDB nebo MySQL:

# Na starém Hetzner serveru
mysqldump --all-databases \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  --events \
  | gzip > /tmp/full-dump.sql.gz

# Přenos
scp /tmp/full-dump.sql.gz root@nova-mmitech-ip:/tmp/

# Na novém MMITech serveru
zcat /tmp/full-dump.sql.gz | mysql

Pro PostgreSQL:

# Na Hetzneru
pg_dumpall -U postgres | gzip > /tmp/pg-dump.sql.gz

# Na MMITech
zcat /tmp/pg-dump.sql.gz | psql -U postgres

Testovací dump a obnovu proveďte s dostatečným předstihem před přepnutím. Ověřte, že nový server čistě nastartuje aplikace nad obnovenými daty. Chyby kvůli nesouladu verzí řešte teď, ne při přepnutí ve 2 ráno.

Krok 5: Přeinstalujte a nakonfigurujte služby

Nekopírujte binárky ani systemd unity doslova z Hetzner serveru. Služby nainstalujte na MMITech čerstvě, pak na ně nasaďte své konfigurace.

Typické pořadí přeinstalace:

# Webový server
apt install -y nginx

# PHP, pokud je potřeba
apt install -y php-fpm php-mysql php-redis php-curl php-gd \
               php-imagick php-mbstring php-xml php-zip

# Klientské nástroje pro databáze (servery už v kroku 4)
apt install -y mariadb-client redis-tools

Pak zkopírujte konkrétní konfigurační soubory z adresáře /etc/hetzner-backup/:

cp /etc/hetzner-backup/nginx/sites-available/* /etc/nginx/sites-available/
cp /etc/hetzner-backup/php/8.2/fpm/pool.d/* /etc/php/8.2/fpm/pool.d/

# Před povolením otestujte
nginx -t

Tento přístup zachytí předpoklady specifické pro Hetzner ve vašich starých konfiguracích, jako jsou natvrdo zapsaná rozhraní privátní sítě nebo odkazy na metadata service Hetzner Cloud, dříve než něco rozbijí.

Krok 6: Finální synchronizace a přepnutí

Přepnutí naplánujte na okno s nízkým provozem. Pro většinu evropských firem je to mezi 23:00 a 5:00 SEČ.

Pořadí přepnutí:

  1. Na Hetzner server umístěte stránku údržby nebo v aplikaci aktivujte režim jen pro čtení.
  2. Na Hetzneru zastavte zápisově náročné služby: webový server, aplikační workery, cron.
  3. Z MMITech spusťte finální rsync delta a stáhněte všechny změny od počáteční synchronizace.
  4. Vytvořte finální dump databáze a obnovte ho na MMITech.
  5. Na MMITech nastartujte služby a proveďte smoke test přímo proti nové IP (použijte curl --resolve nebo upravte lokální hosts soubor).
  6. Ověřte, že SSL certifikáty jsou platné. Po propagaci DNS v případě potřeby znovu vystavte Let's Encrypt certifikáty s novou IP.
  7. Přepněte DNS záznamy A a AAAA na novou MMITech IP.
  8. Sledujte logy na obou serverech. Provoz na Hetzneru by měl během 5 až 30 minut klesnout na nulu s expirací cache.

Krok 7: Ověření po migraci

Hetzner zatím nevyřazujte. Nechte ho v režimu jen pro čtení nebo vypnutý alespoň 7 dní. Získáte tím možnost rychlého rollbacku a čas na zachycení problémů.

V prvních 24 hodinách ověřte tyto položky:

  • Všechny weby se správně načítají s platným SSL.
  • Doručování e-mailů funguje oběma směry. Pokud si hostujete poštu sami, znovu prověřte SPF, DKIM a DMARC.
  • Cron úlohy běží. Zkontrolujte logy v očekávaných časech.
  • Aplikační logy nevykazují opakující se chyby.
  • Externí služby používající allowlist podle IP jsou aktualizované.
  • Monitorovací agenty hlásí z nového serveru.
  • Zálohy běží na novém serveru.

Po 7 dnech čistého provozu můžete Hetzner server bezpečně zrušit. U případného zbývajícího předplaceného zůstatku vám pomůžeme finálním vyúčtováním na naší straně.

Časté úskalí při migraci z Hetzneru

Privátní sítě Hetzner Cloud na nové straně neexistují. Pokud vaše aplikace používají adresy 10.x.x.x pro komunikaci mezi servery, budete na MMITech muset nastavit ekvivalentní privátní síť nebo VPN konektivitu. Pro vícestrojové sestavy podporujeme privátní VLAN.

rDNS není automatický. Reverzní DNS pro servery odesílající poštu je potřeba nastavit na naší straně přes požadavek na podporu. Udělejte to dřív, než přepnete poštu.

Cloud-init metadata jsou specifická pro poskytovatele. Vše spoléhající na Hetznerův metadata service tiše selže. V kódu vyhledejte odkazy na 169.254.169.254.

Cesty k Hetzner Storage Boxu přestávají fungovat. Pokud připojujete Hetzner Storage Box pro zálohy, nastavte alternativní úložiště pro zálohy. Nabízíme dedikovaný prostor pro zálohy kompatibilní s Proxmox Backup Serverem.

Často kladené otázky

Jak dlouho obvykle trvá migrace z Hetzneru na MMITech?

Pro jednotlivý VPS se standardní LAMP nebo LEMP aplikací a méně než 50 GB dat počítejte s 2 až 4 hodinami přípravy a 30 až 60 minutami skutečné nedostupnosti. Větší databáze nebo složitější sestavy s více službami potřebují úměrně více plánování.

Může MMITech pomoci s migrací?

Ano. Zákazníkům objednávajícím VPS nebo dedikované plány nabízíme pomoc s migrací. Před začátkem se obraťte na náš tým, naplánujeme okno migrace, poradíme s dimenzováním a pomůžeme s přepnutím.

Přijdu během migrace o data?

Pokud dodržíte přístup dump-a-obnova pro databáze a při přepnutí provedete finální rsync, ne. Rizikové okno je několik minut mezi finální synchronizací a propagací DNS, proto je předem snížené TTL důležité.

Musím migrovat všechny služby najednou?

Ne. Mnoho zákazníků migruje zátěž po zátěži. Nejprve přesuňte vývojový VPS, ověřte zkušenost a pak přesuňte produkci. To je také správný postup, pokud konsolidujete z více Hetzner serverů.

A co mé domény registrované u Hetzneru?

Převody domén jsou oddělené od migrace serveru. Jakmile vaše služby běží na MMITech, můžete domény kdykoliv převést k nám. Podporujeme většinu TLD přes naši službu převodu domén.

Připraveni migrovat?

Pokud jste dočetli až sem, máte jasný obrázek o tom, co migrace obnáší. Naši infrastrukturu jsme postavili na enterprise Ceph úložišti, redundantní 40GbE síti a datacentru umístěném v EU (Slovinsko) přesně pro zákazníky, kteří potřebují spolehlivost bez korporátní zátěže velkých poskytovatelů.

Objednejte si Cloud VPS nebo AMD VPS a ozvěte se našemu týmu, pokud chcete pomoci s plánováním přepnutí. Odpovíme ve vašem jazyce, ve vašem časovém pásmu, a budeme tytéž lidi, s nimiž budete mluvit i příští měsíc, až budete potřebovat něco dalšího.

Byla tato odpověď nápomocná? 0 Uživatelům pomohlo (0 Hlasů)