Time-Machine-Backup/-Sparsebundle reparieren

Aus verschiedenen Gründen kann es sein, dass Time Machine die Überprüfung eines Sparsebundle-Backups nicht erfolgreich abschließt. In den meisten Fällen hat das Dateisystem des Sparsebundle-Images ein Problem. Mit einigen wenigen – aber zeitaufwendigen – Schritten ist nachfolgend erklärt, wie man sein Time-Machine-Backup/-Sparsebundle reparieren kann, nachdem Time Machine es als nicht mehr zuverlässig erkannt hat.

Eine solche Meldung von Time Machine sieht folgendermaßen aus:

Time Machine hat die Überprüfung deines Backups auf „KittNAS.local“ abgeschlossen. Um die Zuverlässigkeit zu verbessern, muss Time Machine ein neues Backup für dich erstellen.

Die Meldung als Text:

Time Machine hat die Überprüfung deines Backups auf „KittNAS.local“ abgeschlossen. Um die Zuverlässigkeit zu verbessern, muss Time Machine ein neues Backup für dich erstellen.

Klicke auf „Neues Backup starten“, um ein neues Backup zu erstellen. Dabei wird dein bestehender Backup-Verlauf gelöscht. Dies kann mehrere Stunden dauern.

Klicke auf „Backup später erstellen“, um morgen an das Backup erinnert zu werden. Währenddessen erstellt Time Machine keine Backups

Im ersten Schritt sollten die automatischen Backups in Time Machine deaktiviert werden. Das geht in den Systemeinstellungen unter Time Machine > Automatische Datensicherung.

Dateisystem einhängen

Danach muss das Time-Machine-Volume eingehängt werden, sodass es unter /Volumes sichtbar ist. Das kann in der Regel über das Netzwerk im Finder vorgenommen werden.

Dann muss man sich im Terminal mit dem Programm chflags Schreibzugriff auf das Sparsebundle-Image geben, damit man es beschreiben kann. Dieser Befehl sieht folgendermaßen aus:

chflags -R nouchg /Volumes/{Netzlaufwerk}/{name}.sparsebundle

Dabei müssen {Netzlaufwerk} und {name} jeweils durch den Namen bzw. durch den Pfad des Netzlaufwerks bis zum Sparsebundle-Image und den Namen des Sparsebundle-Images selbst ersetzt werden.

Sind dort im Pfad Leerzeichen vorhanden, müssen diese mit einem vorangestellten \ markiert werden. Beispielhaft sieht ein Pfad folgendermaßen aus:

/Volumes/timemachine/MacBook\ Pro\ Backup.sparsebundle

Dateisystem überprüfen

Dann sollte als erstes das Dateisystem überprüft werden. Das geht mit dem Programm hdiutil, der genaue Befehl sieht folgendermaßen aus:

hdiutil attach -nomount -noverify -noautofsck /Volumes/{Netzlaufwerk}/{name}.sparsebundle

Auch hier muss wieder der Pfad zum Sparsebundle-Image angepasst werden.

Es erscheint sofort eine Ausgabe, die folgendermaßen aussieht:

/dev/disk3 GUID_partition_scheme /dev/disk3s1 EFI /dev/disk3s2 Apple_HFS

Der eigentliche Test wurde dann bereits durchgeführt und ist unter /var/log/fsck_hfs.log zu finden. In meinem Fall sieht die Ausgabe dort folgendermaßen aus:

/dev/rdisk3s2: fsck_hfs started at Fri Jul 5 21:42:42 2019 /dev/rdisk3s2: /dev/rdisk3s2: ** /dev/rdisk3s2 (NO WRITE) /dev/rdisk3s2: Executing fsck_hfs (version hfs-407.200.4). QUICKCHECK ONLY; FILESYSTEM DIRTY /dev/rdisk3s2: fsck_hfs completed at Fri Jul 5 21:42:42 2019

Oder:

/dev/rdisk3s2: fsck_hfs started at Fri Jul 5 21:22:45 2019 /dev/rdisk3s2: /dev/rdisk3s2: ** /dev/rdisk3s2 (NO WRITE) /dev/rdisk3s2: Executing fsck_hfs (version hfs-407.200.4). QUICKCHECK ONLY; FILESYSTEM CLEAN /dev/rdisk3s2: fsck_hfs completed at Fri Jul 5 21:22:45 2019

