Japanse universiteit verliest 77TB aan data na back-upprobleem

De Universiteit van Kioto in Japan is 34 miljoen bestanden met data kwijtgeraakt bij problemen die plaatsvonden bij een programma voor de back-up van de opslag van een supercomputer van HPE.

In totaal is tussen 14 december en 16 december 77 terabyte aan data per ongeluk verwijderd. Niet bekend is om wat voor data het gaat. De Universiteit van Kioto heeft afdelingen waarvan gegevens zijn verdwenen via e-mail op de hoogte gebracht. De universiteit ontdekte het probleem 16 december en dacht toen nog dat het om 100TB kon gaan. Deze week is dat gecorrigeerd naar 77TB.

Het gaat om data die opgeslagen stond op het Large0-opslagcluster van een supercomputer van HPE. De universiteit heeft meerdere Cray-systemen van HPE. Een wijziging aan het back-upprogramma maakte dat bestanden verwijderd werden. Een groot deel daarvan kon niet hersteld worden.

Eind januari hoopt de universiteit de back-up te kunnen vervolgen, na maatregelen genomen te hebben om herhaling van het probleem te voorkomen. De onderzoeksfaciliteit gaat verder werken met mirrors van back-ups en het intact laten van eerdere generaties van back-ups. Daarnaast verzoekt de universiteit medewerkers om zelf back-ups van belangrijke bestanden te maken.

Bron: University Kyoto, computing services

Reacties (149)

[Jerie]

About file loss in Luster file system in your supercomputer system, we are 100% responsible.
We deeply apologize for causing a great deal of inconvenience due to the serious failure of the file loss.

We would like to report the background of the file disappearance, its root cause and future countermeasures as follows:

We believe that this file loss is 100% our responsibility.
We will offer compensation for users who have lost files.

[...]

Impact:
--

Target file system: /LARGE0

Deleted files: December 14, 2021 17:32 to December 16, 2021 12:43

Files that were supposed to be deleted: Files that had not been updated since 17:32 on December 3, 2021

[...]

Cause:
--

The backup script uses the find command to delete log files that are older than 10 days.

A variable name is passed to the delete process of the find command.

A new improved version of the script was applied on the system.

However, during deployment, there was a lack of consideration as the periodical script was not disabled.

The modified shell script was reloaded from the middle.

As a result, the find command containing undefined variables was executed and deleted the files.

[...]

Further measures:
--

In the future, the programs to be applied to the system will be fully verified and applied.

We will examine the extent of the impact and make improvements so that similar problems do not occur.

In addition, we will re-educate the engineers in charge of human error and risk prediction / prevention to prevent recurrence.

We will thoroughly implement the measures.

Bron van vertaling.

[CAPSLOCK2000]

A new improved version of the script was applied on the system.
(...)
The modified shell script was reloaded from the middle.

Dank voor deze vertaling want de meesten van ons lijken het probleem niet te snappen, ook al staat het hier duidelijk uitgelegd. Deze twee zinnetjes is waar het echt om gaat, dat is het nieuws, niet dat stuk over lege variabelen.

Lege variabelen zijn ook een probleem, maar dat is vrij algemeen bekend. Iedereen heeft die fout wel een keer gemaakt en de meesten houden er inmiddels rekening mee.

Het "nieuwe" probleem is dat het script is overschreven terwijl het liep en dat de computer midden in de uitvoering opeens is overgestapt naar de nieuw file en daar is verder gegaan. Het probleem is niet echt "nieuw" en ouder dan de meeste bezoekers van deze site maar het is behoorlijk onbekend.

Dit is dan ook geen fout van de programmeur, maar van de beheerder die het heeft geinstalleerd (handmatig of procedureel) terwijl het oude script nog liep.

[karma4]

Er hoort een lock op een bestand te staan dat in gebruik is, een read-lock.
Als je niet wat er loopt en in een draaiend systeem wat kan vervangen dat volledig verkeerd uitpakt, dan is het beter een stil moment in te plannen en een nieuwe naam te gebruiken

[casberrypi]

Nee, dat is alleen zo op Windows. Een van de moeilijke dingen van Windows is dat je niets kunt vervangen dat draait. Dat is de reden dat je die machines voortdurend moet rebooten. Op Unix's ligt de verantwoordelijkheid daarvoor bij de beheerder.

Dat is voor .so libraries (Unix equivalent van DLLs) heel prettig, maar voor scripts soms wel onhandig.

Overigens is gedrag bij een verwijderd en opnieuw gemaakt bestand anders dan een aangepast bestand. Bij verwijderen en opnieuw maken blijft de filedescriptor naar de oude file wijzen, die dus pas echt wordt verwijderd als alle actieve filedescriptors zijn gesloten.

[Pianist1985]

Dat is niet 100% correct. Probeer maar eens of je de bestandsnaam kunt veranderen van een mp3 of video die af aan het spelen is - je zult zien dat dat gewoon kan. Metadata wijzigen van een bestand met Mp3Tag lukt ook. Windows stelt je in staat om bestanden te wijzigen die reeds in het geheugen zijn ingeladen en belet alleen het bewerken van data die niet volledig in het geheugen zit maar 'on the fly' vanaf de schijf wordt gelezen tijdens het gebruik.

