Avvio del sistema di salvataggio Hetzner - guida passo-passo per gli amministratori di server

Vi mostrerò come avviare il sistema di soccorso hetzner in pochi minuti, come SSH accedere e inserire il proprio Server riparazione in modo mirato. Questa guida vi accompagna passo dopo passo dall'attivazione al ripristino, compresi i controlli del file system, i backup e la reinstallazione.

Punti centrali

I seguenti aspetti chiave vi aiuteranno a iniziare e a lavorare in modalità di salvataggio senza alcuna deviazione.

• Inizio del salvataggioAttivazione in Robot o Cloud, quindi riavviare.
• Accesso SSHAccedere con chiave o password e diritti di root.
• Analisi degli erroriControllare fsck, log, partizioni.
• Backup dei datirsync, tar, scp per backup veloci.
• Nuova installazioneinstallimage per sistemi nuovi.

Cosa fa il sistema di salvataggio

Il Rescue System carica un ambiente Linux indipendente nella memoria di lavoro e mi fornisce l'accesso immediato ai file di Radice-anche se il sistema installato Sistema operativo fallisce. Eseguo l'avvio indipendentemente da boot loader difettosi, pacchetti danneggiati o configurazioni errate. Questo mi permette di controllare i file system, recuperare i dati, analizzare i log e riavviare i servizi. L'ambiente rimane snello, ma offre tutti gli strumenti importanti per la diagnostica e il ripristino. Questo mi permette di mantenere il controllo, anche se il sistema regolare va completamente in tilt.

L'aspetto pratico è che l'ambiente di salvataggio è volutamente volatile: le modifiche scompaiono dopo il riavvio, il che significa che posso testare in modo sicuro. Se necessario, installo strumenti temporanei (ad esempio smartmontools, mdadm, lvm2, btrfs-progs o xfsprogs) senza modificare il sistema produttivo. La versione del kernel è moderna e supporta l'hardware più recente, compresi NVMe, UEFI, GPT, RAID software (mdraid), LVM e crittografia LUKS. Questo mi permette di coprire anche configurazioni di storage complesse e di isolare anche rari modelli di errore in modo riproducibile.

Requisiti e accesso

Per iniziare, ho bisogno di accedere all'interfaccia del cliente e al mio Chiavi SSH o di un temporaneo password. Gestisco comodamente i sistemi dedicati tramite il Robot Hetznermentre controllo le istanze nel cloud tramite la console. Entrambe le interfacce offrono una chiara opzione per attivare la modalità di ripristino. Verifico in anticipo l'IP corretto del server, la disponibilità dell'IPv6 e, se necessario, le funzioni fuori banda per il ripristino. Questa preparazione riduce notevolmente il tempo di inattività.

Quando accedo a SSH per la prima volta, confermo consapevolmente la nuova impronta digitale e aggiorno la voce Known Hosts, se necessario, in modo che le connessioni successive non falliscano a causa di avvisi. Per i team, memorizzo chiavi aggiuntive specificamente per l'operazione di salvataggio e le rimuovo nuovamente dopo il completamento. Se è disponibile solo una password temporanea, la cambio subito dopo l'accesso e la sostituisco con Key-Auth - disattivo sempre i login con password alla fine del lavoro.

Attivazione del sistema di salvataggio - passo dopo passo

Apro la finestra dei dettagli del server, seleziono l'opzione "Rescue" e imposto l'architettura su linux64 per i sistemi attuali, poi deposito il mio Chiave SSH. A seconda della situazione, avvio solo la modalità di ripristino e attivo il riavvio separatamente oppure utilizzo "Attiva ripristino e ciclo di alimentazione" per un riavvio diretto. Se la macchina si blocca, eseguo un hard reset tramite l'interfaccia. Dopo l'avvio, l'interfaccia mostra una password di root temporanea se non ho inserito una chiave. Non appena il server si avvia, risponde a SSH e posso iniziare.

In situazioni complesse, pianifico una sequenza chiara: attivazione, ciclo di alimentazione, test di accesso SSH, quindi avvio della risoluzione dei problemi. Un ciclo di alimentazione manuale può essere più necessario sui server dedicati, mentre le istanze cloud di solito passano immediatamente alla modalità di ripristino. Importante: dopo una riparazione riuscita, disattivo nuovamente la modalità di ripristino in modo che la macchina si riavvii dal disco rigido locale.

Connessione SSH e primi controlli