Steht dort FILESYSTEM DIRTY, dann muss das Dateisystem repariert werden (siehe erstes Beispiel). Steht dort FILESYSTEM CLEAN, dann muss das Dateisystem nicht repariert werden und die nachfolgenden Reparaturen können übersprungen werden.

Dateisystem reparieren

Für die Reparatur eignet sich das Programm fsck_hfs. Der Befehl sieht dabei folgendermaßen aus:

fsck_hfs -drfy /dev/disk3s2

Dabei haben die Parameter drfy folgende Bedeutung:

  • d: Debug-Modus
  • r: Catalog Tree neu erstellen
  • f: Änderungen erzwingen
  • y: Jeden Dialog automatisch mit „ja“ beantworten

Den Pfad /dev/disk3s2 kann man der Ausgabe von hdiutil oben entnehmen. Hier muss der Pfad verwendet werden, bei dem rechts dann Apple_HFS steht.

Der Reparaturvorgang kann einige Zeit in Anspruch nehmen. Also bitte warten, bis er vollständig durchgelaufen ist. Das erkennt man im Terminal daran, dass der Cursor rechts von einem $ steht, bei mir beispielsweise:

MacBook:~ matze$

Die Ausgabe kann dabei folgendermaßen aussehen:

journal_replay(/dev/disk3s2) returned 0 ** /dev/rdisk3s2 Using cacheBlockSize=32K cacheTotalBlock=65536 cacheSize=2097152K. Executing fsck_hfs (version hfs-407.200.4). ** Checking Journaled HFS Plus volume. ** Detected a case-sensitive volume. The volume name is Time Machine-Backups ** Checking extents overflow file. ** Checking catalog file. ** Rebuilding catalog B-tree. hfs_UNswap_BTNode: invalid node height (1) ** Rechecking volume. ** Checking Journaled HFS Plus volume. ** Detected a case-sensitive volume. The volume name is Time Machine-Backups ** Checking extents overflow file. ** Checking catalog file. Incorrect number of thread records (4, 23290) CheckCatalogBTree: dirCount = 483781, dirThread = 483784 ** Checking multi-linked files. Incorrect number of file hard links Incorrect linkCount for inode=1830530 (expected=2, found=1) ** Checking catalog hierarchy. Invalid directory item count (It should be 598264 instead of 598265) Invalid directory item count (It should be 109502 instead of 109504) Invalid volume directory count (It should be 483690 instead of 483780) Invalid volume file count (It should be 4061850 instead of 4062088) Incorrect folder count in a directory (id = 18) (It should be 0 instead of 1) Incorrect folder count in a directory (id = 19) (It should be 109502 instead of 109504) Incorrect folder count in a directory (id = 4418368) (It should be 41 instead of 0) Incorrect folder count in a directory (id = 4418981) (It should be 41 instead of 0) ** Checking extended attributes file. Incorrect number of extended attributes (It should be 2818345 instead of 2818894) Incorrect number of Access Control Lists (It should be 2818277 instead of 2818826) Unused node is not erased (node = 286408) Unused node is not erased (node = 286409) Unused node is not erased (node = 286410) Unused node is not erased (node = 286412) Unused node is not erased (node = 286413) ** Checking multi-linked directories. privdir_valence=109504, calc_dirlinks=309509, calc_dirinode=109502 Incorrect number of directory hard links Error getting first link ID for inode=4419585 ** Checking volume bitmap. Volume bitmap needs repair for under-allocation ** Checking volume information. Invalid volume free block count (It should be 17692608 instead of 8239466) invalid VHB nextCatalogID Volume header needs minor repair (2, 0) Verify Status: VIStat = 0xa000, ABTStat = 0x0064 EBTStat = 0x0000 CBTStat = 0x0800 CatStat = 0x00004003 ** Repairing volume. Indirect node 1834048 needs link count adjustment (It should be 2 instead of 1) Indirect node 1834275 needs link count adjustment (It should be 2 instead of 1) Error getting first link ID for inode = 4421033 (result=32) Invalid first link in hard link chain (id = 4421033) (It should be 7230411 instead of 0) Error getting first link ID for inode = 4421840 (result=32) Invalid first link in hard link chain (id = 4421840) (It should be 7230419 instead of 0) Error getting first link ID for inode = 4422043 (result=32) Invalid first link in hard link chain (id = 4422043) (It should be 7230421 instead of 0) Error getting first link ID for inode = 4422691 (result=32) Invalid first link in hard link chain (id = 4422691) (It should be 7230427 instead of 0) Error getting first link ID for inode = 4422911 (result=32) Invalid first link in hard link chain (id = 4422911) (It should be 7230429 instead of 0) Orphaned directory hard link (id = 7230385) Orphaned directory hard link (id = 7230391) UpdFolderCount: second SearchBTreeRecord failed (thread.parentID = 19, result = 32), just returning without complaint UpdFolderCount: second SearchBTreeRecord failed (thread.parentID = 19, result = 32), just returning without complaint DoMinorRepair: Repair for type=542 failed (err=2). ** The volume Time Machine-Backups could not be repaired. volume type is pure HFS+ primary MDB is at block 0 0x00 alternate MDB is at block 0 0x00 primary VHB is at block 2 0x02 alternate VHB is at block 856014766 0x3305bfae sector size = 512 0x200 VolumeObject flags = 0x07 total sectors for volume = 856014768 0x3305bfb0 total sectors for embedded volume = 0 0x00 CheckHFS returned 2, fsmodified = 1

