Hetzner Rescue -järjestelmän käynnistäminen - vaiheittainen opas palvelimen ylläpitäjille

Näytän sinulle, miten hetznerin pelastusjärjestelmä käynnistetään vain muutamassa minuutissa, miten SSH kirjaudu sisään ja anna Palvelin korjaaminen kohdennetusti. Tässä oppaassa opastetaan vaihe vaiheelta aktivoinnista palautukseen, mukaan lukien tiedostojärjestelmän tarkistukset, varmuuskopiot ja uudelleenasennus.

Keskeiset kohdat

Seuraavat keskeiset seikat auttavat sinua aloittamaan ja työskentelemään pelastustilassa ilman kiertoteitä.

• Pelastuksen aloitusAktivointi Robotissa tai Cloudissa ja käynnistä sitten uudelleen.
• SSH-yhteysKirjaudu sisään avaimella tai salasanalla ja pääkäyttäjän oikeuksilla.
• VirheanalyysiTarkista fsck, lokit, osiot.
• Tietojen varmuuskopiointi: rsync, tar, scp nopeisiin varmuuskopioihin.
• Uusi asennusinstallmage tuoreille järjestelmille.

Mitä Rescue-järjestelmä tekee

Rescue System lataa työmuistiin itsenäisen Linux-ympäristön ja tarjoaa minulle välittömän pääsyn Juuret-pääsy, vaikka asennettu Käyttöjärjestelmä epäonnistuu. Käynnistän koneen riippumatta viallisista käynnistyslataajista, vahingoittuneista paketeista tai virheellisistä kokoonpanoista. Näin voin tarkistaa tiedostojärjestelmät, palauttaa tietoja, analysoida lokitietoja ja käynnistää palvelut uudelleen. Ympäristö pysyy kevyenä, mutta tarjoaa kaikki tärkeät työkalut diagnostiikkaa ja palautusta varten. Näin pysyn hallinnassa, vaikka tavallinen järjestelmä menisi täysin epäkuntoon.

Käytännönläheistä on se, että pelastusympäristö on tarkoituksellisesti epävakaa: muutokset häviävät uudelleenkäynnistyksen jälkeen, mikä tarkoittaa, että voin testata turvallisesti. Tarvittaessa asennan väliaikaisia työkaluja (esim. smartmontools, mdadm, lvm2, btrfs-progs tai xfsprogs) muuttamatta tuottavaa järjestelmää. Ytimen versio on nykyaikainen ja tukee uusinta laitteistoa, mukaan lukien NVMe, UEFI, GPT, ohjelmisto-RAID (mdraid), LVM ja LUKS-salaus. Näin voin kattaa monimutkaisetkin tallennuskokoonpanot ja eristää harvinaisetkin virhemallit toistettavasti.

Vaatimukset ja pääsy

Aloittaakseni tarvitsen pääsyn asiakkaan käyttöliittymään ja oman SSH-avaimet tai väliaikainen salasana. Hallitsen omistettuja järjestelmiä kätevästi Hetzner-robottikun taas minä hallitsen pilvessä olevia instansseja konsolin kautta. Molemmissa käyttöliittymissä on selkeä vaihtoehto pelastustilan aktivoimiseksi. Tarkistan etukäteen oikean palvelimen IP-osoitteen, IPv6-saatavuuden ja tarvittaessa kaistan ulkopuoliset toiminnot resetointia varten. Tämä valmistelu lyhentää seisokkiaikaa merkittävästi.

Kun kirjaudun SSH:hen ensimmäistä kertaa, vahvistan tietoisesti uuden sormenjäljen ja päivitän tarvittaessa Known Hosts -tietueeni, jotta seuraavat yhteydet eivät epäonnistu varoitusten takia. Tiimejä varten tallennan ylimääräisiä avaimia nimenomaan pelastusoperaatiota varten ja poistan ne jälleen valmistumisen jälkeen. Jos käytettävissä on vain väliaikainen salasana, vaihdan sen heti kirjautumisen jälkeen ja korvaan sen Key-Authilla - poistan salasanalliset kirjautumiset käytöstä johdonmukaisesti työn päätyttyä.

Rescue-järjestelmän aktivointi - askel askeleelta

