Opstart af Hetzner Rescue System - trinvis vejledning til serveradministratorer

Jeg vil vise dig, hvordan du starter Hetzners redningssystem på få minutter, hvordan du SSH log ind og indtast din Server reparation på en målrettet måde. Denne vejledning tager dig trin for trin fra aktivering til gendannelse, inklusive filsystemtjek, sikkerhedskopiering og geninstallation.

Centrale punkter

Følgende nøgleaspekter vil hjælpe dig med at starte og arbejde i redningstilstand uden omveje.

• RedningsstartAktivering i Robot eller Cloud, og genstart derefter.
• SSH-adgangLog ind med nøgle eller adgangskode og root-rettigheder.
• Analyse af fejlTjek fsck, logfiler, partitioner.
• Sikkerhedskopiering af data: rsync, tar, scp til hurtig sikkerhedskopiering.
• Ny installationinstallimage til nye systemer.

Hvad Rescue System gør

Rescue System indlæser et uafhængigt Linux-miljø i arbejdshukommelsen og giver mig øjeblikkelig adgang til Root-adgang, selv om den installerede Operativsystem fejler. Jeg booter uafhængigt af defekte boot loadere, beskadigede pakker eller fejlbehæftede konfigurationer. Det giver mig mulighed for at tjekke filsystemer, gendanne data, analysere logfiler og genstarte tjenester. Miljøet forbliver slankt, men tilbyder alle de vigtige værktøjer til diagnosticering og gendannelse. Det giver mig mulighed for at bevare kontrollen, selv hvis det almindelige system går helt ned.

Det praktiske er, at redningsmiljøet bevidst er flygtigt: ændringer forsvinder efter genstart, hvilket betyder, at jeg kan teste sikkert. Hvis det er nødvendigt, installerer jeg midlertidige værktøjer (f.eks. smartmontools, mdadm, lvm2, btrfs-progs eller xfsprogs) uden at ændre det produktive system. Kerneversionen er moderne og understøtter den nyeste hardware, herunder NVMe, UEFI, GPT, software-RAID (mdraid), LVM og LUKS-kryptering. Det giver mig mulighed for at dække selv komplekse storage-opsætninger og isolere selv sjældne fejlmønstre på en reproducerbar måde.

Krav og adgang

For at komme i gang skal jeg have adgang til kundeinterfacet og min SSH-nøgler eller en midlertidig adgangskode. Jeg administrerer dedikerede systemer bekvemt via Hetzner Robotmens jeg styrer instanser i skyen via konsollen. Begge grænseflader tilbyder en klar mulighed for at aktivere redningstilstand. Jeg tjekker den korrekte server-IP, IPv6-tilgængelighed og om nødvendigt out-of-band-funktioner til nulstillingen på forhånd. Denne forberedelse forkorter nedetiden betydeligt.

Når jeg logger ind på SSH for første gang, bekræfter jeg bevidst det nye fingeraftryk og opdaterer om nødvendigt min Known Hosts-indgang, så efterfølgende forbindelser ikke mislykkes på grund af advarsler. For teams gemmer jeg ekstra nøgler specifikt til redningsaktionen og fjerner dem igen, når de er færdige. Hvis der kun er en midlertidig adgangskode til rådighed, ændrer jeg den straks efter login og erstatter den derefter med Key-Auth - jeg deaktiverer konsekvent adgangskode-logins ved arbejdets afslutning.

Aktivering af redningssystemet - trin for trin

Jeg åbner serverdetaljevinduet, vælger indstillingen "Rescue" og indstiller arkitekturen til linux64 for nuværende systemer, så indbetaler jeg min SSH-nøgle. Afhængigt af situationen starter jeg kun redningstilstanden og udløser genstarten separat, eller jeg bruger "Activate Rescue & Power Cycle" til en direkte genstart. Hvis maskinen hænger, udfører jeg en hård nulstilling via interfacet. Efter opstarten viser grænsefladen en midlertidig root-adgangskode, hvis jeg ikke har indtastet en nøgle. Så snart serveren starter op, svarer den på SSH, og jeg kan komme i gang.

I komplekse situationer planlægger jeg en klar rækkefølge: Aktivér, tænd/sluk, test SSH-login, og start derefter fejlfinding. En manuel power cycle kan være mere nødvendig på dedikerede servere, mens cloud-instanser normalt skifter til redningstilstand med det samme. Vigtigt: Efter en vellykket reparation slår jeg redningstilstanden fra igen, så maskinen genstarter fra den lokale harddisk.

SSH-forbindelse og første tjek

