Het Hetzner Rescue System starten - stap-voor-stap handleiding voor serverbeheerders

Ik zal je laten zien hoe je het hetzner rescue system in slechts een paar minuten start, hoe je SSH log in en voer uw Server doelgericht herstellen. Deze gids neemt je stap voor stap mee van activering tot herstel, inclusief controles van het bestandssysteem, back-ups en herinstallatie.

Centrale punten

De volgende belangrijke aspecten zullen je helpen om zonder omwegen in de reddingsmodus te starten en te werken.

• ReddingsstartActivering in Robot of Cloud, daarna opnieuw opstarten.
• SSH-toegangLog in met sleutel of wachtwoord en rootrechten.
• FoutenanalyseControleer fsck, logs, partities.
• Back-up van gegevensrsync, tar, scp voor snelle back-ups.
• Nieuwe installatieinstallimage voor nieuwe systemen.

Wat het Rescue System doet

Het Rescue System laadt een onafhankelijke Linux-omgeving in het werkgeheugen en geeft me direct toegang tot de Wortel-toegang, zelfs als de geïnstalleerde Besturingssysteem mislukt. Ik start onafhankelijk van defecte bootloaders, beschadigde pakketten of foutieve configuraties. Hierdoor kan ik bestandssystemen controleren, gegevens herstellen, logs analyseren en services herstarten. De omgeving blijft slank, maar biedt alle belangrijke hulpmiddelen voor diagnostiek en herstel. Hierdoor kan ik de controle houden, zelfs als het reguliere systeem volledig uitvalt.

Wat praktisch is, is dat de rescue omgeving opzettelijk vluchtig is: veranderingen verdwijnen na de reboot, wat betekent dat ik veilig kan testen. Indien nodig installeer ik tijdelijke tools (bijvoorbeeld smartmontools, mdadm, lvm2, btrfs-progs of xfsprogs) zonder het productieve systeem te veranderen. De kernelversie is modern en ondersteunt de nieuwste hardware, inclusief NVMe, UEFI, GPT, software RAID (mdraid), LVM en LUKS-encryptie. Hierdoor kan ik zelfs complexe opslagopstellingen behandelen en zelfs zeldzame foutpatronen op een reproduceerbare manier isoleren.

Vereisten en toegang

Om te beginnen heb ik toegang nodig tot de klanteninterface en mijn SSH-sleutels of een tijdelijke wachtwoord. Ik beheer speciale systemen gemakkelijk via de Hetzner Robotterwijl ik instanties in de cloud beheer via de console. Beide interfaces bieden een duidelijke optie voor het activeren van de reddingsmodus. Ik controleer vooraf het juiste server IP, IPv6-beschikbaarheid en, indien nodig, out-of-band functies voor de reset. Deze voorbereiding verkort de downtime aanzienlijk.

Wanneer ik voor de eerste keer inlog op SSH, bevestig ik bewust de nieuwe vingerafdruk en werk indien nodig mijn Known Hosts entry bij zodat volgende verbindingen niet mislukken door waarschuwingen. Voor teams bewaar ik extra sleutels speciaal voor de reddingsoperatie en verwijder ze weer na voltooiing. Als er alleen een tijdelijk wachtwoord beschikbaar is, verander ik dat direct na het inloggen en vervang het dan door Key-Auth - ik deactiveer logins met wachtwoorden consequent aan het einde van het werk.

Het Rescue System activeren - stap voor stap

Ik open het detailvenster van de server, selecteer de optie "Rescue" en stel de architectuur in op linux64 voor huidige systemen, dan deponeer ik mijn SSH-sleutel. Afhankelijk van de situatie start ik alleen de reddingsmodus en trigger ik de herstart afzonderlijk of gebruik ik "Activate Rescue & Power Cycle" voor een directe herstart. Als de machine hangt, voer ik een harde reset uit via de interface. Na het opstarten toont de interface een tijdelijk root-wachtwoord als ik geen sleutel heb ingevoerd. Zodra de server opstart, reageert hij op SSH en kan ik aan de slag.

In complexe situaties plan ik een duidelijke volgorde: activeren, power cycle, test SSH login, begin dan met troubleshooten. Een handmatige power cycle kan meer nodig zijn op dedicated servers, terwijl cloud instances meestal meteen overschakelen naar de reddingsmodus. Belangrijk: Na een succesvolle reparatie schakel ik de reddingsmodus weer uit zodat de machine opnieuw opstart vanaf de lokale harde schijf.

SSH-verbinding en eerste controles

