"Redmond, valami baj van ..."

Microsoft, Windows

Részletek itt.

( pilisig | 2019. 02. 01., p – 11:10 )

Na az üzemeltető niggáknak is már csak kettőt kell aludni húsvétig. :D
"Joe, van mentésünk?" "Hátőőő"

-pilisig-

Ez ismét a "felhő" dicsérete. Mármint, hogy a fasz tudja, hogy valóban van-e mentés, az mennyire konzisztens, mennyire naprakész és mennyire tudja a szolgáltató időre, jól, pontosan visszaállítani.

Ha magam kezelem, azért nagyjából képben vagyok vele (meg az esetleges gyengeségeivel is).

--
trey @ gépház

Szerintem sokan elhiszik, különösen azok akiknek reccsent meg már winchestere a 2000-es években. Felhőkben ahhoz képes eddig jóval kevesebb hasonló incidens történt. Az adataid olcsóbban vannak nagyobb biztonságban. Inkább olyan bakiktól kell tartani amik saját háttértáron nem fordulhatnak olyan könnyen elő, mint hogy publikusan hozzáférhetővé válnak a felhős fájljaid, Microsoft Azure-on különösen. :)
Ezért titkosítás eléggé javallott felhő mellett.

Hát itt most pont a mentés vizsgázott. Letörlődött egy hibás automatizmus miatt x db adatbázis. Visszaállitották mindenkinek a mentést, ami legrosszabb esetben 5 perccel régebbi, mint a törlési időpontja. Aki ezt elfogadja, az használja igy, aki nem, az pedig nyit egy support ticketet és megpróbálják az adatbázis logból visszaszedni a hiányzó tranzakciókat.

A törlődés nagyon gáz, viszont maga a backup rendszer szerintem jól vizsgázott. Nagyon sokan örülnének, ha egy ilyen katasztrófa után bármely pillanatban lenne nekik egy 5 percnél nem régebbi mentésük az adataikról. (nyilván aki tuti biztosra ment az eleve replikált máshova is és nincs problémája, akár felhő akár helyi rendszer)

Nem! Ez a Microsoft dícsérete.
A felhővel nincs semmi baj, csak normális rendszer kell alá.
Őszintén szólva nem lepne meg ha szép csendben a Microsoft O~S-re cserélné az Azure alatti rendszert szép csendesen ezután az incidens után.
Google cloud köszöni szépen és jól működik.
Amazon AWS köszöni szépen és jól működik.
Provlémák a Microsoft feljőjével vannak és ez már nem az első eset.
Már az sem lepne meg ha 5 év múlva Linux alapon menne a Microsoft desktop és szerver operációs rendszere is.

A baj csak az, hogy sem a Google sem az AWS nem tud garantálni egyébként semmit, és náluk is bármikor beüthet a krach.

Adatmentés. Nemrég megtaláltak egy 100 éves filmfelvételt jó minőségben, amin látható 3 perc Ady Endre temetéséről.
Szenzációs!

Hol lesznek a mai felvételek, adatok 100 év múlva?

--
robyboy

Ebben igazad van! De a Western Digital, Seagate, Kingston, Crucial sem garantálja, hogy holnap is eléred az adataidat a háttértáraikon. Történhetnek olyan események, villám, tűz vagy tüzet megelőző de mindent eláztató tűzvédelem, amikor a RAID sem segít.
Volt példa arra is, hogy egymás után döglöttek meg az egy szériából származó háttértárak gyártási hiba miatt. Ez a nagyobb szervezetet ugyanúgy érinti mint a kis egyéni raid rendszereket.
A valóban jó adatbiztonsághoz kell a több helyszín és leginkább a szalagos backup. Ez így együtt már szép összeg annak ellenére hogy a legolcsóbb pénz/GB adathordozótípus ma is a streamer szalag, plus a vele járó rendszeres munka.

Mint technológiának a felhőnek nincs alternatívája jelenleg, annyival hatékonyabb. A kérdés innentől, hogy saját felhő vagy külsős cég felhője. A nyílt forráskódnak hála, ownCloud-tól O~S-ig van választás. De saját felhőhöz is kell a jó backup stratégia.

Jeleg az arany középút szerintem két külsős felhő használata különböző szolgáltatóknál.
Ha nem bízol a privacy-ban (szerződés szerint a fizetsz nincs megfigyelés) akkor csak adattárolás titkosítottan. Ez esetben az adattároláson kívüli felhős szolgáltatásokról le kell mondanod és ezt az oldalt magadnál kell megoldani. Szerencsére erre is egyre jobb opensource megoldások vannak.

"Adatmentés. Nemrég megtaláltak egy 100 éves filmfelvételt jó minőségben, amin látható 3 perc Ady Endre temetéséről.
Szenzációs!"

