Ho accidentalmente zippato tutto il mio server

Va bene, se qualcuno vuole giocare a Dio e fare miracoli, sono giù.

Quindi mi è stato affidato il compito di creare uno script che trovasse i file più vecchi di 6 mesi, li comprimesse e poi li cancellasse. Sulla mia strada nel fare script tihs ho eseguito questo:

find / -type f -mtime -400 ! -mtime -180 | xargs gzip blablabla

E questo ha dato a OGNI SINGOLO FILE un'estensione .gz. Ora l'ho sciolto non appena me ne sono accorto, ma era un po 'troppo tardi. Al completamento del comando nessuno dei miei comandi bash avrebbe funzionato perché la variabile $ PATH si svuotava. Ho provato molte cose prima di rendermi conto di quale fosse il problema.

Quindi dopo aver decompresso tutto ciò che non riesco ancora ad avviare. Sono riuscito a farcela in soccorso, dopo aver seguito le istruzioni online per:

root (hd0,0)
setup (hd0)
kernel (hd0,0)/boot/vml[...]
initrd (hd0,0)/boot/initrd.im[...]

Dopo che il mio Linux si avvia parzialmente ma mi dà i seguenti errori:

Begin : Running /scripts/init-bottom ... mount : mounting /dev on /root/dev failed : No such file or directory
mount: mounting /sys/ on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed : No such file or directory
Target filesystem doesn't have requrested /sbin/init.
No init found. Try passing init= bootarg.

Ho provato a riparare il filesystem, ho fatto il boot da 3 diversi LiveCD / dischi Rescue, ho eseguito boot-repair da 2 diversi dicsc. Ho forzato fscks ...

Sono davvero senza idee e HO BISOGNO di far avviare questo server almeno per poter recuperare i miei database SQL. Sono alla disperata ricerca di aiuto, pagherò anche se necessario.

Sono stato in agguato per 3 giorni consecutivi tutto il giorno per trovare una possibile soluzione e sono ancora allo stesso punto ... Aiuto per favore?

linux boot gzip

— Dexirian
fonte

se sono mysql db non è necessario avviare; in quel caso proverei a montare l'unità come slave e copiarla nella directory / var / lib / mysql

— user16081-JoeT

Installazione pulita su nuovi dispositivi di archiviazione. Montare il vecchio disco, trasferire i dati come richiesto. Scommetto che la riparazione non varrà la pena.

— Zoredache,

Questo è il punto in cui ripristini dal backup. E ricorda di non correre in giro facendo azioni non privilegiate come utente root la prossima volta.

— Magellano,

because of version differences,reinstallare con la stessa versione esatta. we have corruption issues,i tuoi dati potrebbero essere corrotti. Riparare il sistema in modo che sia avviabile, non ti aiuterà se i dati sono stati cestinati. Se il tuo comando gzip ha compresso i file del database mentre il database era corrotto, sembra inevitabile.

— Zoredache,

Se il tuo software DB era in esecuzione mentre eseguivi quei comandi, potresti non essere in grado di ripristinare i DB. Gzip avrebbe felicemente compresso il file, quindi lo avrebbe scollegato. Ma il tuo software DB aveva ancora il file aperto e stava eseguendo le modifiche. Non appena si è arrestato, il file è stato quindi rimosso.

— toppledwagon,

Risposte:

Ciò dipenderà dal fatto che i filesystem siano riparati abbastanza da permetterti di montare quelle partizioni da un LiveCD. Non preoccuparti di provare ad avviare il sistema. Innanzitutto, montare le partizioni e decomprimere tutti i file .gz. Questo ti darà copie funzionanti di init e binari di sistema. Quindi è possibile utilizzare grub per riparare il settore di avvio. Quindi avviare in modalità utente singolo e riaprire il filesystem. Se funziona, avrai un sistema in esecuzione. Avrai anche un sacco di file decompressi (come le pagine man) che in realtà dovrebbero essere compressi, ma è meglio che avere un sistema non avviabile.

Se non riesci a montare le partizioni da un LiveCD, sfortunatamente sei sfortunato. Nulla ripristinerà il tuo sistema a quel punto.

— Michael Martinez
fonte

In realtà ha funzionato come un fascino ... non posso ringraziarti abbastanza per questo! MySQL non si avviava ma non ho ancora fatto un - force fsck, speriamo che lo risolva! GRAZIE

