Tot nu heb ik eenmaal een backup nodig gehad en deze bleek niet terug te zetten. Afschuwelijk.
Dit is het ergste wat je kan overkomen op IT gebied naast een geslaagde malware aanval.
Ik hoop voor deze universiteit dat er niet teveel bestanden zijn die als backup teruggehaald moeten worden (dus nu niet lukt), of kwijt blijken te zijn nadat tot begin februari gaat blijken dat er nood aan is.

ik geloof bij deze, dat het IT team daar met mega stront on de broek stond..
je reinste nachtmerrie wat uit komt.

mooi man, testen in productie

Het leesbaar maken van dit soort scripts is een nobel doel. Het robuust maken (bijvoorbeeld voor onbedoelde pogingen meerdere backups parallel te draaien) is minstens zo belangrijk. Laten we hopen dat de laatste geslaagde backup (die is gemaakt voor de wijziging in het backup script) nog bestaat en terug te zetten is.

Backups moet je trouwens ook af en toe testen. Bijvoorbeeld door een directory een andere naam te geven en dan (te vragen) die directory (met inhoud) te restoren. Daarna de teruggezette directory en inhoud vergelijken met de directory met de gewijzigde naam.

find / -mtime -10 -delete i.p.v. -mtime +10 of zoiets.

Mee eens. Gelukkig zat de fout ook niet in het aangepaste script zelf, maar dat het gerund werd, terwijl het oude script nog draaide.

Ik lees in de eerste link dat er in de eerste aankondiging nog gesproken werd over 100TB verloren data. Blijkbaar hebben ze nog 23 TB uit een backup kunnen terug zetten.


Hieruit maak ik op dat de resterende 77 TB verkoren is doordat de backup gewist is voordat het wissen van de originele bestanden ontdekt werd. Maar dan werden de backups wel extreem kort bewaard.
De file deletion periode is van 14 tot 16 december. Op 16 december werd dit ontdekt en zijn de betroffen mensen direct gewaarschuwd. Hadden ze toen al geen backup meer van 2 dagen oud?

Dit zou een interessante 1 April grap kunnen zijn geweest.

Heerlijk die japanse PDF, Het gaat goed door een vertaler heen.
Ik lees lustre als een parallel filesyste, met 14 verschillende afnemers/groepen. https://www.lustre.org/
Een backup van HP die bestanden verwijderd? Vreemd een backup hoort enkel bestanden te archiveren.
https://wiki.lustre.org/Backing_Up_a_Lustre_File_System



Juist met die omvang zou een apart filesystem voor testen van procedures handig zijn. Die hoeft niet zo groot als de rest te zijn. Hier gaat iets mis met een gedegen opzet en scheiding van functies
De fout is een typische met bash. Er wordt gesteld dat het script draaide (geen lock) en het vervangen met een nieuwe versie zorgde ervoor dat de draaiende met tekst middenin in het nieuwe verder ging. Auw....geen read locks (disp=shr)?

Mirrorring geeft een beperkte bescherming egen hardware uitva bovenop de 10 hardware storage.
ik lees dat er op incremental / full backup bespaard is.
https://www.bleepingcomputer.com/news/security/university-loses-77tb-of-research-data-due-to-backup-error/

Incrementals voor een beperkte periode met een enkele full backup lijkt de werkwijze te zijn.
Gooi je bestanden massaal weg tijdens of net voor de full dan gaan voorgaande incrementals gaten vertonen om dat die in een backsysteem opgeschoond gaan worden.

Ongeautoriseerde change. Zo zie ik het.

"Ff" scriptje aanpassen gaat altijd fout.

Zo kon ik een keer in het weekend naar mijn werkgever racen omdat er 30.000 man niet konden inloggen omdat een collega ff een scriptje had aangepast, terwijl die verder niet bereikbaar was.

heel wat onder broeken de was in.

Dat is wel het minste wat Hecky Packy er aan kan doen.
Altijd voldoende rekening houden met nietsvermoedende gebruikers.
Vooral bij universiteiten.