Jeg forbinder via SSH med ssh root@. og tjek først netværk, databærere og logfiler for at få et hurtigt overblik over problemet. Status. Med ip a og ping Jeg tjekker tilgængeligheden; journalctl --no-pager -xb eller logfiler på de monterede diske viser de seneste fejlmeddelelser. Kommandoerne lsblk, blkid og fdisk -l giver klarhed over layout og filsystemer. Til RAID bruger jeg cat /proc/mdstat og mdadm --detail for tilstanden. For indledende hardwareindikatorer smartctl -a og en kort hdparm -Tt-test.

LVM, RAID, LUKS og specielle filsystemer

Mange servere bruger LVM, software-RAID eller kryptering. Jeg aktiverer først alle relevante lag:

• mdraid: mdadm --assemble --scan viser eksisterende arrays; jeg tjekker status med cat /proc/mdstat.
• LUKS: Jeg åbner krypterede diskenheder med cryptsetup luksOpen /dev/ ..
• LVMMed vgscan og vgchange -ay Jeg aktiverer volumengrupper og ser dem via lvs/vgs/pvs.

Med Btrfs er jeg opmærksom på undervolumener og monterer specifikt med -o subvol=@ henholdsvis -o subvolid=5 for det øverste niveau. Jeg tjekker XFS med xfs_repair (aldrig på monterede diskenheder), mens Ext4 klassisk bruges med fsck.ext4 -f er reorganiseret. Jeg orienterer mig om GUID/UUID fra blkidfordi enhedsnavne for NVMe (/dev/nvme0n1p1) og kan variere med skiftende ordre. Jeg vil korrigere /etc/fstab.

Reparation af filsystem og sikkerhedskopiering af data

Før jeg reparerer, tager jeg backup af vigtige ting Data med rsync, scp eller tjære til et eksternt mål eller et lokalt mål Backup-katalog. Til kontrol bruger jeg fsck kun på umonterede partitioner, for eksempel fsck -f /dev/sda2for at rette op på uoverensstemmelser. Derefter monterer jeg systemet under /mntfor eksempel med mount /dev/sda2 /mntog vedhæfte understier som f.eks. /proc, /sys og /dev når jeg vil chroot'e. Individuelle konfigurationsfiler som f.eks. /etc/fstab eller netværksindstillinger direkte i det monterede system. Ved at gå forsigtigt frem forhindrer jeg følgeskader og minimerer nedetid.

For at få pålidelige backups er jeg afhængig af gentagelige kommandoer: rsync -aHAX --info=progress2 modtager rettigheder, hardlinks, ACL'er og xattrs. Hvis linjen er svag, drosler jeg ned med --bwlimit og parallelisere komprimeringen med tar -I pigz. Om nødvendigt afbilder jeg kritiske, defekte databærere i blokke med ddrescue for at flytte det logiske arbejde til et image. Jeg tjekker omhyggeligt Btrfs-systemer med btrfs check --readonly og bruge btrfs-scrubfor at opdage lydløse fejl. XFS kræver ofte en off-mount-reparation i tilfælde af uoverensstemmelser (xfs_repair) - Jeg tager altid backup af partitionen først.

Reparation af UEFI/BIOS, GPT/MBR og bootloader

Mange bootproblemer skyldes samspillet mellem firmware, partitionsskema og bootloader. Jeg afklarer først, om serveren starter i UEFI eller legacy BIOS-tilstand (ls /sys/firmware/efi). Med UEFI monterer jeg EFI-partitionen (typisk /dev/sdX1 eller /dev/nvme0n1p1) til /mnt/boot/efi. Og så chrooterer jeg ind i systemet:

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

Jeg geninstallerer bootloaderen korrekt (grub-installation til den rigtige enhed) og genskabe konfiguration og initramfs: opdater-grub og update-initramfs -u -k alle (for dracut-baserede systemer dracut -f). Hvis rækkefølgen af enhederne ikke er korrekt, bruger jeg /etc/default/grub UUID'er og tjek /etc/fstab for korrekte indtastninger. Når jeg ændrer GPT/MBR, tjekker jeg, om der findes en BIOS-opstartspartition (til GRUB/BIOS) eller en gyldig EFI-systempartition.

Netværkets faldgruber i Rescue

