Ein Name für die Ewigkeit, in dreißig Sekunden vergeben

1. September 2026

An einem Veeam-Job lässt sich fast alles nachträglich geradeziehen. Aufbewahrung, Zeitplan, Repository, Verschlüsselung, Benachrichtigungen — alles Felder, die man aufmacht, ändert und wieder zumacht. Eine Ausnahme gibt es. Sie steht ganz oben im Assistenten, sieht nach nichts aus und ist in dreißig Sekunden erledigt: das Namensfeld.

Wie wir Jobs benennen

Unsere Konvention setzt den Namen aus fünf Teilen zusammen:

<Retention>_<OFFSITE>_<GEO>_<APP>_<ENV>

Ein Job heißt damit etwa std_OFFSITE_DE_FILE_PROD. Fällt eine Stelle weg, bleibt sie als doppelter Unterstrich stehen, damit die Position stimmt: ohne Kopie außer Haus std__DE_FILE_PROD, ohne Anwendung prm__EMEA__PROD.

std oder prm ist der Aufbewahrungsstandard. std bedeutet 30 Tage täglich, dazu 4 wöchentliche, 12 monatliche und ein jährliches Backup. prm verlängert die täglichen auf 60 Tage, der Rest bleibt gleich.
OFFSITE steht nur dort, wo tatsächlich ein Copy Job dranhängt.
DE ist das Land, EMEA die Region — dazu unten mehr.
FILE ist die Anwendung — daneben SQL, SQLnoLog, EXCHANGE, AD, WEB. Die Stelle steht nicht zur Zierde im Namen: Sie sagt, wie das Guest Processing eingestellt ist. SQL und EXCHANGE schneiden Logs ab, SQLnoLog lässt sie stehen.
PROD ist die Umgebung — daneben TEST, DEV und cust_<kürzel> für Systeme eines Endkunden, den man als Dienstleister mitsichert.

Zwei Ergänzungen, die sich aus dem Betrieb ergeben haben: Linux-Maschinen bekommen einen eigenen Job mit dem Suffix __LINUX, weil sie ohne Guest Processing laufen und der Windows-Job sie ausschließt. Und bei vielen Endkunden auf einem Backup-Server gibt es einen Job je Endkunde — nicht aus Ordnungsliebe, sondern weil Aufbewahrung, Verschlüsselung und Restore-Rechte sonst nicht sauber zu trennen sind.

Der Zweck ist bescheiden und wirkt trotzdem: Man liest aus der Job-Liste ab, welchen Schutz eine Maschine hat, ohne irgendwo nachzuschlagen. Bei vier Jobs braucht das niemand. Bei achtzig ist es der Unterschied zwischen einem Überblick und einem Nachmittag.

Der Haken

Umbenennen lässt sich ein Job. Nur eben halb.

Veeam zieht die Backup-Auflistung nicht mit, und die Datei- und Ordnernamen im Repository auch nicht. Nach einer Umbenennung heißt der Job das eine und liegen die Daten unter dem anderen. Von Hand aufzuräumen ist das kaum, und wer es versucht, riskiert an einer Stelle etwas, an der man nichts riskieren möchte.

Das Ergebnis ist schlechter als vorher: Statt eines veralteten Namens hat man zwei verschiedene, die beide stimmen könnten.

Der Job-Name ist damit die einzige Einbahnstraße in der ganzen Konfiguration.

Ausgerechnet das Feld, das sich am ehesten ändert

Nun steht vorne im Namen die Aufbewahrung. Und die Aufbewahrung ist genau das, was sich im Leben eines Jobs am ehesten ändert. Eine Maschine wird wichtiger, aus std wird prm — zwei Klicks im Retention-Feld, völlig unspektakulär.

Der Name bleibt std_... und ist ab diesem Moment falsch.

Er ist nicht irgendwo falsch, sondern an der meistgelesenen Stelle der Umgebung. Die Job-Liste ist für die meisten der erste Blick und für viele der einzige. Wer dort std liest, geht von dreißig Tagen aus, und niemand hat einen Anlass, das nachzurechnen — die Zahl steht ja da.

Das ist derselbe Mechanismus, der auch bei dreißig Wiederherstellungspunkten zuschlägt oder bei einer Sperrfrist, die länger hält als die Aufbewahrung : Nichts ist kaputt, nichts wird rot, eine Anzeige bedeutet nur etwas anderes als das, was jemand gemeint hat.