Avaan palvelimen tiedot -ikkunan, valitsen "Rescue"-vaihtoehdon ja asetan arkkitehtuurin arvoksi "Rescue". linux64 nykyisiä järjestelmiä varten, sitten talletan SSH-avain. Tilanteesta riippuen käynnistän vain pelastustilan ja käynnistän uudelleenkäynnistyksen erikseen tai käytän "Activate Rescue & Power Cycle" -toimintoa suoraan uudelleenkäynnistykseen. Jos kone roikkuu, suoritan kovan nollauksen käyttöliittymän kautta. Käynnistyksen jälkeen käyttöliittymä näyttää väliaikaisen pääkäyttäjän salasanan, jos en ole syöttänyt avainta. Heti kun palvelin käynnistyy, se vastaa SSH:hon ja pääsen alkuun.

Monimutkaisissa tilanteissa suunnittelen selkeän järjestyksen: Aktivoi, katkaise virta, testaa SSH-kirjautuminen ja aloita sitten vianmääritys. Manuaalinen virrankatkaisu voi olla tarpeellisempi dedikoiduilla palvelimilla, kun taas pilvipalvelimet siirtyvät yleensä välittömästi pelastustilaan. Tärkeää: Onnistuneen korjauksen jälkeen kytken pelastustilan jälleen pois päältä, jotta kone käynnistyy uudelleen paikalliselta kiintolevyltä.

SSH-yhteys ja ensimmäiset tarkistukset

Olen yhteydessä SSH kanssa ssh root@ ja tarkista ensin verkko, tietovälineet ja lokit, jotta saat nopean yleiskatsauksen Tila. Osoitteessa ip a ja ping Tarkistan saatavuuden; journalctl --no-pager -xb tai asennettujen levyjen lokitiedostoissa näkyvät viimeisimmät virheilmoitukset. Komennot lsblk, blkid ja fdisk -l selkeyttää ulkoasua ja tiedostojärjestelmiä. RAID-järjestelmään käytän cat /proc/mdstat ja mdadm --detail ehdon osalta. Alkuperäiset laitteistoindikaattorit smartctl -a ja lyhyt hdparm -Tt-testi.

LVM, RAID, LUKS ja erikoistiedostojärjestelmät

Monet palvelimet käyttävät LVM:ää, ohjelmisto-RAIDia tai salausta. Aktivoin ensin kaikki asiaankuuluvat tasot:

• mdraid: mdadm --assemble --scan tuo esiin olemassa olevat taulukot; tarkistan tilan komennolla cat /proc/mdstat.
• LUKS: Avaan salatut niteet cryptsetup luksOpen /dev/.
• LVMOsoitteessa vgscan ja vgchange -ay Aktivoin äänenvoimakkuusryhmät ja näen ne lvs/vgs/pvs.

Btrfs:n kanssa kiinnitän huomiota alikasvoihin ja kiinnitän erityisesti -o subvol=@ vastaavasti -o subvolid=5 ylimmälle tasolle. Tarkistan XFS:n xfs_repair (ei koskaan asennetuissa tileissä), kun taas Ext4:ää käytetään klassisesti yhdessä fsck.ext4 -f järjestetään uudelleen. Suuntaudun GUID/UUID-tunnuksen perusteella osoitteesta blkidkoska NVMe-laitteiden nimet (/dev/nvme0n1p1) ja voi vaihdella tilauksen muuttuessa. Korjaan /etc/fstab.

Tiedostojärjestelmän korjaus ja tietojen varmuuskopiointi

Ennen korjausta varmuuskopioin tärkeät Tiedot kanssa rsync, scp tai tar ulkoiseen tai paikalliseen kohteeseen Varmuuskopiointi-hakemisto. Tarkistuksiin käytän fsck vain kytkemättömissä osioissa, esimerkiksi fsck -f /dev/sda2korjata epäjohdonmukaisuudet siististi. Sitten asennan järjestelmän osoitteeseen /mntesimerkiksi mount /dev/sda2 /mntja liittää alipolkuja, kuten /proc, /sys ja /dev kun haluan tehdä chrootin. Yksittäiset asetustiedostot, kuten /etc/fstab tai verkkoasetukset suoraan asennetussa järjestelmässä. Toimimalla varovasti estän välilliset vahingot ja minimoin käyttökatkokset.

Luotettavia varmuuskopioita varten luotan toistettaviin komentoihin: rsync -aHAX --info=progress2 saa oikeuksia, kovalinkkejä, ACL:iä ja xattrs:iä. Jos rivi on heikko, kuristan sen --bwlimit ja rinnakkaistaa pakkauksen tar -I pigz. Tarvittaessa kuvaan kriittiset, vialliset tietovälineet lohkoissa, joissa on ddrescue siirtää looginen työ kuvaan. Tarkistan huolellisesti Btrfs-järjestelmät btrfs check --readonly ja käyttää btrfs scrubhiljaisten virheiden havaitsemiseksi. XFS vaatii usein asennuksen korjaamista epäjohdonmukaisuuksien tapauksessa (xfs_repair) - varmuuskopioin aina ensin osion.