In meinem Fall hat die Reparatur nicht geklappt, was man an der Zeile 90 gut erkennt:

The volume Time Machine-Backups could not be repaired.

Es gibt jedoch noch einen weiteren Befehl, der ebenfalls eine Weile benötigt, den man dann ausprobieren kann:

fsck_hfs -p /dev/disk3s2

Damit werden eigentlich nur normale Inkonsistenzen behoben, aber das kann manchmal wahre Wunder bewirken.

In meinem Fall war die Ausgabe dann die folgende:

Executing fsck_hfs (version hfs-407.200.4). ** Checking Journaled HFS Plus volume. ** Detected a case-sensitive volume. The volume name is Time Machine-Backups ** Checking extents overflow file. ** Checking catalog file. Incorrect number of thread records (4, 23290) ** Checking multi-linked files. ** Checking catalog hierarchy. Invalid directory item count (It should be 598264 instead of 598265) Invalid directory item count (It should be 109502 instead of 109504) Invalid volume directory count (It should be 483690 instead of 483780) Invalid volume file count (It should be 4061848 instead of 4062086) Incorrect folder count in a directory (id = 4416049) (It should be 11 instead of 13) Incorrect folder count in a directory (id = 4418368) (It should be 41 instead of 0) Incorrect folder count in a directory (id = 4418981) (It should be 41 instead of 0) ** Checking extended attributes file. Incorrect number of extended attributes (It should be 2818355 instead of 2818894) Incorrect number of Access Control Lists (It should be 2818277 instead of 2818826) Invalid leaf record count (It should be 10379778 instead of 10379768) ** Checking multi-linked directories. ** Checking volume bitmap. Volume bitmap needs repair for under-allocation ** Checking volume information. Invalid volume free block count (It should be 17692610 instead of 8239466) Volume header needs minor repair (2, 0) ** Repairing volume. ** Rechecking volume. ** Checking Journaled HFS Plus volume. ** Detected a case-sensitive volume. The volume name is Time Machine-Backups ** Checking extents overflow file. ** Checking catalog file. Missing thread record (id = 4418368) Missing thread record (id = 4418981) Incorrect number of thread records (4, 23290) ** Checking multi-linked files. ** Checking catalog hierarchy. Invalid volume directory count (It should be 483690 instead of 483780) Invalid volume file count (It should be 4061848 instead of 4062086) Incorrect folder count in a directory (id = 4418368) (It should be 41 instead of 0) Incorrect folder count in a directory (id = 4418981) (It should be 41 instead of 0) ** Checking extended attributes file. ** Checking multi-linked directories. ** Checking volume bitmap. ** Checking volume information. ** Repairing volume. Missing directory record (id = 4418981) Missing directory record (id = 4418368) ** Look for missing items in lost+found directory. ** Rechecking volume. ** Checking Journaled HFS Plus volume. ** Detected a case-sensitive volume. The volume name is Time Machine-Backups ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. Incorrect folder count in a directory (id = 2) (It should be 5 instead of 4) Incorrect folder count in a directory (id = 11714635) (It should be 2 instead of 0) ** Checking extended attributes file. ** Checking multi-linked directories. ** Checking volume bitmap. ** Checking volume information. Invalid volume file count (It should be 4062086 instead of 4061848) Invalid volume directory count (It should be 483783 instead of 483693) ** Repairing volume. ** Rechecking volume. ** Checking Journaled HFS Plus volume. ** Detected a case-sensitive volume. The volume name is Time Machine-Backups ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking multi-linked directories. ** Checking volume bitmap. ** Checking volume information. ** The volume Time Machine-Backups was repaired successfully.