[mjl]

Klinkt bijna als een Windows command line script, dergelijke batch scripts kan je terwijl ze lopen aanpassen, zolang er maar geen loops of verwijzingen in zitten (bijv. Een goto commando).

[karma4]

Het gaat hier linux luster (open source) in een HPS setting.
Zo te zien:
- geen meerdere cycles van de full backup. Retention policy is enkele dagen -> management faal
- het gaat om een bash script, Deze zou een lock bij de uitvoering moeten zetten -> linux faal
- De backup / restore moet met volle ongelimiteerde rechten lopen.
Waarom opschoonscripts met volle ongelimiteerde rechten? -> linux faal + management faal
Het gaat om een bash script, Bekend issue als valkuil zoals rm -rf
- script is niet uitgetest in een afgescheiden omgeving -> management faal + linux faal
- er is geen behoorlijke vier ogen principe doorgevoerd, git werkt hier echt niet egen -> linux faal + management faal

Een lock op de hele dataset was gangbaar in echte betrouwbare systemen. Aanduiding disp=shr
Dat met een aangepast bestand en inodes als copie is met bash niet aan de orde, Met de backup zou het kunnen werken als er aparte inode snapshots in luster voor zijn. https://wiki.lustre.org/Lustre_Snapshots

De aanname dat linux wel tegen foute beslissingen en foue keuze beschermd is zeer onterecht. Je kunt beter veilig werken met een extra reboot dan in zo'n probleem als van alles kwijt raken terecht komen.

[zenlord]

Ik vind het toch behoorlijk eng om zo'n grote volumes met een bash-script te gaan beheren, ook al doe ik het zelf ook, maar op veel kleinere schaal (in Debian Jessie/Buster was borgmatic nog niet voldoende doorontwikkeld).
Misschien moet ik gewoon meer vertrouwen hebben in bash-fu... Vooralsnog lopen de backups hier als een zonnetje

[CAPSLOCK2000]

Ik vind het toch behoorlijk eng om zo'n grote volumes met een bash-script te gaan beheren, ook al doe ik het zelf ook, maar op veel kleinere schaal (in Debian Jessie/Buster was borgmatic nog niet voldoende doorontwikkeld).
Misschien moet ik gewoon meer vertrouwen hebben in bash-fu... Vooralsnog lopen de backups hier als een zonnetje

Op zich heb je gelijk dat Bash niet de beste taal is voor grootschalig programmeerwerk. Bash is vooral heel goed in quick & dirty. Netjes en degelijk programmeren is lastiger dan in veel andere talen.

Daar staat wel tegenover dat inzicht en begrip ook heel waardevol zijn. Als je het gereedschap dat je gebruikt niet goed begrijpt dan zul je fouten maken. En als je problemen moet oplossen dan is goed inzicht in je software helemaal onmisbaar, net als de mogelijkheid om de code snel te begrijpen en aan te passen. Op dat soort punten zijn die bash-scriptjes ijzersterk.

De keuze hoeft natuurlijk niet zo zwart-wit te zijn. Er zijn een hoop tussenvormen en alternatieven. ZSH en Python zijn bijvoorbeeld ook prima script-omgevingen die vaak net zo bruikbaar zijn als bash en minder gevoelig voor subtiele fouten.

Maar laat je niet wijs maken dat de gekozen programmeertaal ooit het grootste probleem is. De vaardigheid van de programmeurs en systeembeheerders is veel belangrijker dan de taal. Hoe het gereedschap gebruikt wordt is belangrijker dan of je een grote of een kleine hamer hebt.

[Joolee]

Dat klinkt mij als een variatie op de bekende 'rm -r /volume/$undefinedVariable'. Daar is elke linux-beheerder wel eens de mist mee ingegaan en Valve kan er ook zeker over mee spreken.

[Reactie gewijzigd door Joolee op 23 juli 2024 16:26]

[CAPSLOCK2000]

Dat klinkt mij als een variatie op de bekende 'rm -r /volume/$undefinedVariable'. Daar is elke linux-beheerder wel eens de mist mee ingegaan en Valve kan er ook zeker over mee spreken.

Dat is deel van het probleem maar er lijkt meer aan de hand te zijn, namelijk dat het backup script werd veranderd terwijl het liep. De meeste mensen lijken niet te weten dat je dat niet mag doen met (bash)-scripts. Zo'n script wordt regel voor regel uitgevoerd en er wordt niet vooruit gekeken. Als je het overschrijft terwijl het draait, dan gaat het systeem verder op hetzelfde regelnummer maar in de nieuwe file. Daar zijn de meeste scripts niet op gebouwd.

[Verwijderd]

