AUTS!

Sattumia ja tapahtumia — Näitäkin on nähty.


Tähdet oikeassa asennossa ja rautainen osaaja puikoissa

Asiakas oli pyytänyt puolitoista vuotta sitten erikoisvarmistuksen talteen vuodeksi. Varmistetut palvelimet oli tuhottu jo vuosi sitten.

Nyt tuli palautuspyyntö, tarvittaisiin kaksi palvelinta ja niiden Oracle kannat tuolta puolentoista vuoden takaa palautetuksi. Varmistuksiahan tietysti ei enää ollut tallessa pyydetyn talleajan päätyttyä, kuinka siis ratkaista tämä ongelma?

Sattumalta ao. varmistuksen sisältävää nauhaa oli käytetty testattaessa ns. cross-site-dr copy ominaisuutta. Tässä luodaan kahdesta täysin erilaisesta varmistusnauhasta (IBM E07 ja Oracle T1B) ns. pariteettinauha kolmanteen saliin (Oracle T1C). Näiden perusteella pystyttiin luomaan T1B/T1C nauhoilta alkuperäinen data jo ylikirjoitetulle E07 aseman nauhalle. Tämä ominaisuus on koekäytössä ja täysin uniikki tapa tehdä suojaus, vaikka kokonainen konesali olisi pois käytöstä. Suojaus mahdollistaa tietojen palautuksen, vaikka alkuperäistä dataa ei ole muihin konesaleihin sellaisenaan koskaan kopioitu.

Lisävaikeutta tuotti tarkempaan palautusajankohtaan tarvittavat Oracle archivelog -varmistukset, jotka olivat olleet vain kahden viikon talleajalla. Tähtien ollessa oikeassa asennossa oli ko. nauhoilta tullut kirjoitusvirheitä, minkä takia ne oli pistetty syrjään, eikä tietoja ollut ylikirjoitettu.

Rautaisen osaajan toimesta tuhottujen palvelinten varmistukset saatiin eheinä palautettua, vaikka käytännössä alkuperäistä varmistusdataa ei ollutkaan olemassa.


Pilvi on todellakin vain jonkun toisen konesali.

Asynkronisesta peilauksesta johtuen palveluja ei siirretty toiseen konesaliin.

”The decision was made to work towards recovery of data and not fail over to another datacenter, since a fail over would have resulted in limited data loss due to the asynchronous nature of geo replication.”

https://azure.microsoft.com/en-us/status/history/ (9/4 South Central US – Preliminary RCA)


Muistutus siitä että internettiin tallennettuun tietoon ei ole tiedon luojalla kontrollia

Pilvi näytti taas nurjan puolensa: Googlen bugi teki käyttäjien tiedostoista ”sopimatonta sisältöä”

http://www.tivi.fi/Kaikki_uutiset/pilvi-naytti-taas-nurjan-puolensa-googlen-bugi-teki-kayttajien-tiedostoista-sopimatonta-sisaltoa-6685051


Pilviteknologian käyttö – uusia epäjatkuvuuksia.

Varmista pilveen, mutta voitko palauttaa?

– 14.9.2015 Vodafone Italia ilmoitti, ettei Vodafone Cloud online -tallennuspalvelu ole enää käytössä 1. marraskuuta jälkeen
– 23.7.2015 Datablaze ilmoitti, ettei heidän varmistuspalvelunsa toimi enää marraskuun 2015 jälkeen
– 16.7.2014 Dell kertoi sulkevansa pilventallennus- ja varmistuspalvelun Dell DataSafe 11.7.2015
– 12.8.2014 F-Securen Online Backup -varmuuskopiointipalvelu ajettiin alas kesäkuun lopulla


Inhimillisiä erehdyksiä sattuu, palauttaminen on kovan tason ammattilaisuutta

“Unix palvelimen pääkäyttäjä luuli olevansa kotihakemistonsa alikansioissa ja antoi komennon rm –rf *
Odoteltuaan hetkisen hän huomasi, että jotain on vialla ja katkaisi komennon ctrl+C painalluksella.
Tarkastaakseen tilanteen hän antoi ls –l komennon. Mutta palvelin vastasi, että ao. komentoa ei ole olemassa?? Hän yritti siirtyä kansiosta toiseen cd komennolla, mutta palvelin vastasi, että ao. kansiota ei ole olemassa. Palvelin oli client server -sovelluksen tietokantapalvelin. Käyttäjät eivät kuitenkaan reagoineet tilanteeseen, koska itse sovellus toimi.

MultiCom aloitti tilanteen tutkimisen ja havaitsi, että käyttäjä oli ehtinyt poistaa juurilevyltä suurimman osan käyttöjärjestelmästä. Itse sovellus oli käynnissä ja tietokannat auki, mistä syystä sovellus edelleen toimi. Vieressä oli toinen vastaava palvelin ja kaikeksi onneksi rikkoutuneen palvelimen ftp- palvelinprosessi oli ladattuna ja sieltä saimme siirrettyä palvelimelle takaisin mm. mknod-ohjelman, jolla pystyimme luomaan laitetiedostot uusiksi. Samalla siirrettiin myös varmistusohjelmisto, jolla sitten palautimme käyttöjärjestelmän takaisin.

Koko tapahtumaketju tapahtui loppukäyttäjiltä huomaamatta. Seuraavana iltana käynnistimme palvelimen varmuuden vuoksi uudelleen, jotta saatoimme olla varmoja sen toimivuudesta.


Ymmärrä mitä sovelluksia palvelimessa on, ja kuinka ne pitää varmistaa

“Asiakkaalle tuli tarve palauttaa Oracle tietokanta. Palautus tehtiin tiedostojärjestelmävarmistukselta. Koska agenttia ei oltu käytetty, tietokanta oli rikkinäinen eikä suostunut käynnistymään. Lopulta tietokannan tiedot löytyivät parin kuukauden takaiselta käsin otetulta dumpilta.”


Ymmärrä riippuvaisuudet, onneksi oli viisas maintenance plan

“SQL DBA halusi pitää varmistukset omissa käsissään. Hän loi maintenance plan -toiminnot, jotka varmistivat tietokannat levylle ja oletti, että varmistushenkilöstö vie myöhemmin nämä tiedostot varmistuksiin. Valitettavasti sekä maintenance plan, että varmistus oli ajastettu tapahtumaan päällekkäin, ja uusin varmistus jäi aina vajavaiseksi. Kun lopulta palvelin rakennettiin palautuksen yhteydessä uusiksi, havaittiin, että viimeisin varmistus on rikkinäinen. Onneksi maintenance plan oli luotu tekemään erilliset dumppitiedostot eri päiville, joihin tukeutuen pystyttiin palautumaan kaksi päivää vanhaan tilanteeseen.”


Distribute IT –hakkerihyökkäys, toista puolustuslinjaa ei ollutkaan.

4800 kpl Australialaista web-liiketoimintaa pyyhkiytyi pois pysyvästi, kun palveluntarjoaja joutui cyber-hyökkäyksen/hakkeroinnin kohteeksi.

“…not only was the production data erased during the attack, but also key backups, snapshots and other information…” stated the company in its final blog post. – The Register, June 21, 2011


Globaalin palvelutuottajan ohjelmistovirhe, toinen puolustuslinja pelasti.

Ohjelmistobugi tuhosi 40.000 sähköposti-tiliä muutaman minuutin aikana. Tilit pystyttiin palauttamaan “toisen puolustuslinjan” ansiosta.

“Since the tapes are offline, they´re protected from such software bugs”.