Ik maak verbinding via SSH met ssh root@ en controleer eerst het netwerk, de gegevensdragers en de logboeken voor een snel overzicht van de Status. Met ip a en ping Ik controleer de beschikbaarheid; journalctl --no-pager -xb of logbestanden op de gemounte schijven tonen de laatste foutmeldingen. De commando's lsblk, blkid en fdisk -l duidelijkheid verschaffen over lay-out en bestandssystemen. Voor RAID gebruik ik cat /proc/mdstat en mdadm --detail voor de toestand. Voor initiële hardware-indicatoren smartctl -a en een korte hdparm -Tt-test.

LVM, RAID, LUKS en speciale bestandssystemen

Veel servers gebruiken LVM, software RAID of encryptie. Ik activeer eerst alle relevante lagen:

• mdraid: mdadm --assemble --scan toont bestaande matrices; ik controleer de status met cat /proc/mdstat.
• LUKSIk open gecodeerde volumes met cryptsetup luksOpen /dev/.
• LVMMet vgscan en vg-wissel -ay Ik activeer volumegroepen en zie ze via lvs/vgs/pvs.

Met Btrfs let ik op subvolumes en mount ik specifiek met -o subvol=@ respectievelijk -o subvolid=5 voor het bovenste niveau. Ik controleer XFS met xfs_herstel (nooit op gemounte volumes), terwijl Ext4 klassiek wordt gebruikt met fsck.ext4 -f is gereorganiseerd. Ik oriënteer me op de GUID/UUID van blkidomdat apparaatnamen voor NVMe (/dev/nvme0n1p1) en kan variëren met het veranderen van volgorde. Ik zal de /etc/fstab.

Bestandssysteem repareren en gegevensback-up maken

Voordat ik repareer, maak ik een back-up van belangrijke Gegevens met rsync, scp of tar naar een extern doel of een lokaal doel Back-up-directory. Voor controles gebruik ik fsck alleen op niet-gemonteerde partities, bijvoorbeeld fsck -f /dev/sda2om inconsistenties netjes te corrigeren. Vervolgens mount ik het systeem onder /mntbijvoorbeeld met mount /dev/sda2 /mnten bevestig subpaden zoals /proc, /sys en /dev wanneer ik wil chrooten. Individuele configuratiebestanden zoals /etc/fstab of netwerkinstellingen rechtstreeks in het gemonteerde systeem. Door zorgvuldig te werk te gaan, voorkom ik gevolgschade en minimaliseer ik downtime.

Voor betrouwbare back-ups vertrouw ik op herhaalbare commando's: rsync -aHAX --info=voortgang2 ontvangt rechten, hardlinks, ACL's en xattrs. Als de regel zwak is, geef ik gas met --bwlimit en parallelle compressie met tar -I pigz. Indien nodig beeld ik kritieke, defecte gegevensdragers af in blokken met ddrescue om het logische werk naar een image te verplaatsen. Ik controleer Btrfs-systemen zorgvuldig met btrfs check --readonly en gebruik btrfs schrobbenom stille fouten op te sporen. XFS vereist vaak een off-mount reparatie in het geval van inconsistenties (xfs_herstel) - Ik maak altijd eerst een back-up van de partitie.

UEFI/BIOS, GPT/MBR en bootloader herstellen

Veel opstartproblemen worden veroorzaakt door de interactie van firmware, partitieschema en bootloader. Ik verduidelijk eerst of de server opstart in UEFI of legacy BIOS modus (ls /sys/firmware/efi). Met UEFI mount ik de EFI-partitie (typisch /dev/sdX1 of /dev/nvme0n1p1) aan /mnt/boot/efi. Dan chroote ik in het systeem:

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

Ik installeer de bootloader opnieuw (grub installeren naar het juiste apparaat) en regenereer de configuratie en initramfs: update-grub en update-initramfs -u -k alle (voor dracut-gebaseerde systemen dracut -f). Als de volgorde van de apparaten niet correct is, gebruik ik de /etc/default/grub UUID's en controleer /etc/fstab voor correcte vermeldingen. Wanneer GPT/MBR wordt gewijzigd, controleer ik of er een BIOS-opstartpartitie (voor GRUB/BIOS) of een geldige EFI-systeempartitie bestaat.

Netwerk valkuilen in Rescue

