File Eraser programmieren

[3_of_8]

Nein, ich frage jetzt nicht, wie man einen File Eraser schreibt. Hab ich nämlich schon. Mit Chrissi91.

Meine Frage ist nur: Warum sollte man ein und dieselbe Datei mehrmals mit zufälligen Daten überschreiben? Reicht das nicht einmal?

Und, wird mit deletefile() der Header (oder wie das beiner Datei heißt) ganz gelöscht, sodass man nicht mehr sagen kann "Es gab mal ne Datei mit dem Namen..." und wenn nicht, wie kriege ich den weg?

[Matze]

AH, du fragst mal nach einem simplen programm ;)
( Löschen ginge so: http://www.delphipraxis.net/internal...=478795#478795 )

Anmerkung:
Sicher ist nichts, das die Hardware ganz lässt, da die Profis die Restmagnetisierung mit diversen Tools und Gerätschaften auslesen können und damit meistens Dateien wiederherstellen, von denen du sicher warst, dass das nicht mehr geht.

[3_of_8]

Nein, ich habe schon ein Programm. Ich frage, warum man eine Datei mehrmals überschreiben soll.

Das mit der EM-Signatur hab ich schonmal in Navy CIS gesehen, aber ich wusste ned, ob das stimmt. Glaube niemals dem Fernsehen.

[DP-Maintenance]

Dieses Thema wurde von "alcaeus" von "Sonstige Fragen zu Delphi" nach "Programmieren allgemein" verschoben.
Ist eine allgemeine Frage, also mal nach \\"Programmieren Allgemein\\" ;)

[Oxmyx]

Ganz einfach: Selbst wenn du physikalischen Speicher mit anderen Daten überschreibst, kann man mit extrem feinfühligen Geräten trotzdem noch die Restmagnetisierung der Datei, die vorher dort war, messen. Wenn man quasi die Magnetisierung der "aktuellen" Daten herausrechnet, kann man tatsächlich noch die Magnetisierung der vorherigen Daten erkennen. Das kannst du verhindern, indem du einfach oft genug irgendwelche Daten drüberschreibst. Denn irgendwann versumpft einfach alles im Datenbrei.

[3_of_8]

Achso. Heißt praktisch, ich kann durch oft genug überschreiben auch die EM-Signatur noch unbrauchbar machen. Hätte ich nicht gedacht.

Ich habe mal gehört, dass ein Programm eine Datei zuerst mit dem Muster 00001111 und dann mit 11110000 überschreibt. Was hat das für einen Sinn?

[himitsu]

also die großen Programme, welche sowas machen, gehen oftmals mit verschienenen Bitmustern drüber, damit auch wirklich jedes Bit ofgenug überschrieben/geändert wird.


Denn wenn du eine 1 über 'ne 1 drüberschreiben läßt, dann verändert sich da nicht viel.
Und über eine gut gewählte BitMusterkombination, kann eher garantiert werden, daß die einzelnen Bits auch oft genug geändert werden.

Du kannst ja z.B. nacheinander sowas reinschreiben, dann es "sichergetellt, daß die einzelnen Bits immer schön umgekehrt werden und somit die restdaten langsam verschwinden.

Delphi-Quellcode:

11110000
00001111
11110000
00001111
... // mehrfach wiederholen
10101010
01010101
10101010
01010101
... // hier och mal

... // und eventuell alles auch noch mal in ein paar Runden druchlaufen

Natürlich wären da ein paar weniger gleichmäßige Bitmuster besser, damit es noch schwerer wird diese rauszurechnen. (je gleichmäßiger und/oder weniger überschrieben wird, desto einfacher wird es aus dem aktuellen Datenbrei, auf die ursprünglichen Daten zurückzurechnen)

[PierreB]

Meint ihr es würde reichen den Inhalt der Datei zu löschen, dann sinnlose Zeichenfolgen in die Datei zu kopieren und dann die Datei zu löschen (so macht es der Code von 3_of_8 nämlich derzeit) ? Die Datei wird ja dann nicht überschrieben, sondern lediglich im Inhalt ersetzt, oder ? :gruebel:

[3_of_8]

So ähnlich: Ich füre in etwa folgenden Code aus:

Delphi-Quellcode:

if fileexists(filename) then
begin
assignfile(f,filename);
reset(f);
size:=filesize(f);
rewrite(f);
for I:=1 to size do begin character:=chr(Random(255)+1); write(f,character); end;
closefile(f);
deletefile(filename);
end;

[PierreB]

Zitat:

So ähnlich: Ich füre in etwa folgenden Code aus:

Ich weiß,

ich hab den Quelltext eures Projekts von Chrissi91 bekommen.

[3_of_8]

Achso...Verstehe. Ohne mich zu fragen, tss... Als nächstes veröffentlicht er noch meine Klasse...Tsss...

Obwohl, die ist ja eh sch****, hat Matze mir gesagt, ich soll ja alles am besten vergessen. Sollte ich wirklich gaaanz schnell tun.

[himitsu]

Da meine Variante eh mal als OpenSource auslaufen wird, kann ich dat hier ja ruhig mal zeigen ^^

Alao aktuell mach ich dat so:

Delphi-Quellcode:

Type TDelFlags = Set of (cdfOverride1, cdfOverride3, cdfOverride7, cdfOverride15, cdfOverride31,
  cdfSplit, cdfSplitLarge, cdfFileTable);  // cdfFileTable do not use on Win NT file system.

Const cdfDefault  = [cdfOverride7 {, cdfFileTable}];
  cdfDefaultLarge = [cdfOverride1, cdfSplitLarge {, cdfFileTable}];



Function ClearAndDeleteFile(FileName: WideString; Flags: TDelFlags = cdfDefault): ByteBool;
  Var Handle: THandle;
    Len, LF: TLargeIntRec;
    DecSize, BufSize, i, i2: LongInt;
    Buffer: PLongWordArray;

  Begin
    Result := False;
    FileName := _ExpandFileName(FileName);
    Handle := CreateFileW(Pointer(FileName), amGenericWrite or amGenericRead,
      amFileShareRead or amFileShareWrite or amFileShareDelete, nil, cdOpenExisting, 0, 0);
    If Handle = InvalidHandle Then Exit;
    Buffer := nil;
    Try
      Len.Lo := GetFileSize(Handle, @Len.Hi);
      If Len.Org = InvalidFileSizeLI Then Exit;
      If (Len.Hi = 0) and (Len.Lo <= $00A00000) Then BufSize := Len.Lo shr 2 Else BufSize := $00280000;
      Buffer := Memory.Get((BufSize + 1) shl 2);
      Memory.Fill1(Buffer, BufSize shl 2, LongWord(_Random(-1)));
      If cdfOverride31 in Flags Then i := 31 Else If cdfOverride15 in Flags Then i := 15
      Else If cdfOverride7 in Flags Then i := 7 Else If cdfOverride1 in Flags Then i := 1 Else i := 3;
      For i := i downto 0 do Begin
        For i2 := BufSize - 1 downto 0 do Buffer^[i2] := Buffer^[i2] xor LongWord(_Random(-1));
        i2 := BufSize shl 2 - _Random(BufSize);
        LF.Org := Len.Org;
        SetFilePointer(Handle, 0, nil, mmFileBegin);
        While LF.Org >= i2 do Begin
          WriteDataNE(Handle, Buffer, i2, nil, nil);
          Dec(LF.Org, i2);
        End;
        WriteDataNE(Handle, Buffer, LongInt(LF.Lo), nil, nil);
        FlushFileBuffers(Handle);
      End;
      If (cdfSplit in Flags) or (cdfSplitLarge in Flags) Then Begin
        DecSize := GetClusterSize(_ExtractFileDrive(FileName), 512);
        LF.Org := Len.Org;
        SetFilePointer(Handle, LF.Lo, @LF.Hi, mmFileBegin);
        If cdfSplitLarge in Flags Then Begin
          i := DecSize;
          While LF.Org > i do Begin
            Dec(LF.Org, i);
            SetFilePointer(Handle, -i, nil, mmFileCurrent);
            SetEndOfFile(Handle);
            FlushFileBuffers(Handle);
            i := DecSize + LF.Org shr 10;
          End
        End Else While LF.Org > DecSize do Begin
          Dec(LF.Org, DecSize);
          SetFilePointer(Handle, -DecSize, nil, mmFileCurrent);
          SetEndOfFile(Handle);
          FlushFileBuffers(Handle);
        End;
      End;
      SetFilePointer(Handle, 0, nil, mmFileBegin);
      SetEndOfFile(Handle);
    Finally
      Memory.Free(Pointer(Buffer));
      CloseHandle(Handle);
    End;
    DeleteFileW(Pointer(FileName));
    If cdfFileTable in Flags Then Begin
      For i := 0 to 99 do Begin
        FileName := WideString('CF') + WideChar(i div 10 or $30) + WideChar(i mod 10 or $30) + WideString('.FNSClearDir');
        Handle := CreateFileW(Pointer(FileName), amGenericWrite,
          amFileShareRead or amFileShareWrite or amFileShareDelete, nil, cdCreateAlways, 0, 0);
        If Handle <> InvalidHandle Then CloseHandle(Handle);
      End;
      For i := 99 downto 0 do Begin
        FileName := WideString('CF') + WideChar(i div 10 or $30) + WideChar(i mod 10 or $30) + WideString('.FNSClearDir');
        DeleteFileW(Pointer(FileName));
      End;
    End;
    Result := True;
  End;

