Advanced Backup Forum
Sicherungsarchiv wird sehr groß Forum
Bei der Sicherung eines Windows Server 2012 R2 wird das
Sicherungsarchiv ungewöhnlich groß. Laut Windows Explorer, sind 418 von 599 GB
frei, bedeutet es wären 181 GB zu sichern. Die gesicherten Archive werden
allerdings um die 500 GB groß. Das Sicherungsschema ist inkrementell mit 2
Vollsicherungen, 6 Teilsicherungen. Sicherungen nach Ablauf von X (30) Tagen
löschen. Das Flag „Sicherungsschema auf Vollsicherung zurücksetzen…“ ist
gesetzt auf „…jeden Montag“. Die Flags „Bei Speicherplatzmangel….“ Und „Alte
Teilsicherungen…“ sind ebenfalls gesetzt. Es handelt sich um einen Server der
unter Hyper-V virtualisiert erstellt wurde, mit einer virtuellen Festplatte. Er
wird als Terminalserver von 4-5 Usern
genutzt. Eine weitere Hyper-V Maschine läuft auf demselben Host und ist
ein DC, die Sicherung hier läuft normal: zu sichern wären 17 GB (126 – 109 GB),
das (Voll-) Archiv wird um die 10 GB groß. Wo könnte das Problem des übergroßen
(Voll-) Archivs liegen?
Wenn noch weitere Infos benötigt werden, bitte melden.
der naheliegendste Grund, für das beschriebene Verhalten bei der Vollsicherung Ihrer Hyper-V Maschine, ist ein
- unbekanntes,
- verschlüsseltes oder
- falsch erkanntes Dateisystem.
- verschlüsselt,
- der Zugriff auf die ClusterMap verweigert, oder
- ist das Dateisystem inkompatibel (bspw. ReFS)
dann wird ein RAW-Backup erstellt, wobei alle Sektoren gesichert werden. Dies führt zu einem Voll-Backup von 500 GB.
Lösungsansätze:
- Stellen Sie sicher, das Sie ein kompatibles Dateisystem verwenden: NTFS, FAT32, exFAT
- Die Software sollte durch einen Anti-Virus nicht am Auslesen der Clustermap gehindert werden: Ausführen unter System + Whitelisting
- Welches Dateisystem wird verwendet? Welche Version? (CMD fsutil fsinfo ntfsinfo C: )
Mit freundlichen Grüßen,
Evorim Support
also die fsinfo besagt:
NTFS-Volumeseriennummer 0x2a3c0ef13c0eb839
NTFS-Version : 3.1
LFS-Version : 2.0
Anzahl der Sektoren : 0x000000004aef77ff
Gesamtzahl Cluster : 0x00000000095deeff
Freie Cluster : 0x000000000688c36f
Insgesamt reserviert : 0x0000000000000f80
Bytes pro Sektor : 512
Bytes pro physischem Sektor : 4096
Bytes pro Cluster : 4096
Bytes pro Dateidatensatzsegment : 1024
Cluster pro Dateidatensatzsegment : 0
Gültige MFT-Datenlänge : 0x0000000026680000
MFT-Start-LCN : 0x00000000000c0000
MFT2-Start-LCN : 0x0000000000000002
MFT-Zonenstart : 0x0000000000520ce0
MFT-Zonenende : 0x0000000000524a80
Ressourcen-Manager-Bezeichner: 1E0E185D-883C-11E3-9C8F-D6BFA6A3C939
Beim letzten Backup hat ABM für die 599 GB Partition 614 GB "komprimiert" gesichert. Bei Beobachten des Nachrichtenfensters zu Beginn des BKP-Jobs werden auch eigentlich korrekterweise 180 zu sichernde GB angezeigt. Ist dieser erste Job fertig, zählt der Job danach weiter hoch.
Bei der Antivirensoftware habe ich noch den Installationspfad von ABM als Ausnahem hinzugefügt.
Der Backup Service läuft unter "lokales System".
vom beschriebenen Verhalten her, scheint das interne Parsen der Clustermap im ABM fehlzuschlagen. Es wird zunächst die Größe korrekt ausgelesen, dann aber flasch umgesetzt.
Ich werde eine spezielle ABM Version vorbereiten und Ihnen bereitstellen, in welcher das Verhalten geloggt wird.
Mit freundlichen Grüßen,
Evorim Support
wie ist denn der Status bzgl. des letzten Posts?
Mit freundlichem Gruß
Markus Stahl
die spezielle Version mit dem erweiterten Loggin ist fast fertig. Wird am Montag bereitgestellt.
Mit freundlichen Grüßen,
Evorim Support
die Beta Version ist fertig und wurde bereitgestellt.
Nach der Installation und dem Durchführen Ihrer Festplatten-Datensicherung, befindet sich die Datei bdi.log im Installationsordner. Senden Sie bitte diese Datei per E-Mail an den Support.
Mit freundlichen Grüßen,
Evorim Support
konnte die Beta erst heute einspielen, BKP-JOB startet um 21:30 - ich werde das LOG dann morgem schicken.
Viele Grüße
Markus Stahl
