Starta Hetzner Rescue System - steg-för-steg-guide för serveradministratörer

Jag kommer att visa dig hur du startar Hetzners räddningssystem på bara några minuter, hur du SSH logga in och ange din Server reparation på ett målinriktat sätt. Den här guiden tar dig steg för steg från aktivering till återställning, inklusive filsystemkontroller, säkerhetskopiering och ominstallation.

Centrala punkter

Följande viktiga aspekter kommer att hjälpa dig att starta och arbeta i räddningsläge utan några omvägar.

• Start av räddningsinsatsAktivering i Robot eller Cloud, sedan omstart.
• SSH-åtkomstLogga in med nyckel eller lösenord och root-rättigheter.
• FelanalysKolla fsck, loggar, partitioner.
• Säkerhetskopiering av data: rsync, tar, scp för snabb säkerhetskopiering.
• Ny installationinstallimage för nya system.

Vad räddningssystemet gör

Rescue System laddar in en oberoende Linux-miljö i arbetsminnet och ger mig omedelbar tillgång till Rot-åtkomst, även om den installerade Operativsystem misslyckas. Jag startar oberoende av defekta startladdare, skadade paket eller felaktiga konfigurationer. Detta gör att jag kan kontrollera filsystem, återställa data, analysera loggar och starta om tjänster. Miljön förblir slimmad, men erbjuder alla viktiga verktyg för diagnostik och återställning. Det gör att jag kan behålla kontrollen även om det ordinarie systemet skulle gå ner helt.

Det som är praktiskt är att räddningsmiljön är avsiktligt flyktig: förändringar försvinner efter omstarten, vilket innebär att jag kan testa på ett säkert sätt. Om det behövs installerar jag tillfälliga verktyg (t.ex. smartmontools, mdadm, lvm2, btrfs-progs eller xfsprogs) utan att ändra det produktiva systemet. Kärnversionen är modern och stöder den senaste hårdvaran, inklusive NVMe, UEFI, GPT, mjukvaru-RAID (mdraid), LVM och LUKS-kryptering. Detta gör att jag kan täcka även komplexa lagringsinställningar och isolera även sällsynta felmönster på ett reproducerbart sätt.

Krav och tillgång

För att komma igång behöver jag tillgång till kundgränssnittet och min SSH-nycklar eller en tillfällig Lösenord. Jag hanterar dedikerade system bekvämt via Hetzner Robotmedan jag styr instanser i molnet via konsolen. Båda gränssnitten erbjuder ett tydligt alternativ för att aktivera räddningsläget. Jag kontrollerar korrekt server-IP, IPv6-tillgänglighet och, om nödvändigt, out-of-band-funktioner för återställningen i förväg. Denna förberedelse förkortar driftstoppstiden avsevärt.

När jag loggar in i SSH för första gången bekräftar jag medvetet det nya fingeravtrycket och uppdaterar min Known Hosts-post om det behövs så att efterföljande anslutningar inte misslyckas på grund av varningar. För team lagrar jag ytterligare nycklar specifikt för räddningsoperationen och tar bort dem igen efter slutförandet. Om endast ett tillfälligt lösenord finns tillgängligt ändrar jag det omedelbart efter inloggningen och ersätter det sedan med Key-Auth - jag avaktiverar konsekvent lösenordsinloggningar när arbetet är slutfört.

Aktivering av räddningssystemet - steg för steg

Jag öppnar serverns detaljfönster, väljer alternativet "Rescue" och ställer in arkitekturen till linux64 för aktuella system, sedan sätter jag in min SSH-nyckel. Beroende på situationen startar jag bara räddningsläget och utlöser omstarten separat eller så använder jag "Activate Rescue & Power Cycle" för en direkt omstart. Om maskinen hänger sig utför jag en hård återställning via gränssnittet. Efter uppstarten visar gränssnittet ett tillfälligt root-lösenord om jag inte har angett någon nyckel. Så fort servern startar upp svarar den på SSH och jag kan komma igång.

I komplexa situationer planerar jag en tydlig sekvens: Aktivera, strömavbrott, testa SSH-inloggning och börja sedan felsöka. En manuell strömcykel kan vara mer nödvändig på dedikerade servrar, medan molninstanser vanligtvis växlar till räddningsläge omedelbart. Viktigt: Efter en lyckad reparation stänger jag av räddningsläget igen så att maskinen startar om från den lokala hårddisken.

SSH-anslutning och första kontroller