Tja voorkomen was lastig geweest in dit geval echter waarom ze niet werkte met diskspace alerts in combi met audit rules is me een raadsel. Als je weet dat je back-up 70+ TB is en het zeldzaam is dat back-ups kleiner worden dan waarom niet een treshold alert bij 65TB of alert bij verwijdering van een dummy bestand. Schade was er hoe dan ook geweest maar twee dagen is wel heel erg lang om hier achter te komen dit had een realtime alert kunnen zijn middels mail, sms modem of api.

HP heeft hier echter een megablunder begaan en ik hoop voor hun dat er niet zometeen Terrabytes aan data forensisch moet worden hersteld het zal hoe dan ook een enorme klap zijn voor hun reputatie bij aangesloten organisaties.

Veel sterkte gewenst aan het IT team en overige medewerkers van de getroffen universiteit.

Nee, dat is een echte programmeerfout .

Deze was subtieler .

iets als :
cp /home/test/backup_script_v1.1.sh /home/live/backup_script.sh

(of een git pull uit de approved_for_deploy repo, of een rsync vanuit acceptatie, - whatever) .

Probleem was alleen dat "het" live backup script op dat moment draaide .
Langlopend, of botte pech dat de deploy overeenkwam met het moment in de cron dat het script gestart werd .

En toen liep van alles mis.

Uit https://stackoverflow.com/questions/21096478/overwrite-executing-bash-script-files maak ik op dat het gedrag oonvoorspelbaar is . Of in elk geval erg afhankelijk van bash versie, os, lengte van het shell script etc .
Duidelijk een gevalletje 'don't do that' . (of test je suf op de exacte bash+os+script versie voor het werkelijke gedrag) .

Er zijn natuurlijk meer instinkers op dit thema - een shared library updaten - leidt dat vanzelf tot gebruik door lopende processen die de library gebruiken ?
Riskant als je denk een security bug gepatched te hebben, maar processen niet herstart .

Config file van een daemon updaten - SIGHUP nodig ? Er zijn programma's die actief hun config monitoren en zichzelf her-initialiseren als ze een wijziging zien.
Soms een lang liggende valkuil - config file met kleine fout, en daemon niet herstart . Het kan dagen/weken/maanden duren voordat er een keer een herstart gebeurt, en dan zoekt iedereen zich suf wat er nu veranderd is dat hij "zomaar" niet meer wil opstarten, want er is al zo lang niks gewijzigd .

Voorkomen was goed te doen, het was niet de backup maar een bash opschoonscriptje bij de backup. Her verwijderdei logfiles, althans dat was de bexoeling.
Doe je ene fullbackup erna dan kan je niet meer terug.
Je aanname dat er meerdere fullbackups zouden zijn klopt niet.

De draatijd voor die full is dusdanig dat je weinig aan een vergelijk voor veranderingen hebt. De omvang is dusdanig dat meerdere fullbackups erg duur zijn.

Nou ja zo'n vaart zal het wel niet lopen denk ik , éénmaal er geweten is welke data mist kunnen studenten die gebruikten en mogelijks over een copie beschikken het terugbezorgen. Raar dat sommige bestanden niet geblockeert zijn van wissen . Ik draai eigen backupsystemen maar die lege variable lijkt mij wel meer mensen te kunnen overkomen.

Wat velen niet weten is dat het meer gebeurt maar het onder de mat verdwijnt en dan ergens de schuld komt bij onbestaande hackers (zoals bij angular wel eens gebeurt maar altijd litle to late).

Eens reclame maken voor het bedrijf in oostende die dat aanbied voor bedrijven.

Omdat je niet leest ?

Je denk dat iedereen moet springen als er 65T meer of minder in gebruik is ?

De 77 T waren natuurlijk maar een fractie van de totale data .
Op een HPC systeem valt het een tiental T meer of minder gewoon niet op.