De 100 évig senki sem látta. Ez alatt sokan leélték a komplett életüket anélkül, hogy esélyük lett volna Ady Endre temetéséről készült filmfelvétel megtekintésére.
Hofi Géza temetéséről készült filmfelvételt bárki meg tudja nézni a világ bármely pontjáról. Ez is előny azt ne felejtsük el.
Ami a hosszú távú adattárolást illeti. Pozitív példa: ma is megtalálhatóak 70-es években írt programkódok, akkor fontosnak és megőrzésre érdemesnek tartott állományok. Sőt korábbról is.
Negatív példa: Babylon-5 fimsorozat, amit jövőbiztosan 16:9-ben vettek fel és a nagy számú digitális animációt is archiválták. De ezeknek a mentéseknek jó részét elkutyulták az idők során. Ami megvan azzal sem tudnak mit kezdeni mert a hiányos dokumentáció miatt nem tudnak mit kezdeni a meglevő fájlokkal annyira egyedi cgi megoldással dolgoztak.
Ezért nem tudtak végül Bluray HD kiadást készíteni a sorozatból.

A magyar hangarchívumnál úgy 8 éve megvizsgálták a digitalizáció lehetőségét. Akkor elvetették és maradtak az analóg matrica gyártásnál. Szóval nyilván sok igazság van abban is amit írsz.
Mindig meg kell találni a optimális megoldást időállóság, karbantartási idény, elérhetővé tétel között. Sok esetben különböző megoldások kombinációja vezet a legjobb eredményre.

Nem zárható ki egy Blade Runner 2049 -féle "Blackout" esemény a jövőben, amikor masszív digitális adatveszteség történik globálisan.

+1 Pont ez az, aminek a költsége felhő esetén minimális volna. A georedundanciát "csak" jól kell megtervezni, és nagyon jól skálázódik utána, nem lesz tőle drágább. Egyesével pedig ezt a baromi drága megcsinálni. Ha ezt tudná a felhő, akkor érné meg. Ha a felhő csak egy "bazinagy" szerverközpont, az annyira nem vonzó.

Emlékszem, hogy amikor elkezdték a felhőt promózni, akkor még hitegettek ilyesmivel, hogy mennyire redundáns lesz, aztán ezek alábbhagytak. Inkább olcsón akarnak sokat kaszálni :-)

A felhő szolgáltató egy telephelynek is tekinthető:
- mint most láttuk, van egy olyan komplex vezérlési rétege (helyi infrastruktúrában ez tipikusan hiányzik), amiben bármikor történhet hiba és előfizetői adatvesztéssel járhat. Van üzleti ügyfelem, akinek O365 dolgai vesztek oda, most ez az adatbázis mizéria, de nemrégen a Google is lapított emlékeim szerint valamilyen illetéktelen behatolásról (nem kapott nagy hírverést; lehet, hogy nem történt számot tevő kár, de akár történhetett is volna)
- mint szeptemberben láttuk Azure kapcsán, "alapvető" problémák is előfordulhatnak (hibás adatközpont tervezés).
- megszűnhet: ennek nagyok esetén kicsi az esélye, de az egyszerűbb szolgáltatásokat is ide lehetne érteni (pl. korábban rendőrség kivonult warez miatt és lefoglalt szervereket, ezen szerverek kapcsán esetleg üzleti ügyfelek is érintettek lehettek)

Normál infrastruktúrában mit kell csinálni egy telephellyel? Menteni. Miként kell menteni? Mindenki eldönti saját maga, hol van a műszaki minőség és a pénzügyi mennyiség (kockázat) közös nevezője.

Keresett már meg ügyfél teljesen önszántából: nem nyugodt, hogy minden levelük csak a Google-nél van meg, jó lenne valami mentési megoldás. Sokat nem akarnak rá áldozni, de nyugodtabb lenne. Lett és megnyugodott.
És szaporodnak a felhő mentő szoftverek.

Lehet volt a Googlenél is, de ilyenek mint a Microsoftnál nem volt. Ráadásul már nem ez az első eset. Ekkora bakit még a Google sem tudna a szőnyeg alá sörögetni.
Az egyik korábbi Microsoft okostelefonos próbálkozásnak is egy nagy adatvesztés vetett véget:
http://www.bbc.co.uk/blogs/technology/2009/10/the_sidekick_cloud_disast…

Annyi baj van az Azure-ral, hogy én komolyan nem merek számolni vele mint felhős megoldással.

"Keresett már meg ügyfél teljesen önszántából: nem nyugodt, hogy minden levelük csak a Google-nél van meg, jó lenne valami mentési megoldás. Sokat nem akarnak rá áldozni, de nyugodtabb lenne. Lett és megnyugodott.
És szaporodnak a felhő mentő szoftverek."