Wie am Ende zu sehen ist, war hier die Reparatur erfolgreich. Wenn nicht, kann man nochmal den ersten Reparaturbefehl nutzen:

fsck_hfs -drfy /dev/disk3s2

Danach sollte das Dateisystem wirklich repariert sein. Falls nicht, ist es in einer Art und Weise beschädigt, dass eine Reparatur nicht mehr möglich ist und ein neues Backup erstellt werden muss. Am besten entfernt man hier das Sparsebundle-Image manuell, sodass Time Machine wirklich ein komplett sauberes neu anlegt.

In meinem Fall sah die Ausgabe dann folgendermaßen aus:

journal_replay(/dev/disk3s2) returned 0 ** /dev/rdisk3s2 Using cacheBlockSize=32K cacheTotalBlock=65536 cacheSize=2097152K. Executing fsck_hfs (version hfs-407.200.4). ** Checking Journaled HFS Plus volume. ** Detected a case-sensitive volume. The volume name is Time Machine-Backups ** Checking extents overflow file. ** Checking catalog file. ** Rebuilding catalog B-tree. hfs_UNswap_BTNode: invalid node height (1) ** Rechecking volume. ** Checking Journaled HFS Plus volume. ** Detected a case-sensitive volume. The volume name is Time Machine-Backups ** Checking extents overflow file. ** Checking catalog file. ** Checking multi-linked files. ** Checking catalog hierarchy. ** Checking extended attributes file. ** Checking multi-linked directories. privdir_valence=109502, calc_dirlinks=309507, calc_dirinode=109502 ** Checking volume bitmap. ** Checking volume information. ** The volume Time Machine-Backups was repaired successfully. CheckHFS returned 0, fsmodified = 1

Überprüfungsstatus zurücksetzen

Zu guter Letzt muss im Time-Machine-Backup selbst der Status der letzten Überprüfung zurückgesetzt werden. Andernfalls ist Time Machine nach wie vor der Auffassung, dass ein neues Backup angelegt werden muss, auch wenn alle Fehler korrigiert wurden.

Dazu muss man das Sparsebundle-Image öffnen. Je nach Größe kann das im Finder einige Minuten dauern, in denen es keine Rückmeldung gibt. Daher empfehle ich, sofern möglich, das Image direkt auf dem jeweiligen Netzlaufwerk (beispielsweise NAS) zu öffnen. Dort findet man direkt auf der ersten Ebene die Datei com.apple.TimeMachine.MachineID.plist. Deren Inhalt müsste etwa folgendermaßen aussehen:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>RecoveryBackupDeclinedDate</key> <date>2019-07-05T19:40:26Z</date> <key>VerificationDate</key> <date>2019-07-05T19:39:50Z</date> <key>VerificationExtendedSkip</key> <false/> <key>VerificationState</key> <integer>2</integer> <key>com.apple.backupd.HostUUID</key> <string>C361AD5E-10AE-533B-9E58-BA73E2A5D840</string> <key>com.apple.backupd.ModelID</key> <string>MacBookPro14,3</string> </dict> </plist>