Jag ansluter via SSH med ssh root@ och kontrollera först nätverket, databärare och loggar för att få en snabb överblick över Status. Med ip a och ping Jag kontrollerar tillgängligheten; journalctl --no-pager -xb eller loggfiler på de monterade diskarna visar de senaste felmeddelandena. Kommandona lsblk, blkid och fdisk -l ge klarhet om layout och filsystem. För RAID använder jag cat /proc/mdstat och mdadm --detalj för tillståndet. För initiala hårdvaruindikatorer smartctl -a och en kort hdparm -Tt-test.

LVM, RAID, LUKS och speciella filsystem

Många servrar använder LVM, mjukvaru-RAID eller kryptering. Jag aktiverar först alla relevanta lager:

• mdraid: mdadm --montera --skanna tar fram befintliga matriser; jag kontrollerar statusen med cat /proc/mdstat.
• LUKS: Jag öppnar krypterade volymer med cryptsetup luksOpen /dev/.
• LVMMed vgscan och vgchange -ay Jag aktiverar volymgrupper och ser dem via lvs/vgs/pvs.

Med Btrfs är jag uppmärksam på undervolymer och monterar specifikt med -o subvol=@ respektive -o subvolid=5 för den översta nivån. Jag kontrollerar XFS med xfs_repair (aldrig på monterade volymer), medan Ext4 klassiskt används med fsck.ext4 -f är omorganiserad. Jag orienterar mig på GUID/UUID från blkideftersom enhetsnamn för NVMe (/dev/nvme0n1p1) och kan variera vid ändring av order. Jag kommer att korrigera /etc/fstab.

Reparation av filsystem och säkerhetskopiering av data

Innan jag reparerar säkerhetskopierar jag viktiga Uppgifter med rsync, scp eller . tjära till ett externt mål eller ett lokalt mål Säkerhetskopiering-katalogen. För kontroller använder jag fsck endast på omonterade partitioner, t.ex. fsck -f /dev/sda2för att korrigera inkonsekvenser på ett snyggt sätt. Jag monterar sedan systemet under /mnttill exempel med montera /dev/sda2 /mntoch bifoga undervägar som t.ex. /proc, /sys och /dev när jag vill göra en chroot. Enskilda konfigurationsfiler som t.ex. /etc/fstab eller nätverksinställningar direkt i det monterade systemet. Genom att gå försiktigt tillväga förhindrar jag följdskador och minimerar stilleståndstiden.

För pålitliga säkerhetskopior förlitar jag mig på repeterbara kommandon: rsync -aHAX --info=progress2 får rättigheter, hårda länkar, ACL och xattrs. Om linjen är svag stryper jag med --bwlimit och parallellisera komprimeringen med tar -I pigz. Vid behov avbildar jag kritiska, felaktiga databärare i block med ddräddning för att flytta det logiska arbetet till en image. Jag kontrollerar noggrant Btrfs-system med btrfs kontrollera --läsa endast och använda btrfs-skrubbaför att upptäcka tysta fel. XFS kräver ofta en reparation utanför monteringen i händelse av inkonsekvenser (xfs_repair) - Jag säkerhetskopierar alltid partitionen först.

Reparation av UEFI/BIOS, GPT/MBR och bootloader

Många startproblem orsakas av samspelet mellan firmware, partitionsschema och startladdare. Först klargör jag om servern startar i UEFI- eller legacy BIOS-läge (ls /sys/firmware/efi). Med UEFI monterar jag EFI-partitionen (typiskt /dev/sdX1 eller . /dev/nvme0n1p1) till /mnt/boot/efi. Sedan chrootear jag in i systemet:

Montera /dev/ /mnt
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

Jag installerar om bootloader på lämpligt sätt (grub-installation till rätt enhet) och återskapa konfiguration och initramfs: uppdatera-grub och uppdatera-initramfs -u -k alla (för Dracut-baserade system dracut -f). Om ordningen på enheterna inte är korrekt använder jag /etc/default/grub UUID:er och kontroll /etc/fstab för korrekta poster. När jag ändrar GPT/MBR kontrollerar jag om det finns en BIOS-startpartition (för GRUB/BIOS) eller en giltig EFI-systempartition.

Fallgropar i nätverket i Rescue