Fizetett a Gmail használatáért? Mert ez a első mielőtt drága egyedi megoldásokhoz nyúl valaki.
Googlenél pont számtalan jó megoldás létezik erre, kezdve a Google takeout-tal, ami értelmes formátumba teszi letölthetővé a felhasználói adatokat szolgáltatásonként. Persze gmail backupra jó egy sima imap is.

Google-nél dolgozol? :-)

Probléma mindenhol lehet. A legjobb helyeken is. Van, ahol megússzák kisebb problémákkal, akár kevesebbel, de garancia semmire nincs, legfeljebb valószínűségek, amibe sok minden belefér.

"Fizetett-e a Gmailért?" Első felhasználók között voltak, így még ingyenesen használják, mostanában fognak átmenni fizetősbe. De a történet szempontjából teljesen közömbös, mert nem emiatt aggasztotta. Hiába fizet, ha egyszer elvesznek az adatok (teljesen mindegy, hogy mi az oka).

Nekem úgy tűnik, hogy elviekben mozogsz csak üzemeltetésben, nem gyakorlatban, a felhőt inkább evangelizálod, mint alkalmazod:
- takeouttal nem fogsz naponta vagy akár hetente kézzel játszani minden felhasználóra, tudomásom szerint nem automatizálható, ráadásul mindig mindent menteni nem célszerű
- IMAP: akkor lehet jó, ha az IMAP tükrödet mented, de még akkor is macerás egyenként kezelni a fiókokat (azaz megvalósítasz egy helyi levelező szerver mentést, amitől szabadulni akartál). Ugyanis ha olyan hiba van, hogy eltűnnek a levelek, akkor az IMAP tükörből is el fognak tűnni a levelek.

Másik hozzászólásodban írod, hogy leghatékonyabb technológia a felhő. A felhő nem technológia, hanem szolgáltatási modell. A hatékonyságot elég nehéz általánosan mérni. Az valószínű (de nem biztos), hogy néhány fős cégnek nem éri meg saját levelező szervert üzemeltetni, más hasonló szolgáltatások is vannak, de ha mindent bedobsz a kalapba, számolsz, akkor más is jöhet ki.

""Fizetett-e a Gmailért?" Első felhasználók között voltak, így még ingyenesen használják, mostanában fognak átmenni fizetősbe. De a történet szempontjából teljesen közömbös, mert nem emiatt aggasztotta. Hiába fizet, ha egyszer elvesznek az adatok (teljesen mindegy, hogy mi az oka)."

Egyáltalán nem mindegy. Más stratégiába vannak a fizetős és ingyenes ügyfelek, adattárolás, adatkezelés szempontból. Fizetős Google ügyfelek adataival nem kufárkodik a Google, egy esetleges krach esetén sokkal nagyobb valószínűséggel maradnak meg a fizetős ügyfelek adatai mint az ingyenes felhasználóké. Bár a pontos részleteket sosem fogja nyilvánosságra hozni a Google.

"takeouttal nem fogsz naponta vagy akár hetente kézzel játszani minden felhasználóra, tudomásom szerint nem automatizálható, ráadásul mindig mindent menteni nem célszerű"

Automatizálható, én megcsináltam. Egyedi megoldás.
Ha érdekel egy tipp, tervezés közben érdemes szolgáltatásonként megvizsgálni milyen szolgáltatásról van szó. Nem mindig az az optimális ha brute-force nekiesünk a takeout-nak.
Differential mentés aránylag egyszerűen megoldható incrementallal már nem biztos, hogy érdemes vesződni. Természetesne jó lenne ha ezt a Google Takeout saját oldalán tudná. Sávszélt is spórolna ezzel mindenki.

"IMAP: akkor lehet jó, ha az IMAP tükrödet mented, de még akkor is macerás egyenként kezelni a fiókokat (azaz megvalósítasz egy helyi levelező szerver mentést, amitől szabadulni akartál). Ugyanis ha olyan hiba van, hogy eltűnnek a levelek, akkor az IMAP tükörből is el fognak tűnni a levelek."

Természetesen imap tükör nem archiválási megoldás. A helyi imap tökörről készített rendszeres backup már az. Pláne ha az szalagra kerül.
De lehetne más megközelítéssel ZFS snapshotokban is gondolkodni.

"Másik hozzászólásodban írod, hogy leghatékonyabb technológia a felhő. A felhő nem technológia, hanem szolgáltatási modell. A hatékonyságot elég nehéz általánosan mérni. Az valószínű (de nem biztos), hogy néhány fős cégnek nem éri meg saját levelező szervert üzemeltetni, más hasonló szolgáltatások is vannak, de ha mindent bedobsz a kalapba, számolsz, akkor más is jöhet ki."

