Aitch is back. Again.

Shotokan - sabato 26 Luglio

“Pensavamo foste morti.”
Gia’, lo pensavamo pure noi.

Facciamo un resoconto dei casini avvenuti in questo periodo, per far capire che realmente non siamo stati fermi 4 MESI per niente.

Analysis Of An Apocalypse

Aitch era hostato direttamente su di un VPS che gestivo direttamente (4 core, 2GB di RAM) Debian 6 pulito, NginX e poche altre cose.

A quanto pare sono stato uno dei pochi “fortunati” ad avere un bug con GRUB+RAID10, per cui ad un certo punto dopo un riavvio non partiva piu’ il VPS.
Faccio il backup a mano di /var/lib/mysql/ per non perdere l’ultimo articolo che stavo scrivendo e formatto direttamente il VPS.
Il backup per sicurezza lo copio su 3 vps diversi. Nella stessa webfarm. (yeah, my fault)

Ora, finisco di configurare il VPS appena formattato e me ne vado a dormire, era notte tarda.

La mattina mi sveglio, accendo il pc—– no, rettifico: non parte.
Sono in ufficio, sono le 8.30 e sono li’ a guardare lo schermo nero del mio portatile.

Oh dimenticavo: due settimane prima un cliente molto gentile aveva cosparso il mio portatile di veleno per formiche dato che l’avevo poggiato per 5 minuti su di un muretto mentre ero sopra un tetto a sistemare una antenna WiMAX.

Gia’.

Pensavo di averlo pulito adeguatamente con alcool ma a quanto pare qualcosa era andato storto.

Previsti gli “almeno 3 mesi di attesa” dell’assicurazione Asus, mi prendo un nuovo portatile.
Lo riconfiguro, installo tutti gli strumenti di lavoro e per un po’ tralascio Aitch. Troppe altre cose da sistemare.

Passa circa un mese, un mese e mezzo.

Decido di provare a ricaricare il backup sul VPS di Aitch ma qualcosa va storto.

Non riesco a raggiungere i 3 VPS dove avevo caricato i backup. Chiedo spiegazioni alla webfarm (qualcuno gia’ sta’ iniziando a capire di che webfarm si tratti?) ma noto che molti altri avevano questi problemi.
Diciamo circa.. 95% di packet loss inviando pacchetti di 64byte.

Pare che la compagnia fosse sotto DDoS, allora per un po’ tralascio ancora Aitch, non si riusciva a fare nulla in quel periodo da quei VPS.

La compagnia torna up, “stabile”, e per un po’ mi dimentico addirittura di ricaricare il backup (ormai erano passati due mesi e mezzo..)

Torna il tempo libero, torna la voglia di fare e decido di ripristinare Aitch.
Mi collego ad un VPS ma va estremamente lento.

“Mah, sara’ stato acceso per troppo tempo, li riavvio tutti per sicurezza—”

Morti. Tutti e 3 i VPS.

Vado in panico e cerco di capire cosa sta succedendo.
La webfarm (ora suvvia, dovreste avere capito chi. suggerimento? C@C) aveva notato una possibile vulnerabilita’ del loro sistema di storage, per cui si stava sbrigando a sostituire tutto con un sistema failproof.

Ovviamente il sistema di storage e’ collassato quando erano al 90% del completamento dell’operazione.

Ovviamente i miei 3 VPS erano nel 10%  degli storage non ancora failproof.

Su uno dei 3 VPS (NDA: il 2°) fortunatamente si riusciva ancora ad accedere alla console, era stralenta ma si accedeva.
Avvio in modalita’ di ripristino e ovviamente, crasha.

Avvio in init=/dev/sh con tutto montato RO.

Rimane connesso circa 2 minuti e collassa.

In 10h ho ripristinato ben 42MB di dati. Fortunatamente, tutti quelli che mi servivano.

Essendomi rotto pesantemente gli zeri binari ed avendo un server dedicato di un cliente che: “no.. mi son ricordato che non ne ho bisogno.” formatto tutto, ed inizio a ripristinare nel server dedicato.

Ah che gioia e che gaudio, che velocita’ (8 core @2GHz+ 16GB di RAM @1600MHz) comparato ad un VPS ero felicissimo.

Importo il backup e…

InnoDB: Error: auto-extending data file ./ibdata1 is of a different size
InnoDB: 512 pages (rounded down to MB) than specified in the .cnf file:
InnoDB: initial 640 pages, max 0 (relevant if non-zero) pages!

WTF.

Controllo. ibdata1 e’ di 8 MB, contro i 10MB definiti dal my.cnf

Controllo il checksum ed effettivamente e’ proprio cosi’, ibdata1 non e’ danneggiato ed e’ 8MB.

Allora modifico il my.cnf impostando ibdata1 a 8mb di size e finalmente…

140723 12:58:50 InnoDB: Error: tablespace size must be at least 10 MB
140723 12:58:50 [ERROR] Plugin 'InnoDB' init function returned error.
140723 12:58:50 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140723 12:58:50 [ERROR] Unknown/unsupported storage engine: InnoDB
140723 12:58:50 [ERROR] Aborting

Ma che ca.. Oh well.. allora mi state prendendo in giro.

Controllo in giro e nessuno sa’ come risolvere.
Inizio a studiarmi la configurazione di innodb e finalmente trovo:

The COMBINED size of data files must be at least 10MB.

AHA! Ci siamo dunque!

Ri-eseguo una installazione pulita di mysql, reimporto il tutto, salvo il backup di ibdata1 come ibdata2 lasciando l’ibdata1 creato in automatico dall’installazione pulita.

Aggiungo nel my.cnf:

innodb_data_file_path = ibdata1:10M;ibdata2:8M:autoextend

Salvo, avvio mysql e finalmente…

140723 14:23:54 InnoDB: Error: tablespace size must be at least 10 MB
140723 14:23:54 [ERROR] Plugin 'InnoDB' init function returned error.
140723 14:23:54 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
140723 14:23:54 [ERROR] Unknown/unsupported storage engine: InnoDB
140723 14:23:54 [ERROR] Aborting

…No, no no no no.

Lampo di genio momentaneo: sostituiamo ibdata1 con ibdata2.
Li sostituisco, li scambio nel my.cnf e avvio mysql incrociando le dita…
Funziona.

Gaudio e gioia.

Effettuo il dump .sql di tutti i database:

mysqldump -u root -p --all-databases > aitch.sql

Faccio pulizia della cartella /var/lib/mysql/, reinstallo sql pulito, reimporto il backup:

mysql -u root -p < aitch.sql

Aand… We’re online.

Defcon: 5

Non ho mai sofferto cosi’ tanto per un fottuto backup SQL.

Comunque si, vi vogliamo bene anche se siete stati adottati e nessuno vi ama.
A presto nuove news firmate Aitch.

P.s.: si, ora ho distribuito i backup su diversi altri PC.

P.p.s: si, ora Aitch. e’ su di un server dedicato.

Peace.

Theme made by Koala