Dit was nieuw voor mij, en net even getest met een bash scriptje met 5x `echo "bla"` gescheiden door `sleep 5` en tijdens het draaien een `echo` die nog niet voorbij gekomen was aangepast naar een andere tekst, maar dat klopt dus niet, het script dat uitgevoerd was, is zoals het op het moment van starten was.
Hoogst waarschijnlijk wordt het script in geheugen geladen bij starten.

[CAPSLOCK2000]

Dit was nieuw voor mij, en net even getest met een bash scriptje met 5x `echo "bla"` gescheiden door `sleep 5` en tijdens het draaien een `echo` die nog niet voorbij gekomen was aangepast naar een andere tekst, maar dat klopt dus niet, het script dat uitgevoerd was, is zoals het op het moment van starten was.
Hoogst waarschijnlijk wordt het script in geheugen geladen bij starten.

Nu heb ik het zelf ook nog maar een keer getest en voor mij werkt het wel. Je moet alleen even opletten hoe je die file aanpast. Sommige editors maken eerst een nieuwe file aan en renamen de oude en de nieuwe file.

Ik gebruikte het volgende script.

#/usr/bin/bash

echo aaaaa
sleep 1

echo aaaaa
sleep 1

echo aaaaa
sleep 1
...

en dan het commando:

vim /tmp/tst.sh
:%s/aaa/bbbg
:w!

(edit: in de eerste versie van deze post gebruikte ik sed maar krijg dat nu zo snel niet meer gerepliceerd)

output:

aaaaa
aaaaa
aaaaa
aaaaa
bbbaa
bbbaa
bbbaa
bbbaa
bbbaa
bbbaa
...

Let er ook even op dat je geen loops gebruikt, want het gaat pas fout als de interpreter naar de volgende regel gaat en bij een loop blijf je op dezelfde regel.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juli 2024 16:26]

[TheMak]

Dank, voor mij was het ook nieuw. Ik zou het tegenwoordig het als een bug zien ipv een feature, met deployments ipv on-the-fly even iets aanpassen.

[CurlyMo]

Deze bug / feature was mij niet bekend, en het lijkt ook niet generiek te zijn. Want hier blijft het oorspronkelijke script de output geven zoals het was tijdens de start.