Cloud computing, cloud technology, eléggé széles körben használjuk ezeket a szóösszetételeket. De ne indítsunk megint n+1 nyelvészvitát.
Egy levelezőszerver még nem felhő. A freemail nem felhős szolgáltatás volt (már jó ideje nem követem mit bénáznak ott, szóval az aktuális állapotot nem ismerem). A Gmail az első perctől kezdve felhős szolgáltatás volt. A különbség azonnal érezhető volt. Egy jól megtervezett felhőn kevesebb mint tized annyi ember erőforrással oldhatóak meg azok a feladatok amik az egyedi szerveknél sok időt igényelnek, és ezért gyakran hanyagolják is. Jól lehet automatizálni feladatokat. Saját infrastruktúrán is jó megoldás egy O~S.

"Nekem úgy tűnik, hogy elviekben mozogsz csak üzemeltetésben, nem gyakorlatban, a felhőt inkább evangelizálod, mint alkalmazod"

Programozó vagyok nem rendszergazda. De azt tapasztalom, hogy sokkal jobban képben vagyok mint a tisztelt magyar rendszergazdák, tisztelet a kivételeknek. Sokszor azért ragaszkodnak elavult, gyenge hatékonyágú megoldásokhoz, mert a tisztelt rendszergazdák nem hajlandóak haladni a korral.

Google-nél dolgozol? (ez elég fontos kérdés)

"Más stratégiába vannak a fizetős és ingyenes ügyfelek, adattárolás, adatkezelés szempontból."

Ettől még elveszhet az adat, magad is leírod, hogy "nagyobb valószínűséggel maradnak meg".

Takeout: lehet, hogy meg lehet csinálni, én hirtelen nem találtam meg (sőt, nem is kerestem igazán, az ügyfél nézte a lehetőséget), ha faragni kell, akkor már megint ott tartunk, hogy távolodunk a felhő fő alapelvétől: nyűgöt adjuk át másnak, mindenki foglalkozzon azzal, amihez ért. (engem arra kért meg, hogy keressek "dobozos" megoldást)

IMAP: nem csak ZFS pillanatkép van, de teljesen mindegy miként oldjuk meg, az IMAP önmagában nem megoldás, azaz nem ennyire egyszerű. A mentés akkor mentés, ha vissza is lehet állítani, azaz a folyamatokat ki kell dolgozni köré, ergó dolgozni kell vele.

Tény, hogy kár a felhő definícióján lovagolni, ráadásul két oldala: aki csinálja, és aki fizet érte. Előbbinek technológiákat kell alkalmaznia, utóbbit az érdekli, hogy igényeihez rugalmas szolgáltatást kapjon.

"Sokszor azért ragaszkodnak elavult, gyenge hatékonyágú megoldásokhoz, mert a tisztelt rendszergazdák nem hajlandóak haladni a korral."

Sok megoldás esetén nemcsak azzal van gond, hogy nem hatékony, hanem a "megoldás" is problémás (ha készült egyáltalán megoldás valamilyen implicit/explicit igényre).

Ez önmagában nem jelenti azt, hogy nem felhővel ne lehetne "jobban" megoldani valamit, hanem azt mutatja, hogy híg a szakma. Üzleti oldalról sokan bíznak abban, hogy a felhőben normális szakértelmet kap (az is kiadás, hogy olyan ember/szolgáltató kerüljön adott céghez, aki normálisan tud dolgozni). A Microsoft egyelőre rombolja ezt a képet.

Az biztos, hogy a felhő a jövő nagyon fontos része, de az ma még nem igaz, hogy a felhő mindenre jobb, olcsóbb és egyszerűbb megoldást tud kínálni.
Például a szeptemberi Azure bénázásnál kétféle érintett ügyfélről is lehetett olvasni:
- egyiknek az volt a fontos, hogy visszaálljon a szolgáltatás - akár adatvesztéssel
- másiknak az volt a fontos, hogy ne legyen adatvesztés, az idő kevésbé kritikus
Hely infrastruktúra esetén egy ilyen helyzetet rugalmasabban lehet kezelni, akár eseti jelleggel is (normális infrastruktúra esetén ezen esetek száma azért eléggé minimális).

"Google-nél dolgozol? (ez elég fontos kérdés)"

Miért fontos?

"Ettől még elveszhet az adat, magad is leírod, hogy "nagyobb valószínűséggel maradnak meg". "

Nálad sokkal nagyobb valószínűséggel fog elveszni. Teljesen más lehetőségei vannak egy nagy és magas megbízhatóságú multinak mint akár egy közepes, sőt nagy magyar vállalatnak. De 100% biztonság sehol sincs és nem is lesz.

"Takeout: lehet, hogy meg lehet csinálni, én hirtelen nem találtam meg (sőt, nem is kerestem igazán, az ügyfél nézte a lehetőséget), ha faragni kell, akkor már megint ott tartunk, hogy távolodunk a felhő fő alapelvétől: nyűgöt adjuk át másnak, mindenki foglalkozzon azzal, amihez ért. (engem arra kért meg, hogy keressek "dobozos" megoldást)"