Das Feld, das mitwächst

Dagegen hilft ein zweites Feld, das direkt daneben liegt und dauerhaft änderbar bleibt: die Beschreibung.

Dorthin gehört alles, was lebt — Besonderheiten des Jobs, die Wiederherstellungsstrategie, warum die Aufbewahrung angehoben wurde und wann. Vier Angaben stehen immer drin: wer den Job angelegt oder geändert hat, wann, warum, und welches Ticket dazugehört. Wir füllen sie beim Anlegen aus, nicht erst dann, wenn sie jemand braucht. Wer sie braucht, hat meistens gerade keine Zeit, sie zu schreiben.

Der Job, dessen Name nicht falsch werden kann

Es gibt einen Weg, auf dem das std-Problem von oben gar nicht entsteht. Ab ein paar Dutzend VMs pflegen wir keine VM-Listen mehr in Jobs. Stattdessen bekommt jede VM im vCenter Tags aus sieben Kategorien — Aufbewahrung, Offsite, Region, Anwendung, Scope, Endkunde, Betriebssystem — und der Job sammelt eine Tag-Kombination ein. prm_OFFSITE_EMEA_SQL_PROD enthält genau die VMs mit 1-premium backup, 2-offsite backup, 3-EMEA, 4-SQL und 5-production.

Der Name ist damit nichts anderes als die Tag-Kombination in Kurzform. Wird eine Maschine wichtiger, ändert niemand den Job: Die VM bekommt 1-premium backup statt 1-standard backup und liegt beim nächsten Lauf im prm-Job. Der std-Job heißt weiter std und enthält weiter nur Standard-Maschinen. Eine neue VM bekommt ihre Tags und ist gesichert, ohne dass jemand einen Job anfasst.

Der Haken daran ist klein und gemein: Ein Job, dessen Tag-Kombination gerade keine VM trifft, ist leer und schlägt fehl. Deshalb liegt in jedem Tag-Job zusätzlich eine VeeamJobDummy-VM — leer, ohne Betriebssystem, eine Platte von ein paar Megabyte, ausgeschaltet. Der Job läuft grün, und ein Job ohne echte VMs fällt trotzdem auf: am Backup-Volumen.

Das Feld, das wir lange nicht entschieden haben

Ehrlicherweise gehört dazu, dass unsere eigene Konvention an einer Stelle jahrelang offen war. Für den geografischen Teil gibt es zwei Wege: grobe Regionen wie EMEA oder APAC, oder die Länderkennung wie DE und FR. Festgelegt wurde lange nicht, welcher gilt. In derselben Umgebung standen also std_EMEA_FILE_PROD und std_DE_FILE_PROD nebeneinander und meinten dasselbe.

Inzwischen steht eine Regel im Standard: Land oder Region, pro Umgebung einheitlich, nicht mischen. Das ist eine halbe Entscheidung. Sie legt nichts fest, sie verbietet nur das Mischen — und in den Umgebungen, in denen schon gemischt wurde, ändert sie nichts, weil sich die Namen nicht ändern lassen. Jede Runde Unentschiedenheit wird dauerhaft mitgeschleppt.

Und ein Standard auf dem Papier ist noch keine Umgebung, die ihm folgt. Bei uns steht die Vereinheitlichung der Backup- und VM-Namen seit Jahren auf der Liste der Dinge, die regelmäßig stören und selten drankommen. Für dieses Jahr steht sie als eigener Auftrag drauf. Ob das reicht, wird man sehen.

Die Regel

In den Namen gehört nur, was sich nicht ändert.

Alles andere gehört in die Beschreibung. Und weil ein Name eine Einwegentscheidung ist, wird das Schema einmal vollständig entschieden, bevor der erste Job angelegt wird — einschließlich der Felder, die im Moment niemanden interessieren.

Ein Feld, das man offen lässt, wird nicht später geklärt. Es bleibt offen, solange die Umgebung steht.

Damit niemand das Schema im Kopf zusammensetzen muss, haben wir es in ein Werkzeug gegossen: Bauplan nimmt RPO, RTO, Aufbewahrung, Anwendung und Umgebung je System und gibt Job-Namen, Copy-Job-Namen, Zeitplan, Beschreibung und Tag-Kombination aus. Das ist Eigenwerbung — und der Grund, warum die dreißig Sekunden am Namensfeld bei uns nicht mehr aus dem Bauch kommen.