Netværksproblemer er ofte årsagen til, at tjenester er "væk". I Rescue tjekker jeg linkstatus (ip-link), ruter (ip r) og DNS-opløsning (resolvectl status hhv. cat /etc/resolv.conf). Jeg tester IPv4 og IPv6 separat (ping -4/ping -6). For servere med broer eller bonding kan rækkefølgen af grænseflader i det produktive system afvige fra redningsmiljøet. Jeg noterer MAC-adresserne og mapper dem korrekt. Hvis produktionssystemet bruger Netplan, kontrollerer jeg /etc/netplan/*.yaml og drej efter chroot'en netplan genererer og netplan gælder på. For klassiske /etc/netværk/grænseflader-opsætninger er jeg opmærksom på konsistente interfacenavne (forudsigelige navne vs. eth0).

Geninstaller operativsystemet

Hvis reparationer ikke længere giver mening, nulstiller jeg systemet med installationsbillede helt nye og dermed spare værdifulde Tid. Værktøjet guider mig gennem valg af distribution, partitionering og boot loader. Jeg inkluderer mine egne konfigurationsfiler og SSH-nøgler i installationen, så den første opstart kører problemfrit. Efter installationen starter jeg serveren som normalt og tjekker tjenester, firewall og opdateringer. Til sidst fjerner jeg redningstilstanden, så den næste opstart sker fra den lokale databærer igen.

Jeg bruger bevidst UUID-baserede mounts til nye installationer for at udelukke problemer med enhedsrækkefølgen senere. Ved RAID-opsætninger opretter jeg arrays fra starten og tjekker rebuild-status, før jeg gendanner data. Hvis du implementerer lignende systemer regelmæssigt, arbejder du med foruddefinerede installationsskabeloner og en klar partitioneringslogik (root, separat datapartition, swap, EFI, hvis det er nødvendigt). Efter den første opstart opdaterer jeg pakkekilder og kerner, aktiverer automatiske sikkerhedsopdateringer og udruller mine grundlæggende hærdningstrin.

Sikkerhed, tidsvindue og tilbagefald

Adgang sker udelukkende via SSHDerfor stoler jeg konsekvent på Nøgler i stedet for statiske adgangskoder. Redningstilstanden forbliver klar i et begrænset tidsrum efter aktivering og falder tilbage til den lokale opstartsenhed ved næste normale genstart. Jeg arbejder hurtigt, dokumenterer hvert trin og holder en anden session åben til større indgreb. Jeg skriver ikke følsomme data i bash-historier og sletter midlertidige filer efter brug. Efter en vellykket gendannelse deaktiverer jeg tilstanden i grænsefladen igen.

Når jeg har genaktiveret det produktive system, roterer jeg adgangsdata, fjerner midlertidige redningsnøgler, nulstiller overflødige root-adgangskoder og tager backup af nyligt genererede konfigurationer. Jeg indsamler revisionsoplysninger (hvem gjorde hvad og hvornår) og dokumenterer afvigelser fra standardopsætningen. Det forhindrer, at nødforanstaltninger bliver permanente, og jeg overholder compliance-kravene.

Eksempel: Red WordPress-server

Jeg starter i redningstilstand, monterer systempartitionen og sikkerhedskopierer Database per mysqldump og den wp-indhold-katalog med tjære eller rsync. Derefter tjekker jeg filsystemet, nulstiller bootloaderen og retter forkerte PHP- eller NGINX-konfigurationer. Hvis pakkerne er beskadigede, bruger jeg chroot og geninstallerer afhængigheder. Hvis det ikke er nok, nulstiller jeg maskinen med installationsbillede og gendanner backup og konfigurationer. Til sidst verificerer jeg frontend, login og cronjobs.

I praksis er jeg opmærksom på InnoDB-konsistens (MySQL/MariaDB): Fejler mysqld I starten sikrer jeg mig /var/lib/mysql og kører dumpen fra en ny instans. Jeg tømmer cacher (objektcache, sidecache, OPCache) selektivt, indstiller filtilladelser konsekvent (find . -type d -exec chmod 755 {} ;, find . -type f -exec chmod 644 {} ;) og tjek open_basedir og upload-biblioteker. Jeg deaktiverer kritiske plugins som en test ved at omdøbe plugin-biblioteket. Derefter tjekker jeg PHP FPM pools, FastCGI timeouts, hukommelsesgrænser og NGINX/Apache includes. En kort wp cron event run --due-now (hvis WP-CLI er tilgængelig) hjælper med at behandle efterslæb.

Bedste praksis for administratorer

Før dybe indgreb opretter jeg en ny Backup og sikre nøglefiler som f.eks. /etcså jeg kan springe tilbage når som helst. Hvert trin bliver registreret i en kort log, som hjælper mig senere med audits eller nye hændelser. Når jeg har genstartet det produktive system, tjekker jeg grundigt tjenester, logfiler, netværk og overvågning. Til tilbagevendende opgaver opbygger jeg et lille script-sæt for at standardisere kommandosekvenser. Hvis du planlægger ekstra ydeevne eller ny hardware, kan du oprette passende Lej en root-server og migreringsvindue.

Jeg har også en runbook-tjekliste klar, som indeholder ansvarsområder og eskaleringsstier. Planlagte "game days" (målrettede fejlsimuleringer) træner teamet til nødsituationer. Jeg tester regelmæssigt sikkerhedskopier som en gendannelsesprøve - en uprøvet sikkerhedskopi betragtes som ikke-eksisterende. Og jeg versionerer mine systemkonfigurationer, så jeg hurtigt kan genkende forskelle mellem "god" og "fejlbehæftet" status.

Cloud vs. dedikeret: forskelle i processen

I skyen ændrer jeg ofte opstartstilstanden direkte i instansdialogen og bruger den serielle konsol til hurtige tjek, mens en power cycle og muligvis out-of-band-adgang er nødvendig på dedikerede servere. Cloud-volumener kan nemt knyttes til andre instanser - en effektiv måde at sikkerhedskopiere data på uden nedetid på den berørte host. På bare metal er jeg mere opmærksom på den fysiske rækkefølge af drevene, især når jeg køber ekstra SSD'er/NVMe-moduler. I begge verdener: Rescue er et midlertidigt værktøj - jeg planlægger vejen tilbage til den normale opstart i god tid.

Sammenligning: leverandører med redningssystem

Ud over en god arbejdskvalitet, hurtig genopretning Hardware også en rent integreret Redning-funktion. Følgende tabel giver et kompakt overblik over udvalget af funktioner og håndtering. Jeg har baseret dette på tilgængelighed, nem adgang og typiske administrative arbejdsgange. Vurderingen "Anbefaling" afspejler min praktiske brug til typiske fejl. Vægtningen kan selvfølgelig variere afhængigt af den tilsigtede brug.

Udbyder	Redningssystem til rådighed	Brugervenlighed	Strøm	Anbefaling
webhoster.de	Ja	Meget god	Meget høj	Vinder af test
Hetzner	Ja	Meget god	Høj
Strato	Delvist	God	Medium
IONOS	Nej	Medium	Medium

Tjekliste: Rækkefølgen af trin i en nødsituation

• Aktiver Rescue, udløs genstart/power cycle, test SSH.
• Se hardware/lager: smartctl, lsblk, blkid, mdstat, lvm.
• Aktiver arrays/LUKS/LVM, inspicér skrivebeskyttede filsystemer.
• Lav en sikkerhedskopi (rsync/tar), og så fsck/Reparationer.
• System under /mnt mount, bind mounts, chroot.
• Reparer bootloader/initramfs, tjek netværkskonfigurationen.
• Test opstart, bekræft tjenester, tjek overvågning/alarmer.
• Deaktiver Rescue, fjern midlertidige nøgler, opdater dokumentation.

Ofte stillede spørgsmål om Hetzner Rescue System

Kan jeg bruge min Data redning, hvis systemet ikke længere starter? Ja, jeg læser databærerne direkte i redningstilstand og tager backup af vigtige data. Mappe eller hele partitioner.

Hvor længe forbliver redningstilstanden aktiv? Efter aktivering er systemet tilgængeligt i en begrænset periode og skifter tilbage til det lokale system ved den næste almindelige genstart. Båd-enhed, og jeg planlægger derfor en hurtig Procedure.

Virker dette for cloud og dedikerede servere? Ja, jeg starter tilstanden for både dedikerede maskiner og cloud-instanser i Hetzner-skyen.

Hvad gør jeg, hvis bootloaderen er beskadiget? Jeg monterer root og om nødvendigt EFI, chrooter ind i systemet, udfører grub-installation, opdater-grub og en genopbygning af initramf, og så tester jeg genstarten.

Hvordan håndterer jeg LVM/RAID? Jeg monterer først mdraid, aktiverer LVM med vgchange -ay og monter derefter de logiske diske. Reparationer finder kun sted efter en backup.

Kan jeg kun gemme enkelte filer? Ja, jeg monterer skrivebeskyttet og kopierer selektivt konfigurationer, databaser (via dump) eller mapper - minimalt invasivt og hurtigt.

Kernebudskab

Med den Hetzner Rescue System har jeg et hurtigt værktøj, der pålideligt identificerer opstartsproblemer, filsystemfejl og beskadigede konfigurationer. Jeg aktiverer tilstanden, logger ind via SSH, sikkerhedskopierer data og vælger så mellem at reparere eller geninstallere. Dette sparer Tid i en nødsituation og reducerer nedetiden til et absolut minimum. Hvis du internaliserer disse få trin, kan du håndtere selv vanskelige nedbrud roligt. Det betyder, at serverdriften kan planlægges, og genstarten kontrolleres.