Mi collego tramite SSH con ssh root@ e controllare prima la rete, i supporti dati e i registri per avere una rapida panoramica del sistema. Stato. Con ip a e ping Verifico la disponibilità; journalctl --no-pager -xb o i file di registro sui dischi montati mostrano i messaggi di errore più recenti. I comandi lsblk, blkid e fdisk -l fornire chiarezza sul layout e sui file system. Per il RAID uso cat /proc/mdstat e mdadm --detail per la condizione. Per gli indicatori hardware iniziali smartctl -a e un breve hdparm -Tt-Test.

LVM, RAID, LUKS e file system speciali

Molti server utilizzano LVM, RAID software o crittografia. Per prima cosa attivo tutti i livelli pertinenti:

• mdraid: mdadm --assemble --scan mostra gli array esistenti; controllo lo stato con cat /proc/mdstat.
• LUCCI: apro volumi criptati con cryptsetup luksOpen /dev/.
• LVMCon vgscan e vgchange -ay Attivo i gruppi di volumi e li vedo tramite lvs/vgs/pvs.

Con Btrfs, faccio attenzione ai subvolumi e li monto specificamente con -o subvol=@ rispettivamente -o subvolid=5 per il livello superiore. Controllo XFS con xfs_repair (mai su volumi montati), mentre Ext4 è classicamente usato con fsck.ext4 -f è riorganizzato. Mi oriento sul GUID/UUID da blkidperché i nomi dei dispositivi per NVMe (/dev/nvme0n1p1) e può variare al variare dell'ordine. Correggerò il /etc/fstab.

Riparazione del file system e backup dei dati

Prima di riparare, eseguo il backup di importanti Dati con rsync, scp oppure catrame a un target esterno o a un target locale Backup-directory. Per i controlli uso fsck solo sulle partizioni non montate, ad esempio fsck -f /dev/sda2per correggere le incongruenze in modo pulito. Monto quindi il sistema sotto /mntad esempio con montare /dev/sda2 /mnte collegare i sottopercorsi come /proc, /sys e /dev quando voglio fare il chroot. I singoli file di configurazione come /etc/fstab o le impostazioni di rete direttamente nel sistema montato. Procedendo con cautela, evito danni conseguenti e riduco al minimo i tempi di inattività.

Per ottenere backup affidabili, mi affido a comandi ripetibili: rsync -aHAX --info=progresso2 riceve diritti, hardlink, ACL e xattr. Se la linea è debole, la strozzo con --bwlimit e parallelizzare la compressione con tar -I pigz. Se necessario, immagino i supporti di dati critici e difettosi in blocchi con ddrescue per spostare il lavoro logico su un'immagine. Controllo attentamente i sistemi Btrfs con btrfs check --readonly e utilizzare btrfs scrubper rilevare gli errori silenziosi. XFS spesso richiede una riparazione off-mount in caso di incongruenze (xfs_repair) - Eseguo sempre prima il backup della partizione.

Riparazione UEFI/BIOS, GPT/MBR e bootloader

Molti problemi di avvio sono causati dall'interazione tra firmware, schema di partizione e boot loader. Innanzitutto chiarisco se il server si avvia in modalità UEFI o BIOS legacy (ls /sys/firmware/efi). Con UEFI monto la partizione EFI (tipica /dev/sdX1 oppure /dev/nvme0n1p1) a /mnt/boot/efi. Poi ho inserito il sistema:

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

Ho reinstallato il bootloader in modo appropriato (grub-install al dispositivo corretto) e rigenerare la configurazione e initramfs: aggiornare-grub e update-initramfs -u -k tutti (per i sistemi basati su dracut dracut -f). Se l'ordine dei dispositivi non è corretto, utilizzo l'opzione /etc/default/grub UUID e controllo /etc/fstab per le voci corrette. Quando si cambia GPT/MBR, controllo se esiste una partizione di avvio BIOS (per GRUB/BIOS) o una partizione di sistema EFI valida.

Insidie della rete nel salvataggio