Dat staat er in zekere zin ook in het bron artikel. Van de 14 groepen die de server gebruiken is er naar bij 4 groepen data verloren gegaan.

Managementprobleem.

In de IT heb je enerzijds de noodzaak van redundancy. Desnoods tien backups bijvoorbeeld, twee in een atoombunker en eentje op de maan. En slimme backups want data blijft in wezen dusdanig dynamisch dat al die rotbitjes echt gewoon per petaflop kunnen veranderen. Dus daar moet je verstandig mee omgaan.

Anderzijds blijft het altijd een onemanshow. Die ene dikke gozer in de hoek. Die heel de dag cola light drinkt. En nog steeds geen verkering heeft. Maar als enige alles in de vingers heeft. Maar op een verkeerde knop drukt. Omdat bijvoorbeeld mejuffrouw Jannie steeds vaker komt vragen of hij echt geen koffietje van haar wil.

Vertrekt die laatste, dan krijg je pas echt een puinhoop. Want de rest heeft enkel meningen. En de directie enkel een mooi logo. Zo ontstaat gatenkaas software. En dan krijg je bijvoorbeeld een Windows. En heel veel updates. Die dan ook weer niet alles oplossen dus dan nog maar een update en dan alsnog heel de zooi geransomewared. Voor briljante mensen bestaat geen redundancy. Het gaat dan echter niet over financiële prikkels (want dan kweek je enkel Elon Musks die alsnog de weg kwijt raken). Maar over deel zijn van een team en een familie. Waar die ene dikke in de hoek zich lekker thuis voelt, zolang je hem maar met rust laat. Dat los je ook niet op met een avondje naar de bowlingbaan. Of een biljart en een Nintendo in de hal. In tegendeel.

Als je het leest hoe de backup is ingericht.
- 1 cycle full backup (sic)
- aantal incrementals van voor een backup maar die zijn nutteloos zonder een echt representatieve full.

Nou hier niet, kennelijk doet HP het operationele beheer (uitbesteed).
Wat zeer verwonderlijk is in dit geval:
- de backup / restore heeft hoge rechten voor alle data nodig (ongelimiteerde root rechten).
Hoe je dat anders wilt doen is uit de aard van wat er moet gebeuren onmogelijk
- Opschoonscripts, zelf gebouwd, laten we voor het gemak ook maar met die ongelimiteerde rechten lopen.
Waarom of waarom. Een gelimiteerde apart service account wat enkel de technische logfiles kan verwerken volstaat.
Dit is waarom least privileges zo belangrijk is.

De gatenkaas waar we het hier over hebben is open sources Linux en Lustre in een HPC omgeving.
Gedegen beheer is niet vanzelfsprekend ook niet als je het uitbesteed aan een externe partij.
Ik had nog open toegang (kaseya) dan wel userids /password in publiek git verwacht met dit soort fouten in een veilige opzet

"- de backup / restore heeft hoge rechten voor alle data nodig (ongelimiteerde root rechten).
Hoe je dat anders wilt doen is uit de aard van wat er moet gebeuren onmogelijk "

onjuist.

Leg dan maar eens uit hoe je alle data kan benaderen lezen en overzetten zonder die root rechten. Bij de restore moet je alle dat kunben overschrijven en toegangsrechten op alle data kunnen zetten.

Simpel:

voor de backup heb je alleen lees rechten van die gebruikers data nodig. Voor restore van gebruikers data heb je alleen schrijf rechten als die gebruiker nodig.

Details:

Een automatische cronjob die als gebruiker runt is afdoende om dagelijks een rsync te doen (met foefjes om incrementals ipv full syncs te doen). Je kunt daarbij ook nog eens een stageing server constructie gebruiken waarbij de backup server een dagelijkse synched kopie backuped van de stageing server ipv de directe host server zelf zodat die host server niet continue belast wordt en de stageing server dus een 'triggered pull' doet ipv een 'push' vanuit de host die je wilt backupen. Je kunt er dan ook "zero trust" en "data diode" concepten introduceren meteen zodat als er een gebruikers / root account op de host compromised is, er geen eenvoudige toegang tot de stageing en backup servers verkregen wordt. Je zult wel nog goede host monitoring blijven moeten houden om compromise te detecteren, maar dat is iets anders dan het wel of niet doen van backups perse als root :).