Nätverksproblem är ofta orsaken till att tjänster är "borta". I Rescue kontrollerar jag länkstatusen (ip-länk), rutter (ip r) och DNS-resolution (resolvectl status resp. cat /etc/resolv.conf). Jag testar IPv4 och IPv6 separat (ping -4/ping -6). För servrar med bryggor eller bonding kan ordningen på gränssnitten i det produktiva systemet skilja sig från räddningsmiljön. Jag antecknar MAC-adresserna och mappar dem korrekt. Om produktionssystemet använder Netplan verifierar jag /etc/netplan/*.yaml och vända efter chroot netplan generera och netplan tillämpas på. För klassiska /etc/nätverk/gränssnitt-uppsättningar är jag uppmärksam på konsekventa gränssnittsnamn (förutsägbara namn vs. eth0).

Installera om operativsystemet

Om reparationerna inte längre är meningsfulla återställer jag systemet med Installimage helt nya och därmed spara värdefulla Tid. Verktyget guidar mig genom valet av distribution, partitionering och startladdare. Jag inkluderar mina egna konfigurationsfiler och SSH-nycklar i installationen så att den första uppstarten går smidigt. Efter installationen startar jag servern som vanligt och kontrollerar tjänster, brandvägg och uppdateringar. Slutligen tar jag bort räddningsläget så att nästa uppstart sker från den lokala databäraren igen.

Jag använder medvetet UUID-baserade mounts för nya installationer för att utesluta problem med enhetsordning senare. För RAID-installationer skapar jag matriserna från början och kontrollerar ombyggnadsstatusen innan jag återställer data. Om du distribuerar liknande system på återkommande basis arbetar du med fördefinierade installationsmallar och en tydlig partitioneringslogik (rot, separat datapartition, swap, EFI vid behov). Efter den första uppstarten uppdaterar jag paketkällor och kärnor, aktiverar automatiska säkerhetsuppdateringar och genomför mina grundläggande härdningssteg.

Säkerhet, tidsfönster och återfall

Tillträde sker uteslutande via SSHdärför förlitar jag mig konsekvent på Nycklar i stället för statiska lösenord. Räddningsläget förblir redo under en begränsad tid efter aktivering och faller tillbaka till den lokala startenheten vid nästa normala omstart. Jag arbetar snabbt, dokumenterar varje steg och håller en andra session öppen för större ingrepp. Jag skriver inte känsliga data i bash-historiken och raderar temporära filer efter användning. Efter en lyckad återställning avaktiverar jag läget i gränssnittet igen.

Efter att ha återaktiverat det produktiva systemet roterar jag åtkomstdata, tar bort tillfälliga räddningsnycklar, återställer överflödiga root-lösenord och säkerhetskopierar nygenererade konfigurationer. Jag samlar in revisionsinformation (vem som gjorde vad och när) och dokumenterar avvikelser från standardkonfigurationen. Detta förhindrar att nödåtgärder blir permanenta och jag uppfyller kraven på efterlevnad.

Exempel: Rädda WordPress-servern

Jag startar i räddningsläge, monterar systempartitionen och säkerhetskopierar Databas per mysqldump och wp-innehåll-katalogen med tjära eller . rsync. Därefter kontrollerar jag filsystemet, återställer startladdaren och korrigerar felaktiga PHP- eller NGINX-konfigurationer. Om paket är skadade använder jag chroot och installerar om beroenden. Om det inte är tillräckligt återställer jag maskinen med Installimage och återställer säkerhetskopian och konfigurationerna. Slutligen verifierar jag frontend, inloggning och cronjobs.

I praktiken är jag uppmärksam på InnoDB-konsistens (MySQL / MariaDB): misslyckas mysqld i början, jag säkrar /var/lib/mysql och kör dumpningen från en ny instans. Jag tömmer cacheminnen (objektcache, sidcache, OPCache) selektivt, ställer in filbehörigheter konsekvent (hitta . -typ d -exec chmod 755 {} ;, hitta . -typ f -exec chmod 644 {} ;) och kontrollera öppen_basedir och uppladdningskataloger. Jag avaktiverar kritiska plugins som ett test genom att byta namn på plugin-katalogen. Jag kontrollerar sedan PHP FPM-pooler, FastCGI-timeouts, minnesgränser och NGINX/Apache-inkluderingar. En kort wp cron händelse kör --due-now (om WP-CLI är tillgängligt) hjälper till att bearbeta eftersläpningar.

Bästa praxis för administratörer

Innan jag gör djupa ingrepp skapar jag en ny Säkerhetskopiering och säkra nyckelfiler som t.ex. /etcså att jag kan hoppa tillbaka när som helst. Varje steg registreras i en kort logg, vilket hjälper mig senare vid revisioner eller nya incidenter. När jag har startat om i det produktiva systemet kontrollerar jag noggrant tjänster, loggar, nätverk och övervakning. För återkommande uppgifter bygger jag upp en liten skriptuppsättning för att standardisera kommandosekvenser. Om du planerar ytterligare prestanda eller ny hårdvara kan du skapa lämpliga Hyr en root-server och migreringsfönstret.

Jag har också en checklista för runbook som innehåller ansvarsområden och eskaleringsvägar. Planerade "speldagar" (riktade felsimuleringar) tränar teamet för nödsituationer. Jag testar regelbundet säkerhetskopior som ett återställningsexempel - en otestad säkerhetskopia anses vara obefintlig. Och jag versionerar mina systemkonfigurationer så att jag snabbt kan känna igen skillnaderna mellan "bra" och "felaktig" status.

Moln vs. dedikerad: skillnader i processen

I molnet ändrar jag ofta startläget direkt i instansdialogen och använder den seriella konsolen för snabba kontroller, medan en strömcykel och eventuellt åtkomst utanför bandet är nödvändigt på dedikerade servrar. Molnvolymer kan enkelt kopplas till andra instanser - ett effektivt sätt att säkerhetskopiera data utan driftstopp på den drabbade värden. På bare metal är jag mer uppmärksam på den fysiska ordningen på enheterna, särskilt när jag köper ytterligare SSD/NVMe-moduler. I båda världarna: Rescue är ett tillfälligt verktyg - jag planerar vägen tillbaka till den normala uppstarten i god tid.

Jämförelse: leverantörer med räddningssystem

Förutom en god kvalitet på arbetet, snabb återhämtning Hårdvara också en rent integrerad Räddning-funktion. Följande tabell ger en kompakt översikt över utbudet av funktioner och hantering. Jag har baserat detta på tillgänglighet, lättillgänglighet och typiska arbetsflöden för administratörer. Betyget "Rekommendation" återspeglar min praktiska användning för typiska fel. Viktningen kan naturligtvis variera beroende på den avsedda användningen.

Leverantör	Räddningssystem tillgängligt	Enkel användning	Effekt	Rekommendation
webhoster.de	Ja	Mycket bra	Mycket hög	Testvinnare
Hetzner	Ja	Mycket bra	Hög
Strato	Delvis	Bra	Medium
IONOS	Nej	Medium	Medium

Checklista: Ordningsföljd i en nödsituation

• Aktivera Rescue, utlösa omstart/power cycle, testa SSH.
• Visa hårdvara/lagring: smartctl, lsblk, blkid, mdstat, lvm.
• Aktivera matriser/LUKS/LVM, inspektera filsystem skrivskyddat.
• Skapa en säkerhetskopia (rsync/tar), sedan fsck/Repairs.
• System under /mnt mount, binda mounts, chroot.
• Reparera bootloader/initramfs, kontrollera nätverkskonfigurationen.
• Testa uppstart, verifiera tjänster, kontrollera övervakning/larm.
• Avaktivera Rescue, ta bort tillfälliga nycklar, uppdatera dokumentation.

FAQ Hetzners räddningssystem

Kan jag använda min Uppgifter räddning om systemet inte längre startar? Ja, jag läser av databärarna direkt i räddningsläget och säkerhetskopierar viktiga data. Mapp eller hela partitioner.

Hur länge är räddningsläget aktivt? Efter aktivering är systemet tillgängligt under en begränsad tid och växlar tillbaka till det lokala systemet vid nästa ordinarie omstart. Båt-Jag planerar därför en snabb leverans av Förfarande.

Fungerar detta för moln- och dedikerade servrar? Ja, jag startar läget för både dedikerade maskiner och molninstanser i Hetzner moln.

Vad gör jag om bootloader är skadad? Jag monterar root och om nödvändigt EFI, chrootar in i systemet, kör grub-installation, uppdatera-grub och en ombyggnad av initramf, sedan testar jag omstarten.

Hur hanterar jag LVM/RAID? Jag monterar först mdraid, aktiverar LVM med vgchange -ay och sedan montera de logiska volymerna. Reparationer sker endast efter en säkerhetskopiering.

Kan jag bara spara enskilda filer? Ja, jag monterar skrivskyddad och selektiv kopiering av konfigurationer, databaser (via dump) eller kataloger - minimalt invasivt och snabbt.

Centralt budskap

Med hjälp av Hetzner Rescue System har jag ett snabbt verktyg som på ett tillförlitligt sätt identifierar startproblem, filsystemfel och skadade konfigurationer. Jag aktiverar läget, loggar in via SSH, säkerhetskopierar data och väljer sedan mellan reparation eller ominstallation. Detta sparar Tid i en nödsituation och reducerar driftstoppet till ett minimum. Om du internaliserar dessa få steg kan du hantera även svåra avbrott på ett lugnt sätt. Det innebär att serverdriften kan planeras och att omstarten blir kontrollerad.