Die Kyoto-Universität in Japan hat Ende 2021 77 TByte an Forschungsdaten verloren. Der Grund: Ein Script-Update hat die Backups von den Servern gelöscht … verteilte ein Update für ein Backup-Script, das Log-Dateien nach zehn Tagen automatisch löscht. Dabei sollte nur dessen Sichtbarkeit und Nachvollziehbarkeit durch neue Variablennamen verbessert werden. Stattdessen habe das Script aber beim Aufspielen ein anderes, laufendes Bash-Script überschrieben – undefinierte Variablen und das anschließende Löschen echter Dateien statt Loggingeinträgen waren die Folge.
Ich bin mir natürlich nicht sicher, aber es hört sich schon sehr nach der alten Script-Krankheit von Linux an: Ein laufendes Script wird direkt von der Festplatte abgearbeitet, und zwar so, wie das seinerzeit unter MS-DOS passiert ist. Hingegen laden fast alle modernen Systeme inzwischen, wegen genau solcher Probleme, wie sich das für die Kyoto-Universität anhört, Scripte in den Speicher und führen sie von dort aus. Dann ist es egal, ob das Script auf der Platte bearbeitet wird – dessen geänderter Code wird ja erst mit dem nächsten Start ausgeführt.
Natürlich sollte es in Linux aber eigentlich gar kein Script geben, das dauernd ausgeführt wird und selbst steuert, wann es was machen soll. Dafür wäre die crontab zuständig. Das behebt das Risiko zwar nicht, reduziert es aber erheblich. Und für solche Fälle, die mit crontab nicht abgebildet werden können, gibt es dann noch inotifywait. Aber das sind alles nur Notbehelfe.
Ich hoffe schon lange, dass endlich Scripte unter Linux nicht mehr direkt von der Festplatte ausgeführt werden. Ich fühle mich dabei immer so steinzeitlich. Mir erschließt sich auch der Sinn nicht, denn es gibt überhaupt keinen zuverlässigen Weg, das für irgendwas auszunutzen (weil man nämlich nicht wissen kann, an welcher Stelle des Scriptes gerade ausgeführt wird). Vielleicht kann die leidgeprüfte Kyoto-Universität da nun etwas ausrichten.