I problemi di rete sono spesso il motivo per cui i servizi sono "spariti". In Rescue controllo lo stato dei collegamenti (collegamento ip), percorsi (ip r) e la risoluzione DNS (stato di resolvectl rispettivamente cat /etc/resolv.conf). Eseguo il test su IPv4 e IPv6 separatamente (ping -4/ping -6). Per i server con bridge o bonding, l'ordine delle interfacce nel sistema produttivo può differire dall'ambiente di salvataggio. Prendo nota degli indirizzi MAC e li mappo correttamente. Se il sistema di produzione utilizza Netplan, verifico che le interfacce /etc/netplan/*.yaml e girare dopo il chroot generare netplan e applicare netplan su. Per i classici /etc/network/interfaces-setup, faccio attenzione ai nomi coerenti delle interfacce (nomi prevedibili vs. nomi di interfaccia). eth0).

Reinstallare il sistema operativo

Se le riparazioni non hanno più senso, resetto il sistema con installare l'immagine completamente nuovo, risparmiando così preziosi Tempo. Lo strumento mi guida nella selezione della distribuzione, del partizionamento e del boot loader. Includo i miei file di configurazione e le chiavi SSH nell'installazione in modo che il primo avvio avvenga senza problemi. Dopo l'installazione, avvio il server come di consueto e controllo i servizi, il firewall e gli aggiornamenti. Infine, rimuovo la modalità di salvataggio in modo che il prossimo avvio avvenga nuovamente dal supporto dati locale.

Per le nuove installazioni uso deliberatamente montaggi basati su UUID per escludere problemi di ordine dei dispositivi in seguito. Per le configurazioni RAID, faccio creare gli array fin dall'inizio e controllo lo stato di ricostruzione prima di ripristinare i dati. Se si distribuiscono sistemi simili in modo ricorrente, si lavora con modelli di immagine di installazione predefiniti e una chiara logica di partizionamento (root, partizione dati separata, swap, EFI se necessario). Dopo il primo avvio, aggiorno i sorgenti dei pacchetti e i kernel, attivo gli aggiornamenti automatici della sicurezza e eseguo le fasi di hardening di base.

Sicurezza, finestra temporale e ricaduta

L'accesso avviene esclusivamente tramite SSHpertanto mi affido costantemente a Chiavi al posto delle password statiche. La modalità di salvataggio rimane pronta per un tempo limitato dopo l'attivazione e ritorna al dispositivo di avvio locale al successivo riavvio normale. Lavoro rapidamente, documento ogni passaggio e tengo aperta una seconda sessione per gli interventi più importanti. Non scrivo dati sensibili nelle cronologie di bash e cancello i file temporanei dopo l'uso. Dopo un ripristino riuscito, disattivo nuovamente la modalità nell'interfaccia.

Dopo aver riattivato il sistema produttivo, ruoto i dati di accesso, rimuovo le chiavi di salvataggio temporanee, resetto le password di root superflue ed eseguo il backup delle configurazioni appena generate. Raccolgo informazioni di audit (chi ha fatto cosa e quando) e documento le deviazioni dalla configurazione standard. In questo modo evito che le misure di emergenza diventino permanenti e mi adeguo ai requisiti di conformità.

Esempio: Salvataggio del server WordPress

Eseguo l'avvio in modalità di ripristino, monto la partizione di sistema ed eseguo il backup di Banca dati per mysqldump e il wp-content-directory con catrame oppure rsync. Quindi controllo il file system, resetto il boot loader e correggo le configurazioni errate di PHP o NGINX. Se i pacchetti sono danneggiati, uso chroot e reinstallo le dipendenze. Se questo non è sufficiente, resetto la macchina con installare l'immagine e ripristino il backup e le configurazioni. Infine, verifico il frontend, il login e i cronjob.

In pratica, faccio attenzione alla consistenza di InnoDB (MySQL/MariaDB): fallisce mysqld all'inizio, assicuro il /var/lib/mysql ed eseguire il dump da un'istanza nuova. Svuoto le cache (object cache, page cache, OPCache) in modo selettivo, imposto i permessi dei file in modo coerente (trova . -type d -exec chmod 755 {} ;, trova . -type f -exec chmod 644 {} ;) e controllare open_basedir e le directory di caricamento. Come test, disattivo i plugin critici rinominando la directory dei plugin. Poi controllo i pool FPM di PHP, i timeout di FastCGI, i limiti di memoria e gli include di NGINX/Apache. Un breve wp cron event run --due-ora (se WP-CLI è disponibile) aiuta a elaborare gli arretrati.

Le migliori pratiche per gli amministratori

Prima di effettuare interventi profondi, creo un nuovo Backup e file chiave sicuri come /etcin modo da poter tornare indietro in qualsiasi momento. Ogni passo viene registrato in un breve registro, che mi aiuta in seguito con gli audit o i nuovi incidenti. Dopo il riavvio del sistema produttivo, controllo accuratamente i servizi, i registri, la rete e il monitoraggio. Per le attività ricorrenti, creo un piccolo set di script per standardizzare le sequenze di comandi. Se state pianificando prestazioni aggiuntive o nuovo hardware, potete creare un set di script adeguato. Noleggiare un server root e la finestra di migrazione.

Ho anche una lista di controllo del runbook pronta, che contiene le responsabilità e i percorsi di escalation. Le "giornate di gioco" pianificate (simulazioni di guasti mirati) addestrano il team alle emergenze. Collaudo regolarmente i backup come campione di ripristino: un backup non testato è considerato inesistente. E modifico le configurazioni del mio sistema in modo da poter riconoscere rapidamente le differenze tra lo stato "buono" e quello "difettoso".

Cloud vs. dedicato: differenze nel processo

Nel cloud, spesso modifico la modalità di avvio direttamente nella finestra di dialogo dell'istanza e utilizzo la console seriale per controlli rapidi, mentre sui server dedicati è necessario un ciclo di accensione ed eventualmente un accesso fuori banda. I volumi del cloud possono essere comodamente collegati ad altre istanze: un modo efficiente per eseguire il backup dei dati senza tempi di inattività sull'host interessato. Su bare metal, faccio più attenzione all'ordine fisico delle unità, soprattutto quando acquisto moduli SSD/NVMe aggiuntivi. In entrambi i mondi: Rescue è uno strumento temporaneo - pianifico il ritorno all'avvio normale in tempo utile.

Confronto: fornitori con sistema di soccorso

Oltre a una buona qualità del lavoro, un recupero veloce Hardware anche un'integrazione pulita Salvataggio-caratteristiche. La tabella seguente fornisce una panoramica compatta della gamma di funzioni e della gestione. Ho basato questo giudizio sulla disponibilità, sulla facilità di accesso e sui flussi di lavoro tipici dell'amministrazione. La valutazione "Raccomandazione" riflette il mio uso pratico per i guasti tipici. La ponderazione può naturalmente variare a seconda dell'uso previsto.

Fornitore	Sistema di salvataggio disponibile	Facilità d'uso	Prestazioni	Raccomandazione
webhoster.de	Sì	Molto buono	Molto alto	Vincitore del test
Hetzner	Sì	Molto buono	Alto
Strato	Parzialmente	Buono	Medio
IONOS	No	Medio	Medio

Lista di controllo: Sequenza di passi in caso di emergenza

• Attivare il salvataggio, attivare il riavvio/ciclo di alimentazione, testare SSH.
• Visualizzazione di hardware/storage: smartctl, lsblk, blkid, mdstat, lvm.
• Attivare array/LUKS/LVM, ispezionare i file system in sola lettura.
• Creare un backup (rsync/tar), poi fsck/Riparazioni.
• Sistema sotto /mnt mount, bind mount, chroot.
• Riparare bootloader/initramfs, controllare la configurazione di rete.
• Test di avvio, verifica dei servizi, controllo del monitoraggio e degli allarmi.
• Disattivare Rescue, rimuovere le chiavi temporanee, aggiornare la documentazione.

FAQ Sistema di salvataggio Hetzner

Posso usare il mio Dati di salvataggio se il sistema non si avvia più? Sì, leggo i supporti dati direttamente in modalità di ripristino ed eseguo il backup dei dati importanti. Cartella o intere partizioni.

Per quanto tempo rimane attiva la modalità di salvataggio? Dopo l'attivazione, il sistema è disponibile per un tempo limitato e torna al sistema locale al successivo riavvio regolare. Barca-dispositivo, sto quindi pianificando una rapida Procedura.

Funziona per i server cloud e dedicati? Sì, avvio la modalità sia per le macchine dedicate che per le istanze del cloud nella cartella Nuvola di Hetzner.

Cosa faccio se il bootloader è danneggiato? Monto root e se necessario EFI, faccio il chroot nel sistema, eseguo grub-install, aggiornare-grub e una ricostruzione di initramf, poi provo il riavvio.

Come faccio a gestire LVM/RAID? Per prima cosa assemblo mdraid, attivo LVM con vgchange -ay e poi montare i volumi logici. Le riparazioni avvengono solo dopo un backup.

Posso salvare solo singoli file? Sì, monto in sola lettura e copio selettivamente le configurazioni, i database (tramite dump) o le directory - in modo poco invasivo e veloce.

Messaggio centrale

Con il Hetzner Rescue System, ho uno strumento rapido che identifica in modo affidabile i problemi di avvio, gli errori del file system e le configurazioni danneggiate. Attivo la modalità, accedo tramite SSH, eseguo il backup dei dati e poi decido se riparare o reinstallare. In questo modo si risparmia Tempo in caso di emergenza e riduce i tempi di inattività al minimo indispensabile. Se si interiorizzano questi pochi passaggi, è possibile gestire con calma anche le interruzioni più difficili. In questo modo è possibile pianificare il funzionamento del server e controllare il riavvio.