UEFI/BIOS, GPT/MBR ja käynnistyslataimen korjaus

Monet käynnistysongelmat johtuvat laiteohjelmiston, osiosuunnitelman ja käynnistyslataajan vuorovaikutuksesta. Selvitän ensin, käynnistyykö palvelin UEFI- vai perinteisessä BIOS-tilassa (ls /sys/firmware/efi). UEFI:n avulla asennan EFI-osion (tyypillinen /dev/sdX1 tai /dev/nvme0n1p1) kohteeseen /mnt/boot/efi. Sitten minä chroote järjestelmään:

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

Asennan bootloaderin uudelleen asianmukaisesti (grub-install oikeaan laitteeseen) ja luo uudelleen konfiguraatio ja initramfs: update-grub ja update-initramfs -u -k all (Dracut-pohjaisten järjestelmien osalta dracut -f). Jos laitteiden järjestys ei ole oikea, käytän komentoa /etc/default/grub UUID-tunnukset ja tarkista /etc/fstab oikeat merkinnät. Kun vaihdan GPT/MBR:ää, tarkistan, onko BIOS-käynnistysosio (GRUB/BIOSia varten) tai kelvollinen EFI-järjestelmäosio olemassa.

Verkon sudenkuopat pelastustoiminnassa

Verkko-ongelmat ovat usein syynä siihen, että palvelut ovat "poissa". Rescue-ohjelmassa tarkistan linkin tilan (ip-linkki), reitit (ip r) ja DNS-resoluutio (resolvectl status resp. cat /etc/resolv.conf-tiedosto). Testaan IPv4:n ja IPv6:n erikseen (ping -4/ping -6). Jos palvelimissa on sillat tai liimaus, rajapintojen järjestys tuotantojärjestelmässä voi poiketa pelastusympäristöstä. Merkitsen MAC-osoitteet muistiin ja kartoitan ne oikein. Jos tuotantojärjestelmä käyttää Netplania, tarkistan, että /etc/netplan/*.yaml ja käänny chrootin jälkeen netplan tuottaa ja netplan apply on. Klassista /etc/verkko/liitännät-asennuksissa kiinnitän huomiota johdonmukaisiin rajapintojen nimiin (ennustettavat nimet vs. eth0).

Asenna käyttöjärjestelmä uudelleen

Jos korjaukset eivät enää ole järkeviä, nollaan järjestelmän seuraavalla tavalla installmage täysin uusia ja siten säästää arvokasta Aika. Työkalu opastaa minua jakelun, osioiden ja käynnistyslataimen valinnassa. Liitän asennukseen omat konfiguraatiotiedostoni ja SSH-avaimet, jotta ensimmäinen käynnistys sujuu ongelmitta. Asennuksen jälkeen käynnistän palvelimen normaalisti ja tarkistan palvelut, palomuurin ja päivitykset. Lopuksi poistan pelastustilan, jotta seuraava käynnistys tapahtuu jälleen paikalliselta tietovälineeltä.

Käytän tarkoituksella UUID-pohjaisia kiinnityksiä uusissa asennuksissa, jotta laitteiden järjestysongelmat voidaan sulkea pois myöhemmin. RAID-asetusten osalta olen luonut asetelmat alusta alkaen ja tarkistan uudelleenrakentamisen tilan ennen tietojen palauttamista. Jos otat samanlaisia järjestelmiä käyttöön toistuvasti, käytät ennalta määriteltyjä asennusmalleja ja selkeää osiointilogiikkaa (pääkäyttäjä, erillinen dataosio, swap, EFI tarvittaessa). Ensimmäisen käynnistyksen jälkeen päivitän pakettilähteet ja ytimet, aktivoin automaattiset tietoturvapäivitykset ja otan käyttöön peruskarkaisuvaiheet.

Turvallisuus, aikaikkuna ja uusiutuminen

Pääsy tapahtuu yksinomaan SSHSiksi luotan johdonmukaisesti Avaimet staattisten salasanojen sijaan. Pelastustila pysyy valmiina rajoitetun ajan aktivoinnin jälkeen ja palaa takaisin paikalliseen käynnistyslaitteeseen seuraavan normaalin uudelleenkäynnistyksen yhteydessä. Työskentelen nopeasti, dokumentoin jokaisen vaiheen ja pidän toisen istunnon auki suurempia toimenpiteitä varten. En kirjoita arkaluonteisia tietoja bash-historiaan ja poistan väliaikaiset tiedostot käytön jälkeen. Onnistuneen palautuksen jälkeen poistan tilan käytöstä käyttöliittymässä uudelleen.

Kun olen aktivoinut tuottavan järjestelmän uudelleen, kierrätän käyttöoikeustiedot, poistan väliaikaiset pelastusavaimet, nollaan turhat pääkäyttäjän salasanat ja varmuuskopioin juuri luodut kokoonpanot. Kerään tarkastustiedot (kuka teki mitä ja milloin) ja dokumentoin poikkeamat vakioasetuksista. Näin estän hätätoimenpiteiden muuttumisen pysyviksi ja noudatan vaatimustenmukaisuusvaatimuksia.

Esimerkki: WordPress-palvelimen pelastaminen

Käynnistän pelastustilaan, kiinnitän järjestelmäosion ja varmuuskopioi Tietokanta per mysqldump ja wp-sisältö-hakemisto kanssa tar tai rsync. Tarkistan sitten tiedostojärjestelmän, nollaan käynnistyslataajan ja korjaan virheelliset PHP- tai NGINX-konfiguraatiot. Jos paketit ovat vioittuneet, käytän chrootia ja asennan riippuvuudet uudelleen. Jos tämä ei riitä, nollaan koneen uudelleen komennolla installmage ja palauta varmuuskopio ja kokoonpanot. Lopuksi tarkistan etusivun, kirjautumisen ja cronjobit.

Käytännössä kiinnitän huomiota InnoDB:n johdonmukaisuuteen (MySQL/MariaDB): Epäonnistumiset mysqld alussa, varmistan /var/lib/mysql ja suorita dumppi uudesta instanssista. Tyhjennän välimuistit (objektivälimuisti, sivuvälimuisti, OPCache) valikoivasti, asetan tiedostojen käyttöoikeudet johdonmukaisesti (löytää . -type d -exec chmod 755 {} ;, löytää . -type f -exec chmod 644 {} ;) ja tarkista open_basedir ja lataushakemistot. Poistan kriittiset lisäosat käytöstä testinä nimeämällä lisäosahakemiston uudelleen. Tämän jälkeen tarkistan PHP:n FPM-poolit, FastCGI:n aikakatkaisut, muistirajat ja NGINX/Apache-integraatiot. Lyhyt wp cron event run --due-now-tapahtuma --due-now (jos WP-CLI on käytettävissä) auttaa käsittelemään ruuhkia.

Parhaat käytännöt ylläpitäjille

Ennen syviä interventioita luon uuden Varmuuskopiointi ja suojatut avaintiedostot, kuten /etcjotta voin hypätä takaisin milloin tahansa. Jokaisesta vaiheesta tehdään lyhyt loki, joka auttaa minua myöhemmin tarkastuksissa tai uusien tapausten yhteydessä. Kun olen käynnistänyt tuottavan järjestelmän uudelleen, tarkistan palvelut, lokit, verkon ja seurannan perusteellisesti. Toistuvia tehtäviä varten luon pienen skriptisarjan komentosarjojen vakioimiseksi. Jos suunnittelet lisäsuorituskykyä tai uutta laitteistoa, voit luoda sopivia Vuokraa juuripalvelin ja siirtymisikkuna.

Minulla on myös valmiina runbook-tarkistuslista, joka sisältää vastuualueet ja eskalointireitit. Suunnitellut "pelipäivät" (kohdennetut vikasimulaatiot) harjoittelevat tiimiä hätätilanteita varten. Testaan säännöllisesti varmuuskopioita palautusnäytteenä - testaamatonta varmuuskopiota pidetään olemattomana. Lisäksi versioin järjestelmäkonfiguraatiot, jotta voin nopeasti tunnistaa erot "hyvän" ja "viallisen" tilan välillä.

Pilvi vs. oma: prosessin erot

Pilvipalvelimissa muutan käynnistystilan usein suoraan instanssin dialogissa ja käytän sarjakonsolia nopeisiin tarkistuksiin, kun taas dedikoitujen palvelimien kohdalla tarvitaan virrankatkaisu ja mahdollisesti kaistan ulkopuolinen pääsy. Pilvipalvelimen volyymit voidaan liittää kätevästi muihin instansseihin - tehokas tapa varmuuskopioida tietoja ilman seisokkiaikaa kyseisellä isännällä. Paljaassa metallissa kiinnitän enemmän huomiota asemien fyysiseen järjestykseen, erityisesti hankittaessa ylimääräisiä SSD-/NVMe-moduuleja. Molemmissa maailmoissa: Rescue on väliaikainen työkalu - suunnittelen tien takaisin normaaliin käynnistykseen hyvissä ajoin.

Vertailu: palveluntarjoajat ja pelastusjärjestelmä

Hyvän työnlaadun, nopean palautumisen lisäksi Laitteisto myös siististi integroitu Rescue-ominaisuus. Seuraavassa taulukossa annetaan tiivis yleiskatsaus toimintojen ja käsittelyn valikoimaan. Olen perustanut tämän saatavuuden, helppokäyttöisyyden ja tyypillisten ylläpitäjän työnkulkujen perusteella. Suositusluokitus kuvastaa käytännön käyttöäni tyypillisiin vikoihin. Painotus voi tietysti vaihdella käyttötarkoituksen mukaan.

Palveluntarjoaja	Rescue System saatavilla	Helppokäyttöisyys	Teho	Suositus
webhoster.de	Kyllä	Erittäin hyvä	Erittäin korkea	Testin voittaja
Hetzner	Kyllä	Erittäin hyvä	Korkea
Strato	Osittain	Hyvä	Medium
IONOS	Ei	Medium	Medium

Tarkistuslista: Vaiheiden järjestys hätätilanteessa

• Aktivoi Rescue, käynnistä uudelleen/virrankatkaisu, testaa SSH.
• Näytä laitteisto/tallennus: smartctl, lsblk, blkid, mdstat, lvm.
• Aktivoi matriisit/LUKS/LVM, tarkasta tiedostojärjestelmät vain lukuoikeuksin.
• Luo varmuuskopio (rsync/tar), sitten fsck/Korjaukset.
• Järjestelmä alle /mnt mount, bind mounts, chroot.
• Korjaa bootloader/initramfs, tarkista verkon asetukset.
• Testaa käynnistys, tarkista palvelut, tarkista valvonta/hälytykset.
• Deaktivoi Rescue, poista väliaikaiset avaimet, päivitä dokumentaatio.

FAQ Hetzner Rescue System

Voinko käyttää Tiedot pelastus, jos järjestelmä ei enää käynnisty? Kyllä, luen tietovälineitä suoraan pelastustilassa ja varmuuskopioin tärkeitä tietoja. Kansio tai kokonaisia osioita.

Kuinka kauan pelastustila pysyy aktiivisena? Aktivoinnin jälkeen järjestelmä on käytettävissä rajoitetun ajan ja siirtyy takaisin paikalliseen järjestelmään seuraavan säännöllisen uudelleenkäynnistyksen yhteydessä. Vene-laite, olen siksi suunnittelen nopeaa Menettely.

Toimiiko tämä pilvipalvelimilla ja omistetuilla palvelimilla? Kyllä, käynnistän tilan sekä dedikoitujen koneiden että pilvipalveluinstanssien kohdalla Hetzner Cloud.

Mitä teen, jos käynnistyslatauslaite on vahingoittunut? Asennan root- ja tarvittaessa EFI-käytön, chroot-käytön järjestelmään, suoritan grub-install, update-grub ja initramf:n uudelleenrakennus, sitten testaan uudelleenkäynnistyksen.

Miten toimin LVM/RAID:n kanssa? Kokoonpanen ensin mdraid:n, aktivoin LVM:n komennolla vgchange -ay ja kiinnitä sitten logiikkatietueet. Korjaukset tapahtuvat vasta varmuuskopioinnin jälkeen.

Voinko tallentaa vain yksittäisiä tiedostoja? Kyllä, mounttaan vain lukuoikeuksin ja kopioin valikoivasti konfiguraatioita, tietokantoja (dumpin kautta) tai hakemistoja - minimaalisen invasiivisesti ja nopeasti.

Keskeinen viesti

Kun Hetzner Rescue System, minulla on nopea työkalu, joka tunnistaa luotettavasti käynnistysongelmat, tiedostojärjestelmävirheet ja vahingoittuneet kokoonpanot. Aktivoin tilan, kirjaudun sisään SSH:n kautta, varmuuskopioin tiedot ja päätän sitten korjauksen tai uudelleenasennuksen välillä. Tämä säästää Aika hätätilanteessa ja vähentää käyttökatkokset minimiin. Jos sisäistät nämä muutamat vaiheet, voit käsitellä vaikeatkin käyttökatkokset rauhallisesti. Tällöin palvelimen toiminta voidaan suunnitella ja uudelleenkäynnistäminen on hallittua.