B&R 16 - Automatisches Löschen bei Vollaufen des Speicherplatzes scheitert

Ich habe mit B&R 16 einen vordefinierten, täglichen Sicherungsauftrag laufen (Basis + 6 Inkremente).
Aufräumoption: Die älteste Sicherungskette automatisch löschen, wenn das Sicherungsziel vollläuft.
Speicherort für die Archive ist eine eigens dafür bestimmte Partition (F). Auf dieser liegen mittlerweile drei komplette Sicherungsketten aus diesem Auftrag und (in einem anderen Ordner) noch eine Ursicherung mit 5 Inkrementen. Gestern wäre nun die routinemäßige Erstellung eines neuen Basisarchivs an der Reihe gewesen, wofür jedoch offenbar der Speicherplatz auf (F) nicht mehr ausreichte. Es wurde jedoch nicht die älteste Sicherungskette gelöscht, sondern die Sicherung schlug fehl (Fehlercode 0x11115, Nicht genügend Festplattenspeicher vorhanden).
Hat jemand eine Idee, woran das liegen kann?

Vorher hatte ich übrigens festgelegt, mindestens 14 Sicherungen (2 Sicherungsketten) zu behalten. Hierbei funktionierte das automatische Löschen einwandfrei.

Hallo, redbull21,

nachdem ich das jetzt extra mal ausprobiert habe und es prima geklappt hat, vermute ich, dass aus irgendeinem Grund ein Bruch in Deinen Ketten ist. Bei mir wurde sogar eine ganze Kette gelöscht, um das neue Vollbackup zu schreiben. Da ich als Ziel einen USB-Stick genommen habe, ging nicht mehr drauf, so dass bei einem Fehlschlagen des Vollbackups sogar gar keine Sicherung dagewesen wäre, was ich auch nicht so lustig gefunden hätte. Da müssen unsere Produktspezialisten sich noch was überlegen. Aber - wie gesagt - im Prinzip funktionierts.

Danke.
Ich teste das aktuell noch weiter aus, vielleicht lag es ja wirklich an einer besonderen Konstellation.
Grundsätzlich darf ja keinesfalls die älteste Sicherungskette zwecks Platzgewinnung gelöscht werden, wenn nicht mindestens eine Vollsicherung übrig bleibt. Anderenfalls stünde man, wie richtig bemerkt, bei Fehlschlagen der neuen Sicherung "nackt" da.
Im Prinzip weiß das Prog ja vorher, wieviel Platz die neue Sicherung brauchen wird. Reicht der Platz vsl. nicht, müsste zunächst die älteste Sicherungskette gelöscht werden und dann erst die neue Sicherung starten. Das darf aber eben nur dann erlaubt sein, wenn die älteste Kette nicht zugleich auch die einzige ist. Ansonsten ist es wohl wirklich besser, lieber die Sicherung abzubrechen und einen Fehlerhinweis "Platzmangel" zu generieren, statt die einzig verbliebene Sicherung zu löschen, bevor die neue fertig ist.
In meinem Fall aber wären ja mehrere Sicherungsketten als Reserve vorhanden gewesen, sodass die älteste Kette bedenkenlos hätte gelöscht werden können. Aber sie wurde eben trotzdem nicht gelöscht, sondern die neue Sicherung wurde wg. Platzmangels abgebrochen (und das wundert mich hier eben).
Je intensiver man über die Problematik nachdenkt, umso klarer wird einem, wie komplex eine wirklich unfehlbare Lösung hier aussehen müsste, damit es immer und unter allen Umständen passt und immer auch mindestens eine Reservesicherung erhalten bleibt. Vor allem bei Aufträgen mit Inkrementenmethode ist das vielleicht tatsächlich nicht mit kompletter Perfektion beherrschbar.

Die Grobsystematik im Programmablauf kann in meiner bescheidenen Vorstellung eigentlich nur folgende sein:

A. Neue Sicherung läuft durch, alles paletti.
Oder
B. Neue Sicherung läuft in Platzmangel hinein, dann Sicherung anhalten und prüfen ob eine (ausreichend große) Altsicherung(skette) gefahrlos gelöscht werden kann, sprich mindestens eine Sicherungskette verbleibt.
wenn ja
B1. Altsicherung löschen und angehaltene Sicherung fortsetzen.
wenn nein
B2. angehaltene Sicherung abbrechen mit Fehlerhinweis "Platzmangel". (Ob dann die einzig übrige Sicherung gelöscht oder woanders hin verschoben wird, muss in jedem Fall der User entscheiden, niemals aber das Programm)

In den allermeisten Fällen sollte das so fehlerfrei funktionieren, oder?
Wer aber auf seinem Sicherungslaufwerk nicht wenigstens 3 Sicherungsketten unterbringen kann, sollte wohl besser eine andere Aufräumoption wählen.