Igen a felhő a kényelemről is biztonságról szól a nagyobb hatékonyság mellett. A Microsoftot most vegyük ki a megbízható felhőszolgáltatók listájáról mert ami ott megy az már valóban szánalmas. A "dobozos" mentés már extra biztonság a felhő különben magas biztonságán túl.
Egy teljesen saját infrastruktúrához képest már a Google vagy Amazon felhő önmagában biztonságosabb megoldás még "dobozos" mentés nélkül is.
Kicsit olyan ez mint az autó vs repülőgép. Minden statisztika több évtizedre visszamenőleg azt mutatja sokkal biztonságosabb repülőgéppel utazni mint autóval (a magánrepülőket most hagyjuk maradjunk a légitársaságoknál). Mégis sokan érzik úgy, biztosabb ha ő maguk fogják a kormányt. Baleset esetén legalább csak magukat hibáztathatják. Még egy repülőgépben az utas teljesen ki van szolgáltatva a pilótának.
"Dobozos" mentésnél sem mindegy, hogy mi az elvárás a felhő megreccsenése esetén?
Azonnal vagy órákon belül vissza kell állítani a szolgáltatást saját vason. Vagy ráér egy hét múlva is ha a felhőben valóban nagy a baj. Előbbi esetnek nagyok a költségei akkor is ha nem történik semmi.

"IMAP: nem csak ZFS pillanatkép van, de teljesen mindegy miként oldjuk meg, az IMAP önmagában nem megoldás, azaz nem ennyire egyszerű. A mentés akkor mentés, ha vissza is lehet állítani, azaz a folyamatokat ki kell dolgozni köré, ergo dolgozni kell vele."

Az IMAP éppen az egyszerűbb problémákhoz tartozik. Készenlétben kell tartani egy saját email szervert ahova rendszeres időközönként fel vannak töltve az emailek. Akár az üzemkész állapotban levő saját email szerverről is lehet készíteni rendszeresen pillanatképeket. Ha törlődnek emailek a felhős szerverről vissza lehet lépni a saját korábbi pillanatképhez.
A saját korábbi pillanatkép nemcsak az email szerver fájljairól készülhet hanem virtuális gép esetén magáról az email szerver image-ről is. Ott mindenképp működőképes korábbi állapototokhoz lehet visszatérni szerver szintjén is átgondolt tervezés esetén.
A Google-nél valójában nem lehet törölni semmit, ilyen a Google FS. Ha valóban támadás miatt történne tömeges email törlés Gmail-en, különösen fizetett ügyfélnek visszaállítják az így elveszett leveleit még a Google-nél.
De egy saját mentési stratéga mindig jó ha van emellett is.

"Sok megoldás esetén nemcsak azzal van gond, hogy nem hatékony, hanem a "megoldás" is problémás (ha készült egyáltalán megoldás valamilyen implicit/explicit igényre).

Ez önmagában nem jelenti azt, hogy nem felhővel ne lehetne "jobban" megoldani valamit, hanem azt mutatja, hogy híg a szakma. Üzleti oldalról sokan bíznak abban, hogy a felhőben normális szakértelmet kap (az is kiadás, hogy olyan ember/szolgáltató kerüljön adott céghez, aki normálisan tud dolgozni). A Microsoft egyelőre rombolja ezt a képet."

Sajnos ebben sok igazság van. A Microsoft a történelmi előzmények miatt túlzottan beágyazott Magyarországon. Teljesen más terület, de a Windows Phone zsákutcába is sokkal több magyar ment bele mint a világátlag, különösen az IT-hoz közeli emberek.
Azt továbbra is fenntartom, hogy Amazon vagy Google felhőben jobb szakértelmet kapnak magyar vállalatok mint sok esetben náluk cégen belül. De ez nem akadálya annak, hogy cégen belül nem annyira jó szakembereikkel csináljanak további, saját kézben tartott backup stratégiát.
Csak a sorrendre kell ügyelni!
Első és minimum a fizetős szolgáltatás a felhőben. Fura, de Magyarországon ezt sem árt leírni.
Második egy további felhőszolgáltató használata. Ez még mindig olcsóbb és biztosabb mint a saját "dobozos" megoldás.
És ha ez sem elég, akkor jöhet harmadik védelmi vonalnak a saját megoldás.

"Az biztos, hogy a felhő a jövő nagyon fontos része, de az ma még nem igaz, hogy a felhő mindenre jobb, olcsóbb és egyszerűbb megoldást tud kínálni.
Például a szeptemberi Azure bénázásnál kétféle érintett ügyfélről is lehetett olvasni:
- egyiknek az volt a fontos, hogy visszaálljon a szolgáltatás - akár adatvesztéssel
- másiknak az volt a fontos, hogy ne legyen adatvesztés, az idő kevésbé kritikus
Hely infrastruktúra esetén egy ilyen helyzetet rugalmasabban lehet kezelni, akár eseti jelleggel is (normális infrastruktúra esetén ezen esetek száma azért eléggé minimális)."