Hier muss zuerst der VerificationState geändert werden, dessen Wert in Zeile 12 mit 2 festgelegt ist. Dieser Wert muss auf 0 geändert werden.

Außerdem müssen die Zeilen 5 und 6 entfernt werden, die angeben, wann das Backup als nicht erfolgreich überprüft eingestuft wurde.

Abgeändert sieht die Datei bei mir dann folgendermaßen aus:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>VerificationDate</key> <date>2019-07-05T19:39:50Z</date> <key>VerificationExtendedSkip</key> <false/> <key>VerificationState</key> <integer>0</integer> <key>com.apple.backupd.HostUUID</key> <string>C361AD5E-10AE-533B-9E58-BA73E2A5D840</string> <key>com.apple.backupd.ModelID</key> <string>MacBookPro14,3</string> </dict> </plist>

Dateisystem aushängen

Um das Sparsebundle-Image nun wieder als Backup-Laufwerk verwenden zu können, muss es erst am lokalen System ausgehängt werden. Das geht mit folgendem Befehl:

hdiutil detach /dev/disk3s2

Backup manuell ausführen und automatische Datensicherung wieder aktivieren

Nun ist das Time-Machine-Sparsebundle wieder vollständig einsatzbereit und kann genutzt werden. Es bietet sich an, das Backup nun einmal manuell zu starten. Lief das erfolgreich durch, kann man auch die automatische Datensicherung wieder aktivieren.

Das erste Backup dauert für gewöhnlich wesentlich länger als normal, da das gesamte Backup erneut geprüft wird. Außerdem kann es wesentlich größer sein (bei mir 80 GB statt der normalen ~800 MB).