Das meiste dürfte ja selbsterklärend sein, von den Namen her.
- WriteDataNE entspricht dabei WriteFile (WinAPI incl. 'ner winzigen Fehlerbehandling)
- Memory geht direkt an den MemoryManager in etwa kann man das so sehn: Memory.Get=GetMem, ...

Ein Problem hab ich allerdings noch beim entfernen der Daten aus dem Verzeichnis.
Bei den älteren Dateisystemen (FAT...) konnte man den Eintrag dadurch entfernen, daß man die Tabelle überfüllt hat.
Leider führt NTFS 'ne Art LogBuch, oder wie man das nennen kann, wo ich bisher noch nicht weiß, wie ich da rannkomme, um den entsprechenden Eintrag entfernen zu können -.-''


Na ja, mal sehn ob jemand noch ein paar Tipps hat :angel2:

[Luckie]

Zu diesen Thema gibt es im Forum schon Lösungen. Einfach mal suchen.

[himitsu]

Wie man was aus'm NTFS rausbekommt?
Hab bereits gesucht und nichts passendes entdeckt.
Und nicht nur in der DP.

[Luckie]

Shredder.

[himitsu]

Diese Beiträge kenn ich schon alle und haben mir nicht geholfen.

Die Daten der Datei bekomm ich schon "weg", nur eben bei NTFS nicht den Verweis darauf, also das, was innerhalb des übergeordneten Verzeichnisses steckt.

Denn, wie gesagt, NTFS scheint 'ne Art Logbuch zu führen (Dateiumbenennungen, Dateilöschungen, und was es sonst noch gibt) und genau das bekomm ich nicht weg.

[Ultimator]

Hagen hat auch schonmal geschrieben, dass man mit den Methoden, die ihr bisher gerwähnt habt nur die Datei so löscht, wie sie gerade besteht. Aber die Datei kann ja auch mal größer gewesen sein als unmittelbar vor dem Löschvorgang, also liegen noch in irgendwelchen Sektoren auf der Platte Restinhalte der Originaldatei rum und warten darauf, gefunden zu werden.

[himitsu]

Jupp, und das bekommt man nur weg, indem man die leeren Sektoren und das ungenutzte Sektoenteil am Ende jeder Datei "sicher" löscht.
Außerdem müßte man noch jede vorhande Datei "sicher löschen" und danach den Dateiinhalt wieder herstelllen, damit auch hinter den vorhandenen Daten die Restmagnetisierung zerstört wird ...

[3_of_8]

WinAPI? Assembler?

[Ultimator]

Zitat:

Zitat von 3_of_8

WinAPI? Assembler?

Knapp die Absicht von himitsus Posting verfehlt :zwinker:
Es ist sozusagen ein Ding der Unmöglichkeit, Daten unwiederbringlich zu löschen (ohne Hammer :mrgreen:)

[3_of_8]

Aber man könnte doch die Festplatte von vorne bis hinten durchgehen und alle nicht verwendeten Sektoren überschreiben, oder?

[Ultimator]

Und was machst du mit den halbvollen Sektoren?
Außerdem sollen ja u.U. Datei"rückstände" anderer Dateien erhalten bleiben.Wenn du aber alles Andere löschst, sind die auch fort.

[3_of_8]

Na gut, ich gebs auf.

[himitsu]

Was mir gerade aufgefallen ist, das ich noch die Dateigröße beim Überschreiben zumindestens auf volle Sektoren aufrunden könnte, damit zumindestens die verwendeten Sektoren vollständig "leer" sind.

[Micha88]

Zitat:

Zitat von himitsu (Beitrag 405557)

Da meine Variante eh mal als OpenSource auslaufen wird, kann ich dat hier ja ruhig mal zeigen ^^

Alao aktuell mach ich dat so:

Delphi-Quellcode:

Type TDelFlags = Set of (cdfOverride1, cdfOverride3, cdfOverride7, cdfOverride15, cdfOverride31,
  cdfSplit, cdfSplitLarge, cdfFileTable);  // cdfFileTable do not use on Win NT file system.

Const cdfDefault  = [cdfOverride7 {, cdfFileTable}];
  cdfDefaultLarge = [cdfOverride1, cdfSplitLarge {, cdfFileTable}];



Function ClearAndDeleteFile(FileName: WideString; Flags: TDelFlags = cdfDefault): ByteBool;
  Var Handle: THandle;
    Len, LF: TLargeIntRec;
    DecSize, BufSize, i, i2: LongInt;
    Buffer: PLongWordArray;

  Begin
    Result := False;
    FileName := _ExpandFileName(FileName);
    Handle := CreateFileW(Pointer(FileName), amGenericWrite or amGenericRead,
      amFileShareRead or amFileShareWrite or amFileShareDelete, nil, cdOpenExisting, 0, 0);
    If Handle = InvalidHandle Then Exit;
    Buffer := nil;
    Try
      Len.Lo := GetFileSize(Handle, @Len.Hi);
      If Len.Org = InvalidFileSizeLI Then Exit;
      If (Len.Hi = 0) and (Len.Lo <= $00A00000) Then BufSize := Len.Lo shr 2 Else BufSize := $00280000;
      Buffer := Memory.Get((BufSize + 1) shl 2);
      Memory.Fill1(Buffer, BufSize shl 2, LongWord(_Random(-1)));
      If cdfOverride31 in Flags Then i := 31 Else If cdfOverride15 in Flags Then i := 15
      Else If cdfOverride7 in Flags Then i := 7 Else If cdfOverride1 in Flags Then i := 1 Else i := 3;
      For i := i downto 0 do Begin
        For i2 := BufSize - 1 downto 0 do Buffer^[i2] := Buffer^[i2] xor LongWord(_Random(-1));
        i2 := BufSize shl 2 - _Random(BufSize);
        LF.Org := Len.Org;
        SetFilePointer(Handle, 0, nil, mmFileBegin);
        While LF.Org >= i2 do Begin
          WriteDataNE(Handle, Buffer, i2, nil, nil);
          Dec(LF.Org, i2);
        End;
        WriteDataNE(Handle, Buffer, LongInt(LF.Lo), nil, nil);
        FlushFileBuffers(Handle);
      End;
      If (cdfSplit in Flags) or (cdfSplitLarge in Flags) Then Begin
        DecSize := GetClusterSize(_ExtractFileDrive(FileName), 512);
        LF.Org := Len.Org;
        SetFilePointer(Handle, LF.Lo, @LF.Hi, mmFileBegin);
        If cdfSplitLarge in Flags Then Begin
          i := DecSize;
          While LF.Org > i do Begin
            Dec(LF.Org, i);
            SetFilePointer(Handle, -i, nil, mmFileCurrent);
            SetEndOfFile(Handle);
            FlushFileBuffers(Handle);
            i := DecSize + LF.Org shr 10;
          End
        End Else While LF.Org > DecSize do Begin
          Dec(LF.Org, DecSize);
          SetFilePointer(Handle, -DecSize, nil, mmFileCurrent);
          SetEndOfFile(Handle);
          FlushFileBuffers(Handle);
        End;
      End;
      SetFilePointer(Handle, 0, nil, mmFileBegin);
      SetEndOfFile(Handle);
    Finally
      Memory.Free(Pointer(Buffer));
      CloseHandle(Handle);
    End;
    DeleteFileW(Pointer(FileName));
    If cdfFileTable in Flags Then Begin
      For i := 0 to 99 do Begin
        FileName := WideString('CF') + WideChar(i div 10 or $30) + WideChar(i mod 10 or $30) + WideString('.FNSClearDir');
        Handle := CreateFileW(Pointer(FileName), amGenericWrite,
          amFileShareRead or amFileShareWrite or amFileShareDelete, nil, cdCreateAlways, 0, 0);
        If Handle <> InvalidHandle Then CloseHandle(Handle);
      End;
      For i := 99 downto 0 do Begin
        FileName := WideString('CF') + WideChar(i div 10 or $30) + WideChar(i mod 10 or $30) + WideString('.FNSClearDir');
        DeleteFileW(Pointer(FileName));
      End;
    End;
    Result := True;
  End;

Das meiste dürfte ja selbsterklärend sein, von den Namen her.
- WriteDataNE entspricht dabei WriteFile (WinAPI incl. 'ner winzigen Fehlerbehandling)
- Memory geht direkt an den MemoryManager in etwa kann man das so sehn: Memory.Get=GetMem, ...

Ein Problem hab ich allerdings noch beim entfernen der Daten aus dem Verzeichnis.
Bei den älteren Dateisystemen (FAT...) konnte man den Eintrag dadurch entfernen, daß man die Tabelle überfüllt hat.
Leider führt NTFS 'ne Art LogBuch, oder wie man das nennen kann, wo ich bisher noch nicht weiß, wie ich da rannkomme, um den entsprechenden Eintrag entfernen zu können -.-''


Na ja, mal sehn ob jemand noch ein paar Tipps hat :angel2:

Kann mir mal wer sagen, welche USES ich dafür alles einbinden muss??

[Luckie]

Wenn du uns sagst, welche Funktionen nicht erkannt werden...

[Micha88]

Funktionen werden generell garkeine in dieser "Function" erkannt.
Sowie TLargeIntRec und PLongWordArray werden nicht erkannt.

[Matze]

Das wird irgendwas eigenes sein wie z.B. das folgende, vermute ich.

Delphi-Quellcode:

type
  TLongWordArray = array of LongWord;

var
  LongWordArray: TLongWordArray;

Delphi-Quellcode:

type
  TLargeIntRect: record
    Hi: LargeInt; // gibt's LargeInt?
    Lo: LargeInt;
    Ord: LargeInt;
  end;

Oder so ähnlich.

[Micha88]

Wieso wird das dann nicht mit in den Post gepackt?
Sehr nett ...

[Matze]

Weil es himi vermutlich darum ging, das Vorgehen des Algorithmusses zu zeigen.
Da sind die genauen Typen weniger wichtig.

Wie ich himi und seine ganzen Open-Source-Klassen kenne, möchte er dir das keinesfalls vorenthalten.
Wenn du ihn lieb fragst, verrät er dir sicher, was genau hinter den Typen steckt.

[himitsu]

Jupp, dahinter stecken teilweise einige eigene Definitionen/API-Implementationen.

Delphi-Quellcode:

PLongWordArray = ^TLongWordArray;
TLongWordArray = Array[0..0] of LongWord;

TLargeIntRec = Int64Rec

Memory.Fill1 = FillMemory usw.


Aber Aufgrund der aktuellen Datendichte und wegen dem exzessiven Logging von NTFS, reicht ein einfaches überschreiben.

Delphi-Quellcode:

var
  s: TFileStream;
  a: array[0..$FFFF] of Byte;
  i: Int64;
begin
  FillChar(a, SizeOf(a), 0);
  s := TFileStream.Create(TheFileName, fmOpenReadWrite);
  try
    i := (s.Size + $FFFF) and not Int64($FFFF);
    while i > 0 do begin
      s.Write(a, SizeOf(a));
      if i mod $03FFFFFF = 0 then
        FlushFileBuffers(s.Handle);
      Dec(i, SizeOf(a));
    end;
    FlushFileBuffers(s.Handle);
  finally
    s.Free;
  end;

PS: Wirklich sicher löschen geht aber nicht.
OK, die Daten in dieser Datei mögen weg sein, aber es können noch Kopien der Dateidaten vorhanden sein.
(Fragmentierung, Pagefile usw.)

Aber den Grund dafür hatte ich in irgendeinem dieser Sicher-Löschen-Threads schonmal ausführlich benannt.

[Assarbad]

Zitat:

Zitat von himitsu (Beitrag 1072067)

Aber Aufgrund der aktuellen Datendichte und wegen dem exzessiven Logging von NTFS, reicht ein einfaches überschreiben.

:shock: ???

Also daß einfaches Löschen reicht, wissen wir. Aber was hat das mit dem (USN-)Journal (welches im Gegensatz zum Tx-Log ab Vista standardmäßig nichtmal aktiv ist) oder der Datendichte zu tun? Das Tx-Log würde ich hingegen nichtmal als relevant ansehen, da diese Daten ja nur bis zum Commit wichtig sind.

Zitat:

Zitat von himitsu (Beitrag 1072067)

PS: Wirklich sicher löschen geht aber nicht.
OK, die Daten in dieser Datei mögen weg sein, aber es können noch Kopien der Dateidaten vorhanden sein.
(Fragmentierung, Pagefile usw.)

Fragmentierung ist kein Argument. Es gibt IOCTLs die man ans Dateisystem schicken kann um entweder selektiv die "cluster tips" (Cluster lesen, berechnen wieviel genullt werden muß, schreiben) zu überschreiben oder eben anderweitig die Fragmente einer Datei und die entsprechenden Einträge in der MFT/FAT zu überschreiben.

Pagefile ist hingegen durchaus ein gutes Argument, dürfte aber praktisch kaum Einfluß haben. Fragmente hingegen werden ja nicht nachträglich angelegt ... hier könnte höchstens eine Defragmentierung das Problem erzeugen indem die Dateidaten in als leer registrierten Clustern noch existieren. Da kann man wiederum mit dem Parsen der MFT Bitmap und Löschen entsprechender Cluster Abhilfe schaffen.

[himitsu]

Zitat:

Delphi-Quellcode:

For i := 99 downto 0 do Begin
  FileName := WideString('CF') + WideChar(i div 10 or $30) + WideChar(i mod 10 or $30) + WideString('.FNSClearDir');
  DeleteFileW(Pointer(FileName));
End;

Die damalige Idee hinter diese, Teil lag darin, daß man Windows dazu zwingt den alten Datei-Eintrag in der Verzeichnisstruktur zu überschreiben.
Was jetzt aber nicht mehr viel bringt und eher nur die Logs auffüllt.


Nja, im Grunde müßte man auch noch alle leeren Cluster und idealer Weise auch noch die Anteile der ungenutzen Cluster hinter den sonstigen Dateien, sowie die ungenutzen Clusterteile innerhalb von SparseFiles und komprimierten Dateien (via NTFS-Compression) auch noch löschen, um wirklich möglichst sicher gehn zu können, daß von der Datei nichts mehr vorhanden ist.

Das meine ich damit. Es kann ja sein, daß z.B. durch's Defragmentieren, bei Speichern/Verändern der Datei oder beim Ansehn der Datei (MS Office z.B. legt sich gern 'ne Arbeitskopie an) irgendwo noch Daten/Datenfragmente in anderen Clustern existieren

[Assarbad]

Zitat:

Zitat von himitsu (Beitrag 1072145)

Die damalige Idee hinter diese, Teil lag darin, daß man Windows dazu zwingt den alten Datei-Eintrag in der Verzeichnisstruktur zu überschreiben.
Was jetzt aber nicht mehr viel bringt und eher nur die Logs auffüllt.

Dann benennt man die Datei wohl lieber so um, daß die maximale Anzahl Zeichen für einen Dateinamen ausgefüllt wird ;) ... dann kann man sie immer noch löschen.

Zitat:

Zitat von himitsu (Beitrag 1072145)

Nja, im Grunde müßte man auch noch alle leeren Cluster und idealer Weise auch noch die Anteile der ungenutzen Cluster hinter den sonstigen Dateien, sowie die ungenutzen Clusterteile innerhalb von SparseFiles und komprimierten Dateien (via NTFS-Compression) auch noch löschen, um wirklich möglichst sicher gehn zu können, daß von der Datei nichts mehr vorhanden ist.

Eraser bringt das und ist FOSS ;)

Zitat:

Zitat von himitsu (Beitrag 1072145)

Das meine ich damit. Es kann ja sein, daß z.B. durch's Defragmentieren, bei Speichern/Verändern der Datei oder beim Ansehn der Datei (MS Office z.B. legt sich gern 'ne Arbeitskopie an) irgendwo noch Daten/Datenfragmente in anderen Clustern existieren

Schon klar.