Főleg Office miatt nincs könnyű helyzet. Bár eddig ebbe nem mentünk bele, de felhőn belül sem mindegy, hogy csak fájlszervernek használjuk és mondjuk email szervernek vagy szofisztikáltabb felhős szolgáltatásokat is használunk?
A Microsoft jelenleg eléggé megkerülhetetlen Office-ban. Bár például az amerikai iskolarendszer elég jól át tudott állni Google Docs-ra és ez máshol is opció ahol nem kell kifele nagy mennyiségű és összetett dokumentumot cserélni naponta külsősökkel.
Az Office 365 felhőnek nincs sem saját felhős sem 3rd party felhős alternatívája. Egyetlen alternatíva a natív MS Office. A dokumentumok más felhőbe való backupolása ennek ellére ha nem is ad zökkenőmentes menekülőutat de legalább biztosítja az adatvesztés nélküli működés fenntartását MS reccsenések időszakaiban. Extra munka mindenképp van vele.
Szóval akinek van mentése a dokumentumairól most nem kell sem adatvesztéstől tartania, sem a Microsoft szolgáltatásának visszaállására várnia. Folytatja a munkát natív Office csomaggal Amazon vagy Google felhőben levő dokumentumokkal.

Google munkahely nyilván az esetleges elfogultság miatt fontos, bár furcsa, hogy ez miért kérdéses...

"De 100% biztonság sehol sincs és nem is lesz."

Éppen ezért akart az ügyfél mentést a Google-nél tárolt adatokról. Innen indult a gondolat, remélhetőleg nem bűn, ha valaki még nyugodtabban szeretne aludni viszonylag kis többlet költségért.
És valószínűleg egyre többen, mivel látszólag nő a felhő mentő szoftverek kínálata.

"Egy teljesen saját infrastruktúrához képest már a Google vagy Amazon felhő önmagában biztonságosabb megoldás még "dobozos" mentés nélkül is. "

Valószínűleg igen, de ha valahol van telephelyen kívüli mentés is, akkor az tipikusan elég jó (még ha technológiailag nem is közelíti meg a normális felhőket), a kérdés az ár és az egyéb szempontok (sok lehet).

"Készenlétben kell tartani egy saját email szervert..."

Pont ezt akartuk elkerülni a felhővel. A sok hókuszpókkal végül kvázi ott vagyunk, mintha helyi infrastruktúrát építenénk.

"Van üzleti ügyfelem, akinek O365 dolgai vesztek oda" --> Ebben az esetben mit tettél?
a. ihat rá hidegvizet.
b. volt esetleg plusz mentés?

a.-ra tippelnék, ugyanis az ember ha már felhő szolgáltatást választ, jelen esetben O365-öt ahol az adatok eleve replikálva tárolódnak (by default nem geo redundanica, de raid), így nem készít mentést.

A felhő nem ígér neked mentést, konkrétan nem adnak, garancia sincs az adatokra. Melyiknél van bármi erre utaló az ÁSZF-jükben? Általában az állandó működést és a "gondtalanságot" adná a felhő, de foglalkozni azzal is kell, saját példányos mentés sem árt. Miért bízna meg bárki egy bármilyen 3rd partyban úgy, hogy garantál adatot. Lásd a 7+ éves pénzügyi vagy a mégkomolyabb munkaügyi adatmegörzési időket. Ezeket neked kell teljesíteni, nem egy random szolgáltatónak. A bónusz, hogy mindenki saját maga tudja, hogy mennyire értékesek az adatai és ennek megfelelően tudja kelezgetni őket.

Hatékony megoldás két felhő használata. Mellette opcionálisan rendszeres data takeout. Sajnos differential vagy incremental takeout lehetőséget még senkinél sem láttam, ezt saját infrastruktúrán kell megvalósítani. Kell hozzá 2x annyi tárhely mint amennyi adatod van, streamer de ez már valóban eléggé biztonságos megoldás.

( bounty v | 2019. 02. 01., p – 11:20 )

"there databases" - leülhet, egyes.
másik kedvenc a "would of" és társai.

( uid_16313 | 2019. 02. 01., p – 12:22 )

Grat.

A felhök feloszlanak :)

--
robyboy

"Amúgy sem értettem sosem, miért is kellene ismeretlen helyre költöztetni szenzitív adatokat?"