Het maken van een disaster recovery image is namelijk iets heel anders dan backupen en restoren en eigenlijk vrijwel altijd kun je beter een automated config managed redeploy doen (waar je dus wel root voor moet zijn eventjes tijdens die herinstallatie procedure via PXE oid) waarna die gebruikers data restored van backup wordt. Gebruikersdata is waardevol, OS binaries die vrij eenvoudig automatisch (re)deployed kunnen worden van een locale mirror, die is niet gevoelig of waardevol. Een goede PXE+anaonda/kickstart al dan niet met ansible is GOUD !

Maargoed ik verwacht nu weer een welles niettes ver pis wedstrijdjes antwrood eerder dan een 'oh ok dus zo kan het voor anderen dus ook' reactie, of had je wel nog goede voornemens?

Geen verschil met rootrechten op het moment dat alles incuslief het systeem mee moet

Gezien de omvang kan dat niet met het door jouw voorgestelde simpele werkwijze. Op zich is een apart account met specifiek een deel (container/segements) de kern service accouts waar ik me vaker druk over maak dat het gemist wordt.

Dat werk enkel als de omvang klein genoeg is. In dit geval lustre big-data is er zelfs geen cyclus van volledige backups, ik verwacht geen externe oflline versie. 100TiB rsyncen? hoe lang denk je dat dat duurt....

Ook die gaat enkel op als het maar klein genoeg is. We hebben het hier over een omvang en schaal waar dat niet werkt. Ook bij het meer simpele gebeuren is er de neiging om naar de cloud te gaan omdat hetgeen zo simple geschetst net niet werkt als het nodig blijkt. Simple Os binaries en dan met allerlei in de OS beheerder niet standaard zaken er bij onmisbaar zijn. Overigens is het idee niet verkeerd, de praktijk is alleen weerbarstiger.
Service accounts te lastig, te veel etc dus nauwelijks er door heen te krijgen. Installatieprocedures een maand na oplevering al niet meer goed herbruikbaar.

Je hebt gelijk dat backup/restore voor een dagelijkse herstel van een vergissing iets anders is dan een DR. Zo vaak dat het door elkaar gehaald wordt zodat uiteindelijk geen van twee behoorlijk is. Het is wel goedkoper zolang het goed werkt.


Goede voornemens genoeg. Nog de beste wensen voor dit jaar.
Wat is nog te doen: Bijvoorbeeld wel werkbare backups uitwijkplannen en meer..

En toch werkt het hier en met meerdere user accounts en met plenty data... dus ergens trek je de verkeerde conclusies. Zoek ze zelf maar uit!

Kwestie van omvang in de systemen data en de grootte van de organisatie. Wou je zeggen dat je zelf zoiets van lustre met 70Tib in hpc hebt draaien? Als je goed gelezen had is service account aub noem ze geen user accounts (lopen via HR) belangijrk zijn.

Ja, geen lustre, maar hier wel een 500T glusterfs gehad. Snellius werkt overigens met gpfs, Andere machines nu weer met beegfs danwel ceph. Het is dus niet altijd luster wat gebruikt wordt.

Dus nogmaals, ook al snap JIJ het niet, toch is het zo. Ga maar lekker in je eigen brei zoeken waar de foute aannames en door de bocht conclusies nu weer zitten. Tip: nergens staat dat ze in tokyo elke DAG een sync / backup doet van 70T. Er staat alleen dat er 70T aan backup data foetsie is.

Duidelijke afspraken maken goede vrienden

Uit: Zes adviezen voor 2022



https://datanews.knack.be/ict/nieuws/de-toestand-is-ernstig-maar-niet-hopeloos/article-opinion-1819375.html