# bash --version
GNU bash, version 5.1.4(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
# cat /etc/debian_version
11.1

[Reactie gewijzigd door CurlyMo op 23 juli 2024 16:26]

[wankel]

Deze bug / feature was mij niet bekend, en het lijkt ook niet generiek te zijn.
[...]

Ik denk dat het niet zozeer een bug of feature is, maar een eigenschap. Er zijn mensen die afraden om bestanden de verplaatsen en om in plaats daarvan copy/paste/delete aanraden in de veronderstelling dat verplaatsen bit-voor-bit gebeurt. Op veel systemen is een eigenschap van het reguliere move-command dat het op bestandssysteemniveau gebeurt, niet lager. Dat kun je ook als bug of als feature bestempelen, afhankelijk van wat je doel is. /offtopic

Het gedrag dat @CAPSLOCK2000 beschrijft (bedankt!) was mij ook niet bekend. Voordat er specifiek Linux-omgevingen gebashed worden, tools op Linux zijn veel gebruiksvriendelijker dan een gemiddelde HP/IBM/betaalde Unix-variant. Best kans dat het specifieke voorbeeld op zo'n HP-omgeving weer anders uitpakt.

[CAPSLOCK2000]

Deze bug / feature was mij niet bekend, en het lijkt ook niet generiek te zijn. Want hier blijft het oorspronkelijke script de output geven zoals het was tijdens de start.

Tot mijn schaamte heb ik een fout gemaakt in het commando dat ik hier boven postte, ik was de '-i' optie voor sed vergeten om "in place" te editten.

$ cat /etc/debian_version
bookworm/sid
$ bash --version
bash --version
GNU bash, version 5.1.12(1)-release (x86_64-pc-linux-gnu)

[CurlyMo]

Die heb ik vanzelfsprekend zelf toegevoegd

[CAPSLOCK2000]

Die heb ik vanzelfsprekend zelf toegevoegd

Mooi zo.
En nu lukt het mij ook niet meer.... Ik voel me een beetje lullig want ik weet zeker dat ik het voor mijn ogen heb zien gebeuren (en dat dit is zoals het "hoort"). Net nog een keer op een ander systeem geprobeerd met vim als editor en daar lukt het me weer om het script aan te passen terwijl het draait.

[CurlyMo]

Dat is dan misschien nog problematischer. Dat de werking niet betrouwbaar is. Als in dat je elke keer dezelfde werking mag verwachten.

[Jerie]

$ cat ./test.sh ; ./test.sh ; cat ./test.sh
#!/bin/bash
echo foo
sleep 2
sed -i '' 's/bar/foo/g' ./test.sh
sleep 2
echo bar
foo
bar
#!/bin/bash
echo foo
sleep 2
sed -i '' 's/foo/foo/g' ./test.sh
sleep 2
echo foo

Bash 5.1.2 @ macOS Big Sur.

(Zelfde resultaat op Bash 5.1.4 @ Debian GNU/Linux 11, Bash 5.1.8 @ Ubuntu 21.10. Die gebruiken GNU sed ipv BSD sed dus iets andere syntax: sed -i 's/bar/foo/' ./test.sh)

Maar wanneer loopt het fout? Vrij simpel. Stel je hebt een Cron script dat er een uur over doet (met find of wat dan ook (btw, fd is sneller)). En dat zit in een loop. En na de find voert hij een commando uit. Maar in de tussentijd update je het commando. Dit is een grote update, hele syntax is ineens anders (niet zo mooi, zal ook niet zo snel gebeuren, maar stel je voor van wel). Ineens gaat dat commando dan stuk op het resultaat van find. En in het geval dat je met rm werkt, dan heb je data loss. Dat is een equivalent tov wat hier plaats heeft gevonden.

[Reactie gewijzigd door Jerie op 23 juli 2024 16:26]

[rjvdboon]

Op Windows met batch files is het nog erger, daar onthoud de interpreter de byte positie. Als je tekens toevoegt/verwijdert vòòr de regel die op dat moment uitgevoerd wordt, dan gaat ie gewoon midden in een regel verder. Als je het weet is het niet zo erg, dan kun je er zelfs gebruik van maken. (Elke bug is voor iemand een feature )

[J_van_Ekris]

Hmmm, ik loop al enkele decennia mee, en ik kende deze manier om jezelf in de voet te schieten ook nog niet.

[karma4]

Zeer oud als je een systeem meegemaakt dat met disp=shr updates uitvoert.
ER zijn nog wel een aantal andere van dat soort valkuilen. big liitle endian bijvoorbeeld

[Xander2]

Dit geldt potentieel voor elk script omdat de inhoud in het TEXT segment terecht komt en de interpreter in het code segment. Als het script writable is dan zal een ondemand update naar geheugen plaatsvinden na wijziging, het is aan de interpreter hoe hiermee om te gaan.

Sowieso verstandig voor update proces te stoppen of het nou script of binary is, je hebt immers beperkte controle over geheugen en wanneer iets uit geheugen geswapped wordt.

[goarilla]

Op dezelfde regelnummer of ... op dezelfde offset in de file descriptor ? Wat me nog erger lijkt.

[Simon Weel]

Ai,klinkt een beetje als 'recover' onder good old DOS. De onwetende die denkt met recover een verwijdert bestand terug te kunnen halen. En daarna tot de ontdekking komt dat ALLE bestanden zijn hernoemd naar "Foundxxxxx"....

[m_snel]

Norton had een aantal recovery programma’s in die tijd, kon je veel mee terug halen.

Zelf ooit mijn 4 GB scsi schijf gesloopt door wat in de partitie tabel te doen.
Een tweede schijf gekocht, Windows geïnstalleerd en diverse programma’s geprobeerd. De meeste leverde dezelfde onzin bestanden op maar met 1 kon ik alles weer terug halen.

[Sinnergy]

Ja hier ook eens op eerste job hun hele NAS gedelete.. Was een typo in dat geval, kleine letter moest een hoofdletter zijn.. Nu ja, ik vroeg toen om een testomgeving om op te testen en kreeg het niet, tja..

Nu, uiteindelijk ~4uur werk kwijt want ze hadden dagelijkse backups, maar fun was anders (en veel evil eyes van collega's die dus alles opnieuw moesten doen wat ze die dag al gedaan hadden)

[rjd22]

Mag ik mijn persoonlijke respect uitspreken voor het feit dat ze volledige verantwoordelijkheid voor het probleem nemen?

In een tijd dat andere bedrijven bij dit soort problemen hun schouders ophalen (remember TransIP) lees ik hier het meest overtuigend geschreven excuses en dat ze voor compensatie gaan zorgen.

Dit is de houding die van van veel andere bedrijven zou verwachten maar het dan niet doen. Soms kan er niet eens een oprecht geschreven "het spijt ons" vanaf.

[Reactie gewijzigd door rjd22 op 23 juli 2024 16:26]

[Jerie]

Is Japan. Andere cultuur. Bieden veel gemakkelijker hun excuses aan. Waardoor de hoezeer het je spijt van belang is in de context.

Vergelijk het met referentie van vorige werkgever in Duitsland. Die mag aldaar niet negatief zijn. Gevolg: aan de hand van hoezeer men positief is kan men opmaken in hoeverre men tevreden was.

Kortom, er zijn nog steeds spectrums en gradaties maar ze liggen anders dan onze standaarden.

[Wannial]

Was het bij transip sowieso niet een 1tb best effort (en gratis) geval waar je vantevoren wist dat het geen backups had?

[PFY]

Maareh, je hebt toch retentie in je backups ? Ik kan niet 1 backup ( stel dagnummer 16) wissen in een retentie periode van 30 dagen. Maar ook al zou dit kunnen, dan alsnog kan ik naar 17 dagen geleden gaan en mijn backup terughalen/restoren. Ik snap niet helemaal wat dit met backuppen te maken heeft, want als je goed backupped en je backup is niet corrupt of encrypted (mal/ransomware) dan kan je altijd terug.

Wat wel kan is dat ik de retentie wijzig in mijn backup en dat mijn backup ipv 30 dagen naar 14 zet, dan gooit die automatisch 16 dagen weg.

[aikebah]

Wat wel kan is dat ik de retentie wijzig in mijn backup en dat mijn backup ipv 30 dagen naar 14 zet, dan gooit die automatisch 16 dagen weg.

Als je goed tussen de regels doorleest is dat precies wat er gebeurde: de retentie werd effectief per ongeluk op 0 seconden gezet.

[PFY]

Oh, ok, dat is dan wel desastreus. En dat via een script ? Wordt wellicht toch wel tijd voor een gui zodat je ziet wat je doet als je toch niet al te veel ervaring met scripts hebt ? En soort van mega disclaimer dat als je je retentie naar 0 zet dat je je backups kwijt bent ?

[aikebah]

Dat door een script aan te passen terwijl het uitgevoerd wordt, waarbij de script-uitvoering regel voor regel ophaalt, uitvoert en dan teruggaat naar de file voor de volgende opdracht.
De tweede helft van de scriptregels werd dus het aangepaste script uitgevoerd, de eerste helft nog het oude script. (en in de eerste helft werden nou juist de juiste variabelen gezet voor een correcte retentietijd)

[PFY]

ok, maar dan nog heb je een source en een data, misschien heb ik het nog steeds niet door, maar hoe kan de source van de data dan ook weg zijn ? Of is alleen de target weg ? Dat is op zich geen probleem, echter de backups heb je niet meer. En dan nog heb je programma`s om data terug te halen echter in geval van zero overwrites is het echt weg...

[GoBieN-Be]

Het betreft geen file server, maar een supercomputer. Zelf back-ups maken van deze enorme datasets waarmee deze supercomputers soms aan de slag gaan is niet evident.

Wellicht licht de verantwoordelijkheid voor back-ups van de datasets bij de eigen systemen van iedere afdeling. Maar is door deze fout de dataset en bijhorende resultaten verwijderd alvorens de gebruikers deze wellicht al naar hun eigen systemen overgedragen hebben.

Volgens de eerder geplaatst vertaling, is het een script dat log bestanden opkuist die ouder zijn dan x dagen (daarom het find met -rm {} commando).

Het liep dus mis bij het aanpassen van het script terwijl het juist bezig was. Waardoor de find plots met verkeerde filters ging verwijderen.
Bijgevolg zijn (bijna) alle bestanden op het filesystem verwijderd.

Als de afdelingen en gebruikers moeten betalen voor het gebruik dan is het terecht dat ze gecompenseerd worden. Ze gaan wellicht de berekeningen opnieuw moeten doen namelijk.

[Reactie gewijzigd door GoBieN-Be op 23 juli 2024 16:26]

[wankel]

Wordt wellicht toch wel tijd voor een gui zodat je ziet wat je doet als je toch niet al te veel ervaring met scripts hebt ?

Ik zit niet op de HRM-afdeling van die Uni, maar ik gok dat ze geen stagair op de backup-updates gezet hebben. Die GUI moet ook geprogrammeerd worden (en getest), en is waarschijnlijk voor de beheerders minder efficient dan scripting. Scripts kun je aan elkaar plakken en toch overzicht houden; met GUI's is dat best lastig.

[WillySis]

Het blijft heel vervelend, maar op een supercomputer worden meestal uncompressed databestanden neergezet. Vaak zijn dat enorme matrixen die geextraheerd zijn uit normale databases.
De echte onderzoeksgegevens staan vaak op de computer van de onderzoeker zelf en ergens op het netwerk of in de cloud.
Daar onderzoekers bekend staan als slechte opruimers van hun gebruikte bestanden zal een deel van de verloren gegane data gewoon oude rommel zijn.
Er zal heus wel wat aan data verloren zijn gegaan, maar de basisgegevens van het grootste deel van de 77TB zal vermoedelijk nog wel ergens terug te vinden zijn.

[Pooj]

Dus altijd: set -Eeu

[RuudAnders]

-E

If set, any trap on ERR is inherited by shell functions, command substitutions, and commands executed in a subshell environment. The ERR trap is normally not inherited in such cases.

-e

Exit immediately if a pipeline, which may consist of a single simple command, a list, or a compound command returns a non-zero status. The shell does not exit if the command that fails is part of the command list immediately following a while or until keyword, part of the test in an if statement

-u

Treat unset variables and parameters other than the special parameters ‘@’ or ‘*’ as an error when performing parameter expansion. An error message will be written to the standard error, and a non-interactive shell will exit.

De -eu vangen dus algehele foutcondities af tijdens het uitvoeren van een script zonder dat je handmatig overal checks hoeft toe te voegen. '-E' zorgt ervoor dat als een user-defined bash functie returned door een error, dat dan het gehele script stopt.

[Reactie gewijzigd door RuudAnders op 23 juli 2024 16:26]

[CAPSLOCK2000]

Dus altijd: set -Eeu

Dit is ontzettend goed advies, ook al is het maar een hele korte post.
Dit had vrijwel zeker voorkomen dat het zou fout was gegaan.
De backup zou nog steeds niet goed zijn gegaan maar met deze opties wat het script waarschijnlijk gestopt met een foutmelding voordat er data verwijderd zou zijn.

[Taquila]

Kun je er ook bij vertellen wat dit doet?

[HoeZoWie]

Update op dit verhaal.....
https://www-tomshardware-...se-of-hpe-software-update

[Brahman]

Ik ken het... Je verwacht een return te krijgen in de trend van ' 5 files processed'. Je drukt op enter en je return komt iets later dan verwacht. '34.531.457 files processed'.

Kak, ik had de filter nog uit gecomment....

[Blokker_1999]

Of misschien sneller dan verwacht.

https://www.youtube.com/watch?v=X6NJkWbM1xk

[humptiedumptie]

Instructief verhaal, maar een database heeft een transaction log waar alle wijzigingen in bewaard blijven.
Dat maakt het mogelijk een point in time restore uit te voeren, op een andere server, update scriptje genereren en dan productie herstellen. Dit was m.i. makkelijk te herstellen.
https://dev.mysql.com/doc...int-in-time-recovery.html

[Joolee]

Bovendien moet die transaction-log dan ook wel aan staan. Als je DB systeem dat niet standaard heeft, begin je er vaak pas aan als je aan replicatie of multi-node systemen begint. Je kunt dan nog wel gebruik maken van transacties (zoals volgens mij ook genoemd in de video) maar dat moet je wel weten en je moet er aan denken. Dat doe je meestal pas als je jezelf een paar keer goed gebrand hebt

[360Degreez]

In de huidige versie ja. Het verhaal uit de video speelde in een tijd waar de feature waarschijnlijk nog niet geïmplementeerd was.

[SPee]

Niet alles wordt daarin bijgehouden (bv truncate) en niet elke database heeft dat (standaard) aan.

[Sjeefr]

Ik denk dat ik die video maar eens op mijn jaarlijkse development-herinneringen lijst zet. Ik zie mijzelf wel als professioneel ontwikkelaar, maar stukje extra voorzichtigheid en een schep minder gemakzucht zal mijzelf en vele developers een hoop moeite schelen

[AJM94]

Ik hoopte al dat iemand deze video van Tom Scott had gepost.

1 Van de comments slaat ook de spijker op zijn kop: "coding is awful because the computer does exactly what you tell it to, not what you want it to".

[pangolin2]

Wat kan die gast (van het youtube filmpje) goed de aandacht vasthouden zeg!

[Reactie gewijzigd door pangolin2 op 23 juli 2024 16:26]

[CurlyMo]

Ik moest denken aan de wijze woorden van @SchizoDuckie van gisteren over precies de moraal van deze video:

Deze medewerker maakt deze fout NOOIT meer. Die heeft z'n straf gehad en zal in de toekomst een van je grotere assets worden. Hij heeft echt wel skills anders kun je niet een hele CI omgeving optuigen.

Als ze hem er bij de belastingdienst uit zouden gooien zou ik mijn werkgever hem zo een baan laten aanbieden.

[GTACrime]

Bron?

[wild_dog]

Is het Tom Scott?

EDIT: Ja, het is Tom Scott over de Oneeseconde

[Reactie gewijzigd door wild_dog op 23 juli 2024 16:26]

[HaterFrame]

Ha dat zijn bekende foutjes idd.... Ik had ooit eens een filtertje gemaakt welke alle bestanden onder de 90mb zou verwijderen. Alleen vergeten te specificeren voor welke folder dat was, het gevolg laat zich raden en ik flink stress

[Verwijderd]

Of een online backup die ervoor zorgt dat je schijf vol loopt. Want ja, een home directory die gebackupt wordt zit ook een mapje in die synct met de root van de online backupschijf. Iets met een neerwaartse spiraal

[computerjunky]

Lijkt op een probleem wat ik jaren geleden gehad heb. De backup maakte ook een backup van de backups. Elke backup werd dus groter en groter en groter.
Uiteindelijk zelf een backup gemaakt wat 2 dagen kostte en de backups verwijderd en het anders opgezet. Software....

[Verwijderd]

Ongeveer hetzelfde hier, ik vond het al zo lang duren Ik was een initiële backup aan het maken en Insync syncte vrolijk de zojuist aangemaakte backupmap met de computer. Ik kwam er pas achter dat ik een melding kreeg dat er nog maar 400MB van de schijfruimte over was.

[DrPoncho]

Haha herkenbaar

[Reactie gewijzigd door DrPoncho op 23 juli 2024 16:26]

[kevlar01]

Aii pijnlijk.. in een klap van universiteit terug naar basisschool

Serieuzere noot: ik hoop dat ze wel een soort maandbackup systeem hebben met tapes waardoor er niet te veel qua 'tijd' is verloren.

[Fermion]

Maar HPE wordt wereldwijd ingezet, ze hebben meerdere soorten producten en dit is natuurlijk afgestemd op deze situatie. Ben toch benieuwd of er geen meer bedrijven last van hebben, want ik lees het artikel als een fout in het software van HPE.

[JackBol]

Die backup scripts worden aangepast aan de situatie.
Ze hebben hier gewoon een typo gemaakt in de config file waardoor het delete script iets te eager werd.

Fail-open in plaats van fail-close helaas.

[CAPSLOCK2000]

Ze hebben hier gewoon een typo gemaakt in de config file waardoor het delete script iets te eager werd.

Nee, ze hebben het script overschreven terwijl het actief was. Dat mag niet maar dat weet geen mens. Mensen gaan er van uit dat de oude file bewaard blijft zolang dat script loopt want zo gaat dat met de meeste andere software.

[Fermion]

Vreemde situatie hier, blijkbaar is een retentie periode niet in deze backup oplossing ingebracht. Dat zou ervoor moeten zorgen dat niet alles kwijt is.

[Blokker_1999]

Als ik dit lees

De onderzoeksfaciliteit gaat verder werken met mirrors van back-ups en het intact laten van eerdere generaties van back-ups.

dan heb ik het gevoel dat er enkel deltas bijgehouden werden.

[JackBol]

Er is niets mis met delta's bijhouden. Zolang je maar geen backup data delete
En zo nu en dan eens alles op tape krassen en in de kluis leggen.

[Zer0]

Zolang je maar geen backup data delete

Ook dat hoeft geen probleem te zijn, als er maar eerst consolidatie plaats vind.

[beerse]

Voor een universiteit zou dit zomaar een grote hoop gegevens kunnen zijn uit metingen en zo, dat het allemaal bij elkaar hoort en dat het experiment nu de gegevens kwijt is.

Maar voor alle anderen: Laat dit een voorbeeld zijn waarom je niet alles op 1 hoop moet backuppen. Natuurlijk is het handig om alles naar 1 centrale backup te sturen. Maar gaat het mis dat ben je dus ook in 1 keer alles kwijt.

[rob12424]

Dit is ook de reden waarom PI's hier draagbare harde schijven aan hun onderzoekers uitdelen. De cloud is leuk opslag is leuk. Maar het is handig als er iets aan data toch ergens anders ligt.

Vergis je overigens niet: een goeie DNA/RNA sequencing kan soms al 20 GB beslaan.

Als het hier om onderzoeksdata gaat. Een PhD doet gemiddeld 4-5 jaar hier. Volgens mij 3 jaar in japan. Ben je net bijna klaar.... 3 jaar vergooit.

[The Zep Man]

Dit is ook de reden waarom PI's hier draagbare harde schijven aan hun onderzoekers uitdelen. De cloud is leuk opslag is leuk. Maar het is handig als er iets aan data toch ergens anders ligt.

Eén backup is geen backup. Een goede vuistregel is dat voor normale backups twee locaties gehanteerd worden (backup on-site, backup offsite). Voor kritische data voeg je daar een extra offsite aan toe.

Vergis je overigens niet: een goeie DNA/RNA sequencing kan soms al 20 GB beslaan.

Opslag kost niets t.o.v. het verliezen van kritische data. 20 GB is vandaag de dag 'niets' als we praten over backups.

Als het hier om onderzoeksdata gaat. Een PhD doet gemiddeld 4-5 jaar hier. Volgens mij 3 jaar in japan. Ben je net bijna klaar.... 3 jaar vergooit.

Daarom dat een slimme PhD niet enkel vertrouwt op de backupfaciliteiten van de universiteit.

Wat men vaak ook vergeet in backupprocedures is het testen van het herstelproces. Zonder herstelprocedure maak je effectief geen backups.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 16:26]

[rob12424]

Wij zijn ook geen universiteit 😉😅 Maar er zijn meer backups. (Zowel in als off-site)

Punt is alleen die 20;gig. Is 1 DNA sequencing. Sommigen doen er 300 op een dag. 😅Als je dan met harde schijven/ssd's moet gaan sjouwen is ook niet alles 😉

[The Zep Man]

Punt is alleen die 20;gig. Is 1 DNA sequencing. Sommigen doen er 300 op een dag. 😅Als je dan met harde schijven/ssd's moet gaan sjouwen is ook niet alles 😉

300 x 20 GB = 6 TB. Met één van deze kan je al twee dagen aan ruwe data opslaan. Verder zal ook niet elke sequence permanent opgeslagen hoeven te worden, en uiteraard is er ook zoiets als compressie.

Het punt is dat het niet onbetaalbaar is om grote hoeveelheden data op te slaan, zeker niet als je een goede voorbereiding daarvoor treft.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 16:26]

[karma4]

Het staat elders in een datacenter niet op de persoonlijke laptop.
Wil je die hoeveelheden data over het netwerk naar je laptop brengen dan heb je echte wel een uitdaging met de doorlooptijd. Heb je het over de backup aan de andere kant dan moe je 100+ TiB in het backup systeem te krijgen. Doe je er meerdere versies van, dan is het ineens zeer veel en toch weer erg kostbaar

[MazDaMan1970]

Was ook mijn 1e gedachte, blijkbaar was dit raw data, waardoor lopende onderzoeken/berekeningen ernstig geschaad worden. Vermoedelijk is men zo'n week aan data kwijt, op deze wijze. Met als neveneffect, dat bepaalde projecten op een flinke achterstand komen te staan.

[Bender]

Als ik het goed lees zijn backups verloren, maar dus niet de actuele data? Wat het probleem toch wel anders maakt.

Of mis ik een deel?

[Yngwie-]

In veel backup software zit een "delete after successful backup" optie, een soort van archiveren en verwijderen uit de live omgeving zeg maar. Als zo'n optie aangezet is, en na die backup job nog een cycle gedraaid heeft (en er geen retentie ingesteld is) is de data door de eerste backup verwijderd en is de nieuwe backup job leeg. Uit het artikel is niet terug te halen of zoiets aan de hand geweest is, maar het klinkt als zo'n situatie ongeveer.

[TheMak]

Het klinkt eerder als iets als in een lange script waar "find /mnt/${systeem}/ -older than drie dagen -exec delete {} \;" waarbij ${systeem} netjes geconfigureerd is op acceptatie, en getest is. En op productie nog niet....

[Bender]

Ik ken de functie zelf niet uit backup software, maar het zal ongetwijfeld bestaan.

Echter naar mijn idee is een archiveerfunctie wel weer iets anders dan een backup (ivm opslaglocatie, encryptie, performance, indexatie, etc).

[PjotterP]

Ai. Benieuwd om wat voor data het echt gaat. 77TB kan door iets gegenereerd zijn dat veel data honger heeft maar waar niet veel werk in zit en/of al outdated is, maar het kan ook staan voor actuele data en/of enorm veel werkuren die verloren zijn gegaan

[JackBol]

Als de data al outdated was, hadden die researchers al wel een opruimslag gedaan. Departments krijgen gewoon een rekening voor storage use en maandelijkse invoice voor 77TB storage is geen geneuzel in de marge.

[HuHu]

Wij betalen 300 euro per jaar per terabyte opslag en back-up (inclusief, dus de back-up telt niet los tegen de opslag). Honderd terabyte lost dus 30.000 euro per jaar, dat is te overzien voor een afdeling of universiteit. Ook omdat kosten voor opslag vaak vergoed worden door subsidieverstrekkers.

[computerjunky]

Dat klinkt heeeeel duur als je kijkt naar de prijzen van een nas hdd. Voor sat geld kan je goedkoper zelf een server opzetten met drives en backup systeem.
Voor dat geld heb je 5x zoveel opslag en ook nog eens een backup daarvan.

Enige punt is de server maar dan nog over meerdere jaren gerekend os dat een enorme kostenbesparing.

[Guru Evi]

Maar je hebt er ook geen beheerder, garanties, netwerk switches/verbindingen, minimum garantie aan IOPS en bandbreedte, rack, koeling, energie etc etc

Er zit meer in storage dan je denkt. Flash is tegenwoordig goedkoper dan schijven in de meeste datacenters omdat je dichter kan verpakken en minder ruimte, koeling nodig hebt (200TB in 2U) maar het kost wel $500/TB/jaar over 5 jaar.

[Frame164]

Als je alleen de kosten van de opslagdevices berekent moet iemand in z'n vrije tijd de rest doen. Daar is dan immers geen budget meer voor. Als onderzoekers dit er naast moeten doen ben je ook niet echt professioneel bezig.

[JackBol]

In plaats van niet gebruikte data kan je die 30.000 ook uitgeven aan een extra PhD positie.

[psychodude]

Er zit bij sommige data op basis van regelgeving een ruime bewaartermijn. Binnen de medische wereld heb je het over ten minste 15 jaar, tor zelfs 30 jaar, binnen Nederland. En met o.a. meer en meer beeldvorming, lopen die opslagcijfers ook aanzienlijk op.

[pennenlikker]

Natuurlijk niet handig maar als dat cluster vol gas staat te rekenen met 150GB/s is er dus zo'n 8,5 minuten aan data weg. Zet dingen wel in perspectief, kan natuurlijk ook zijn dat er hele belangrijke documenten verdwenen zijn maar dat staat er niet bij.

[JonPalle]

Het hoeft niet alleen nieuwe data te zijn. Het kan ook oude data zijn welke bewerkt is met nieuwe inzichten of gegevens. Het lijkt dan een klein probleem maar daar kan dan wel onnoemelijk veel werk in zitten. En iets wat je reeds bedacht of gemaakt hebt zal in de herhaling nooit hetzelfde zijn.

[8mile13]

Dat is het probleem met data. Het lijkt mij verstandig om op verschillende manieren data te bewaren.