A saját infrát meg kell tervezni, beszerezni, üzemeltetni, bővíteni, hibaelhárítani. Ha nagy ez az infra, embereket kell felvenni csak azért, hogy a vasat simogassák. A felfelé skálázódás drága és lassú, a lefelé skálázódás után meg a kihasználatlan vasban fog állni a pénz. Sehogy se jó.
A cloud infra szerintem egy tök jó dolog, és igen, tartunk benne szenzitív adatokat. Ez is egy olyan kockázat, mint amilyen kockázatok a saját infrában is megvannak. Ha igénytelen, figyelmetlen a saját rendszergazdánk, akkor lehet hogy sokkal nagyobb a kockázat.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

RAID + rendszeres backup + rendszeres szalagos archiválás. Ezek nélkül meg sem fogja közelíteni a saját infrastruktúra biztonsága egy normális felhő adatbiztonságát.

A felhőszolgáltatók sem egyformák. Ha saját infrastruktúrán valaki WD Green merevlemezeket használ mindenféle redundancia nélkül ne lepődjön meg ha megreccsennek az adatai. A Microsoft Azure a sokadik baki után kivívta magának a WD Green szintet adatbiztonságban.
Majd ha rendszeresen lesznek hasonló incidensek Amazonnál és Google-nél is majd akkor lehet általános következtetéseket levonni a felhőkkel kapcsolatban.
De itt a Microsofttal van probléma nem a cloud-dal.

Az nem archiválás.
A szalag "kikapcsolt állapotban" is hosszú ideig megőrzi a rajta levő adatot.
Egy működő gépet feltörhetnek, elrontott frissítéssel, szoftverhiba következtében veszthet adatot.
Még egy szekrénybe elzárt merevlemez sem archiválási megoldás. Nincs rá garancia, hogy x idő múlva felpörög az a merevlemez.
Egyébként ár/GB arány a szalagnál a legalacsonyabb. A kezdeti beszerzési költségek magasak.

Pár havonta (3-6) cserélni a merevlemezt és zárt tűzvédett páncélban felmalmozni, és adott időnél régebbieket szépen forgatni vissza vagy selejtezni. Az aktív hdd-k száma így bármennyi lehet és bármennyire fokozható a megbízhatóság. Nem beszélve a HDD típusának megfelelő megválasztásáról.

Olcsóbban fogsz kijönni egy steamerrel. Nem kell feltétlenül LTO-8.
Merevlemezes archiváláshoz kelleni fog egy GoogleFS képességű fájlrendszer, amin OS szinten lehetetlen törölni fájlokat. Raid1(0) vagy Raid5,6 sem árt hozzá és természetesen csak linuxos softraid vagy ZFS.
A hardveres raid kártyák csak rontanak az adatbiztonságon.

Ha egyáltalán nem archiválsz akkor az 0 idő, tehát zéró órabér.
De nincs is rá szükség ha nem fontosak az adatok. Csak ne nevezzük archiválásnak ami nem az.
Valószínűleg a Microsoft is lazán kezelte témát, ezért van most baj. Ennél a szolgáltatásnál ez szükséges lett volna. De valóban nem szükséges mindenhol.

Visszajutottunk a kiindulási pontba. A megbízható felhő (Google, Amazon) igényli a legkevesebb órabért. Teljesen automatizálható a felhős mentés. Két párhuzamosan használt felhő nagyobb adatbiztonságot jelent mint a saját infrastruktúra még akkor is ha nincs kispórolva belőle a valódi archiválás.
És nem kell felesleges munkaórákat pazarolni merevlemezek szerelésére.

( tigrincs | 2019. 02. 01., p – 11:43 )

Mondjuk ha a backup ugyanabban a rendszerben tarolodik mint az eles akkor az nem annyira jo megoldas.

( Mycrobi | 2019. 02. 01., p – 13:37 )

Hmm,ezért szeretünk redundánsan menteni magunknak is biztos ami biztos. Mármint legalább a fontos adatokat. Ami nagyon kell az lokál f&P szerveren, és ütemezett mentéssel máshová. A kliens adatok meg OneDrive-ban elvannak. Ha valami gigszer van akkor mi szóltunk hogy csak a szerveres adatokért van felelősségünk. Slussz passz issue solved.

- Az élet, a világmindenség, meg minden (DA) -

( YleGreg | 2019. 02. 01., p – 13:57 )

Bocsánat, de muszáj voltam valami értelmes módon modellezni a problémát.
Úgy érzem, hogy mivel minden if -et lezártam, ennél nem lehet sokkal bonyolultabb: 


if [ $timeOfOutage -lt $slaValueFromContract ]; then
    echo "And the beat goes on! (Scoooooter!)"
else
    if [ $lossOfOutage -lt $penaltyValueFromContract ]; then
        echo "Yes! Free money!"
    else
        echo "The contract is wrong."
        bonusOfFinancialDepartment=$(($defaultBonus-($lossOfOutage-$penaltyValueFromContract)))
    fi