Netwerkproblemen zijn vaak de reden waarom services "weg" zijn. In Rescue controleer ik de linkstatus (ip-link), routes (ip r) en DNS-resolutie (status resolvectl respectievelijk cat /etc/resolv.conf). Ik test IPv4 en IPv6 afzonderlijk (ping -4/ping -6). Voor servers met bridges of bonding kan de volgorde van interfaces in het productieve systeem verschillen van de reddingsomgeving. Ik noteer de MAC-adressen en breng ze correct in kaart. Als het productiesysteem Netplan gebruikt, controleer ik de /etc/netplan/*.yaml en draai na de chroot netplan genereren en netplan toepassen aan. Voor klassieke /etc/netwerk/interfaces-opstellingen let ik op consistente interfacenamen (voorspelbare namen vs. eth0).

Besturingssysteem opnieuw installeren

Als reparaties geen zin meer hebben, reset ik het systeem met installeer volledig nieuw en besparen zo waardevolle Tijd. De tool leidt me door de selectie van distributie, partitionering en bootloader. Ik neem mijn eigen configuratiebestanden en SSH-sleutels op in de installatie zodat de eerste boot soepel verloopt. Na de installatie start ik de server normaal op en controleer ik de services, firewall en updates. Tot slot verwijder ik de rescue mode zodat de volgende boot weer vanaf de lokale gegevensdrager plaatsvindt.

Ik gebruik bewust UUID-gebaseerde mounts voor nieuwe installaties om problemen met de volgorde van apparaten later uit te sluiten. Voor RAID setups laat ik de arrays vanaf het begin maken en controleer ik de rebuild status voordat ik gegevens restoreer. Als je regelmatig vergelijkbare systemen implementeert, werk je met voorgedefinieerde installimage sjablonen en een duidelijke partitioneringslogica (root, aparte data partitie, swap, EFI indien nodig). Na de eerste boot update ik package sources en kernels, activeer ik security auto-updates en rol ik mijn basis hardening stappen uit.

Veiligheid, tijdvenster en terugval

Toegang is uitsluitend via SSHdaarom vertrouw ik consequent op Sleutels in plaats van statische wachtwoorden. De reddingsmodus blijft na activering een beperkte tijd gereed en valt bij de volgende normale herstart terug op het lokale opstartapparaat. Ik werk snel, documenteer elke stap en houd een tweede sessie open voor grotere interventies. Ik schrijf geen gevoelige gegevens in bash histories en verwijder tijdelijke bestanden na gebruik. Na een succesvol herstel deactiveer ik de modus weer in de interface.

Na het reactiveren van het productieve systeem, roteer ik toegangsgegevens, verwijder ik tijdelijke rescue keys, reset ik onnodige rootwachtwoorden en maak ik back-ups van vers gegenereerde configuraties. Ik verzamel auditinformatie (wie deed wat en wanneer) en documenteer afwijkingen van de standaardinstellingen. Zo voorkom ik dat noodmaatregelen permanent worden en houd ik me aan de compliance-eisen.

Voorbeeld: WordPress server redden

Ik start op in de reddingsmodus, koppel de systeempartitie en maak een back-up van de Database per mysqldump en de wp-content-directory met tar of rsync. Vervolgens controleer ik het bestandssysteem, reset ik de bootloader en corrigeer ik onjuiste PHP- of NGINX-configuraties. Als pakketten corrupt zijn, gebruik ik chroot en installeer ik afhankelijkheden opnieuw. Als dat niet genoeg is, reset ik de machine met installeer en herstel de back-up en configuraties. Tot slot controleer ik de frontend, login en cronjobs.

In de praktijk let ik op InnoDB consistentie (MySQL/MariaDB): Mislukt mysqld aan het begin beveilig ik de /var/lib/mysql en voer de dump uit vanaf een nieuwe instantie. Ik leeg caches (object cache, pagina cache, OPCache) selectief, stel bestandspermissies consequent in (find . -type d -exec chmod 755 {} ;, find . -type f -exec chmod 644 {} ;) en controleer open_gebaseerdir en uploadmappen. Als test deactiveer ik kritieke plugins door de plugin-directory te hernoemen. Vervolgens controleer ik PHP FPM pools, FastCGI timeouts, geheugenlimieten en de NGINX/Apache includes. Een korte wp cron gebeurtenis uitvoeren --due-nu (als WP-CLI beschikbaar is) helpt bij het verwerken van achterstanden.

Beste werkwijzen voor beheerders

Voordat ik diep ingrijp, maak ik een verse Back-up en beveiligde sleutelbestanden zoals /etczodat ik op elk moment terug kan springen. Van elke stap wordt een kort logboek bijgehouden, dat me later helpt bij audits of nieuwe incidenten. Na het herstarten in het productieve systeem controleer ik de services, logs, netwerk en monitoring grondig. Voor terugkerende taken bouw ik een kleine scriptset op om opdrachtreeksen te standaardiseren. Als je extra prestaties of nieuwe hardware plant, kun je geschikte Een rootserver huren en migratievenster.

Ik heb ook een runbook-checklist klaarliggen met verantwoordelijkheden en escalatiepaden. Geplande "wedstrijddagen" (gerichte storingssimulaties) trainen het team voor noodgevallen. Ik test regelmatig back-ups als herstelvoorbeeld - een ongeteste back-up wordt als onbestaand beschouwd. En ik versie mijn systeemconfiguraties zodat ik snel verschillen kan herkennen tussen de status "goed" en "defect".

Cloud vs. dedicated: verschillen in het proces

In de cloud verander ik de opstartmodus vaak direct in het dialoogvenster van de instantie en gebruik ik de seriële console voor snelle controles, terwijl een power cycle en mogelijk out-of-band toegang nodig zijn op dedicated servers. Cloud volumes kunnen gemakkelijk worden gekoppeld aan andere instanties - een efficiënte manier om een back-up te maken van gegevens zonder downtime op de betreffende host. Op bare metal let ik meer op de fysieke volgorde van de schijven, vooral bij de aanschaf van extra SSD's/NVMe-modules. In beide werelden: Rescue is een tijdelijk hulpmiddel - ik plan de weg terug naar de normale boot op tijd.

Vergelijking: aanbieders met reddingssysteem

Naast een goede kwaliteit van het werk, snel herstel Hardware ook een goed geïntegreerde Redding-functie. De volgende tabel geeft een compact overzicht van de verschillende functies en handelingen. Ik heb dit gebaseerd op beschikbaarheid, toegankelijkheid en typische administratieve workflows. De beoordeling "Aanbeveling" weerspiegelt mijn praktisch gebruik voor typische fouten. De weging kan natuurlijk variëren afhankelijk van het beoogde gebruik.

Aanbieder	Reddingssysteem beschikbaar	Gebruiksgemak	Prestaties	Aanbeveling
webhoster.de	Ja	Zeer goed	Zeer hoog	Testwinnaar
Hetzner	Ja	Zeer goed	Hoog
Strato	Gedeeltelijk	Goed	Medium
IONOS	Geen	Medium	Medium

Checklist: Volgorde van stappen in een noodgeval

• Rescue activeren, herstart/stroomcyclus activeren, SSH testen.
• Bekijk hardware/opslag: smartctl, lsblk, blkid, mdstat, lvm.
• Activeer arrays/LUKS/LVM, inspecteer bestandssystemen alleen-lezen.
• Maak een back-up (rsync/tar) en vervolgens fsck/Reparaties.
• Systeem onder /mnt mount, bind mounts, chroot.
• Herstel bootloader/initramfs, controleer netwerkconfiguratie.
• Test opstarten, controleer services, controleer bewaking/alarmen.
• Rescue deactiveren, tijdelijke sleutels verwijderen, documentatie bijwerken.

FAQ Hetzner Reddingssysteem

Kan ik mijn Gegevens redden als het systeem niet meer opstart? Ja, ik lees de gegevensdragers direct in de reddingsmodus en maak een back-up van belangrijke gegevens. Map of volledige partities.

Hoe lang blijft de rescue mode actief? Na activering is het systeem voor een beperkte tijd beschikbaar en schakelt het terug naar het lokale systeem bij de volgende reguliere herstart. Boot-apparaat, ik ben daarom van plan een snelle Procedure.

Werkt dit voor cloud- en dedicated servers? Ja, ik start de modus voor zowel dedicated machines als cloud-instanties in de Hetzner wolk.

Wat doe ik als de bootloader beschadigd is? Ik mount root en eventueel EFI, chroot in het systeem, voer grub installeren, update-grub en een rebuild van de initramf, dan test ik de reboot.

Hoe ga ik om met LVM/RAID? Ik monteer eerst mdraid, activeer LVM met vg-wissel -ay en koppel vervolgens de logische volumes. Reparaties gebeuren alleen na een back-up.

Kan ik alleen individuele bestanden opslaan? Ja, ik mount alleen-lezen en kopieer selectief configuraties, databases (via dump) of mappen - minimaal invasief en snel.

Kernboodschap

Met de Hetzner Rescue System, ik heb een snel hulpmiddel dat opstartproblemen, fouten in het bestandssysteem en beschadigde configuraties betrouwbaar identificeert. Ik activeer de modus, log in via SSH, maak een back-up van gegevens en beslis dan tussen repareren of opnieuw installeren. Dit bespaart Tijd en beperkt de uitvaltijd tot het absolute minimum. Als je deze paar stappen internaliseert, kun je zelfs moeilijke uitvallen rustig afhandelen. Dit betekent dat de werking van de server kan worden gepland en de herstart kan worden gecontroleerd.