22 Kommentare zu “Time-Machine-Backup/-Sparsebundle reparieren

  1. Vielen Dank für die wirklich hilfreiche und verständliche Erklärung. Wie hier in der Erklärung angeführt, Reparaturversuch Nr. 2 (fsck_hfs -p /dev/disk3s2) hat bei mir dann funktioniert und das Time Machine Backup läuft wieder! Danke.

    1. Abgesehen davon, dass sich das Format bei meinem bestehenden Backup nicht geändert hat, gehe ich nicht davon aus, dass sich die grundlegende Funktionalität von Time Machine (und um die geht es hier) grundlegend geändert hat.

  2. Vielen Dank and den Erzeuger, hat auch bei mir (alter Mac Mini macOS 10.14.6 als TM-Server, Macbook auf 10.15.5 als TM-Client) prima funktioniert und ich gerettet.

    Bei aktuellem OS: einfach im obigen Rezept .sparsebundle durch .backupbundle ersetzen. Wer die .plist-Datei nicht findet, man muss sich zuerst mit Rechtsklick auf „Paketinhalt anzeigen“ in das Bundle hereinarbeiten.

    Als Ergänzung würde ich empfehlen, vom TM-Client aus eine manuelle Backup-Überprüfung anzustoßen, bevor man sich wieder blind auf die Integrität der Backups verlässt. Schließlich überlistet man ja durch die Änderung des Integer-Werts zurück auf 0 die TM und behauptet, die Integrität sei (wieder) gewährleistet, was aber de facto durch das Festplattendienstprogramm wie hier verwendet nicht garantiert werden kann.

  3. Ich konnte der Anleitung als Laie gut folgen – Dateisystem war clean. Hänge jetzt aber im letzten Schritt (*hdiutil detach /dev/disk3s2*) und wollte mal nachfragen, bevor ich etwas kaputt mache:

    Bei mir sieht es jetzt unter hdiutil attach -nomount -noverify -noautofsck /Volumes/{Netzlaufwerk}/{name}.backupbundle so aus:

    /dev/disk2 GUID_partition_scheme
    /dev/disk2s1 EFI
    /dev/disk2s2 Apple_HFS /Volumes/Time Machine-Backups

    Muss ich dann eventuell einfach dort „*hdiutil detach /dev/disk2s“ ausführen, weile s bei mir kein „disk3s2“ gibt? Würde mich über einen Hinweis freuen.

      1. Ich war offenbar voreilig: Leider hat es doch nicht geklappt.

        Das Volume wurde bei mir zwar als „clean“ gemeldet, der Versuch des manuell angestoßenen Backups ist aber mehrfach abgebrochen. Er startet zwar normal, überträgt offenbar auch Daten, bricht dann aber immer ab.

        Weitere Beobachtungen:

        Über Time Machine kann ich zwar auf die so erstellen Backups zugreifen. Die ältere sind dagegen zwar sichtbar, lassen sich aber nicht anwählen.

        Im fsck_hfs.log wird ein „No Write“ gemeldet.

        „/dev/rdisk2s2: fsck_hfs started at Tue Aug 18 09:47:15 2020
        /dev/rdisk2s2: /dev/rdisk2s2: ** /dev/rdisk2s2 (NO WRITE)
        /dev/rdisk2s2: Executing fsck_hfs (version hfs-522.100.5).
        QUICKCHECK ONLY; FILESYSTEM CLEAN
        /dev/rdisk2s2: fsck_hfs completed at Tue Aug 18 09:47:15 2020“

        Beim Versuch, im Ordner, der auch das Backupbuntle enthält, hdiutil attach -nomount -noverify -noautofsck laufen zu lassen, erscheint jetzt der Hinweis „attach failed – Die Ressource ist zeitweilig nicht verfügbar“

        Dafür erscheint jetzt unter Volumes noch zusätzlich „Time Machine-Backups“ (bin mir nicht sicher, ob das vorher auch schon da war).

        1. Bricht das Backup denn mit einer Fehlermeldung ab? Kann es vielleicht sein, dass kurzzeitig die Verbindung zum Backup verloren geht, sofern sie über das Netzwerk angeschlossen ist?

          Hast du einmal deinen Mac neu gestartet, um sicherzugehen, dass kein anderer Prozess noch auf das Backup zugreift?

          1. Ich habe noch mal nachgesehen (und neu gestartet, obwohl ich das vorher mW auch schon mal gemacht hatte): Das manuelle Backup lief nun durch. Beim „VerificationDate“ in com.apple.TimeMachine.MachineID.plist erschien auch das aktuelle Datum.

            Wenn man Time Machine öffnete, dauerte das Laden der früheren Versionen zwar lange, aber sie ließen sich auch ansteuern.

            In der Systemeinstellung Time Machine wurde die Platte jedoch weiter mit rotem „i“ markiert und nur das Datum des letzten erfolgreichen Backups vor dem Auftreten des Fehlers angezeigt.

            Aber, o Wunder, nachdem Aktivieren des automatischen Backups gab es im zweiten Versuch dann auch eine problemlosen Durch und die Warnung verschwand auch in der Systemeinstellung.

  4. Hallo ,
    ich habe auch ein Problem mit meinen TM Backup. Mit einem Mal will er ein neues *.backupbundle anlegen und lässt das bestehende links liegen (Habe MacOS Catalina)…
    Bei „hdiutil attach“ kommt:
    „hdiutil: attach failed – Image nicht erkannt“
    Ich habe dem Terminal bereits Festplattenvollzugriff gewährt und die Befehle mit sudo ausgeführt.

    Ich wäre über jeden Tip dankbar. Gruß Jan

        1. Hab Dank für die schnelle Antwort 🙂 aber ich glaube ich bekomme es einfach nicht mehr hin … nun sagt er mir: already specified

          Rolands-iMac:time machine ordner root# hdiutil attach -nomount -noverify -noautofsck /Volumes/time\ machine\ ordner /Rolands\ mac.purgeable.sparebundle
          hdiutil: attach: extra image argument „/Rolands mac.purgeable.sparebundle“ – „/Volumes/time machine ordner“ already specified
          Usage: hdiutil attach [options]
          hdiutil attach -help

  5. Hallo, ich habe auch eine womöglich, defektes Backup. Und hänge beim einhängen fest.

    Rolands-iMac:time machine ordner root# hdiutil attach -nomount -readwrite -noverify -noautofsck Rolands\ Mac.purgeable.sparsebundle
    hdiutil: attach failed – Es existiert keine Datei und kein Ordner dieser Art

    … doch sie existiert!

    Kann jemand meinen Fehler sehen, den ich mache?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.