fi

( asch v | 2019. 02. 01., p – 14:21 )

Én azt nem értem, hogy ha magamnak kell megoldanom a tisztességes redundanciát, és backupot, ha azt akarom, hogy _egyetlen tranzakció se vesszen el_, akkor tulajdonképpen mit is nyerek az üzemeltetésen a clouddal? Hogy a legnehezebb feladatot továbbra is magamnak kell megoldanom?

Mi volt egyébként ezeknek az adatbázisoknak az ígérete? Oké, hogy lehet némi downtime, de elvesző adat is lehetséges a szerződés szerint? (Fogalmam sincs, és nem is nézek utána, csak puffogok :-)

> [...] _egyetlen tranzakció se vesszen el_ [...]

Akkor saját hiper-redundáns rendszert építesz, a felhő árához képest irdatlan drágán. Arra adhatsz sokkilences rendelkezésreállást, felelősségvállalással, mindennel.
A felhővel azt nyered hogy nem te üzemelteted a sok vasat, sok datacenterben sok rendszergazdával.

Ez sem feltétlen igaz. A Microsoft Office 365 az elmúlt negyedévekben kb. 3 9-est (99,97, 99,98) tudott felmutatni.

SLA sértés esetén milyen kötbért is fizet? Hidd el, tudunk konkurálni vele. Olyan szerződést mi is tudunk csinálni, hogy 99,7 a szint, de ha nem teljesítünk, akkor egy-két havi díjat elengedünk, egyébként meg STFU.

Azért ha abban gondolkodsz, hogy azon a vason hány virtuális gépet lehet eladni ilyen feltételek mellett...

--
trey @ gépház

> A Microsoft Office 365 az elmúlt negyedévekben kb. 3 9-est (99,97, 99,98) tudott felmutatni.

De öt dollárba kerül fejenként. Ebből ki kell hozni a gépektől kezdve az üzemeltetők bérén keresztül a tárhelyen át a supporting mindent, mindezt levelezésre, file share-re, videoconfra, stb. Szerintem ár-érték arányban rendben van a háromkilences. Ez elvileg havi <45 perc, beleértve a tervezett, off-hours leállásokat.

Ennél lehet _sokkal_ jobb rendelkezésre állást biztosítani, de az nem publikus felhő lesz, és (sejtéseim szerint) nem 5 dollár havonta. Az a kérdés, mire van szükség.

( Goten v | 2019. 02. 01., p – 14:34 )

Csak nekem van merevedesem attol ha valaki ilyen masszivan lebuntet es megeroszakol egy idegen nyelvet?

( uid_395 v | 2019. 02. 01., p – 17:55 )

vicces ezt olvasni, főleg úgy hogy sokan körberöhögik azt a fajta "felfogást", vagy IBSZ-t hogy nem tárolunk adatokat cloudban, főleg nem 3rd party cloudban.

Hát.. na.. bizony, nehéz elhinni, de vannak olyan helyek ahol tiltva van az ilyen fajta adattárolás / szerverüzemeltetés / bármiegyéb .... *.gov* ..

Egy csomó kormányzati cucc van Office365-ben is, külön garanciákat adnak, mert azért az elég jólfizető vevőkör.

A hiba maga nem valószínű, hogy felhő specifikus, egy jól irányzott paranccsal, elírással, klikkel, nagyon szépen végig lehet on-premisis darálni az adataid. Sokkal inkább a mentés, cloud esetén mondjuk úgy hogy saját hatókörben elérhető, tehát klódfüggetlen, van-e...

:) Egész jól emlékeztem: https://azure.microsoft.com/en-us/global-infrastructure/government/ és https://azure.microsoft.com/en-us/global-infrastructure/regions/

Jól sejtem a Gov-osok külön DC-k.

"Government exclusivity

Only US federal, state, local, and tribal governments and their partners have access to this dedicated instance that only screened US citizens operate."

Szal nem viccelnek, rámentek erősen a kormányzati sztorira kint.

Hahó ez a NISZ, mindenen jelszó van :) Szerződj aztán megmondjuk (TM), az NTG-nél én is szívtam vele (ennyi erővel az összes ISP átvehetné ezt a módszert :))

Arról nem beszélve, hogy lé nélkül van insane biztonsági szabályzat amit lével a saját rendszereik se teljesítenek (sql injection is fun in a system that is used by everyone but not by chance). Tényleg nincs egy nyomorult teszter a cégnél (hogy melyiknél jó kérdés , de ha már össze shoppingoltuk a rendszereket a haveroktól oldjuk már meg). Igen tudom van hibajegy foci. De az ember nem akar azon vitatkozni egy biorobottal azon , hogy mi meg mi a nem helyes input. Legalább implementáljunk egy "skip scripted response" gombot.