— Dexirian,

Eccezionale. Sono contento che abbia aiutato.

— Michael Martinez,

La prima cosa che proverei è eseguire un ambiente LiveCD e provare solo a decomprimere tutto, sperando che possa riportare il sistema in uno stato avviabile. Nota: sarei preoccupato per il potenziale danneggiamento dei dati se il processo originale di gzip fosse interrotto.

Altrimenti, proverei a migrare il DB su un nuovo sistema come altri hanno suggerito, ma come hai riscontrato, potrebbero esserci problemi di dipendenza e lavoro intensivi che dovranno essere risolti individualmente.

— Bob Barker
fonte

Domanda rapida: non siamo sicuri del vecchio server di database SQL e il server più recente utilizza un diverso Linux Distro. Il server più recente esegue CentOS con WHM e il vecchio server era Debian / Unbuntu. Quindi la mia domanda è: come posso migrare efficacemente i miei database SQL senza corruzione e quant'altro?

— Dexirian,

Il consenso generale qui, che dovresti semplicemente montare il disco in un sistema funzionante e salvare i tuoi file, non è sbagliato. È la cosa sensata da fare. Ma l'altro modo è più divertente e molto educativo. Ho imparato molto combattendo per uscire da situazioni disordinate in cui altre persone si sarebbero semplicemente arrese e reinstallate da zero. (Non su un server da cui altre persone dipendono però ...)

Comunque, finora hai un initramfs (initrd) che gira. È un buon inizio. Ma non è possibile completare il passaggio a init perché init è ora init.gzforse? Per fare progressi, sarebbe utile sapere esattamente quale distribuzione Linux hai, quindi possiamo cercare quali strumenti sono disponibili nei suoi initramfs per l'uso di emergenza.

I messaggi di errore che hai presentato sembrano provenire dagli initramfs di Debian. Se è Debian, dovresti aver ricevuto un (initramfs)prompt della shell sulla riga successiva dopo l'ultimo errore. In tal caso, dovresti esaminare cosa sta succedendo con quei montaggi falliti. è /root/devmancante? ( /rootè dove dovrebbero essere montati i tuoi normali root fs durante l'esecuzione di initramfs)

Se non hai ricevuto il prompt della shell, ciò che No init found. Try passing init= bootarg.verrà dopo sarà interessante. Anche se non era altro che un cursore lampeggiante, questo è un indizio. Se sembra completamente congelato, prova ad ottenere alcune informazioni su quali processi sono ancora in giro usando magic sysrq o Ctrl + ScrollLock.

Debian initramfs consente anche di richiedere una shell in alcuni punti di riferimento speciali aggiungendo un break=parametro alla riga di comando del kernel. Ad esempio, per ottenere una shell prima della Running /scripts/init-bottomlinea, utilizzare break=bottom.

A parte: non so come il findcomando avrebbe potuto comprimere ogni file ... mi sembra corretto allo scopo di selezionare file tra 180 e 400 giorni.

Quando faccio un ls sotto / root non viene trovato nulla. Quindi posso prenderlo il montaggio fs non va bene all'avvio? Dove posso cambiarlo?

— Dexirian,

@Dexirian così hai avuto prompt di una shell (hai dovuto usare break=bottom?) ... sì, nel momento in cui sta cercando di montare /root/deve /root/proce /root/sys, /rootdovrebbe essere il vero e proprio filesystem di root. Deve esserci stato un messaggio di errore in precedenza, sul mancato montaggio. Hai incluso un root=parametro nella riga di comando del kernel? La mia memoria è un po 'confusa su questo punto, ma penso che il root (hd0,0)solo dice a grub dove trovare i suoi file di supporto, e devi ancora dire al kernel separatamente dove si trova il root.

Sì, ho usato root =, kernel = initrd = e setup =, non ho dovuto usare break = bottom. E non ho individuato un precedente messaggio di mount fallito, poiché scorre molto rapidamente

— Dexirian,

@Dexirian È disponibile lo scrollback della console? Maiusc + PgSu. E puoi montarlo da lui (initramfs) , qualcosa del genere mount -r /dev/sda1 /root? cat /proc/partitionsper vedere quali dischi sono disponibili.

Benvenuti nel mondo dell'amministrazione di sistema.

— Michael Martinez,