Resolving Siemens SINUMERIK 840D Ghost Backup Error 657

Problem Overview

When running a Symantec Ghost 8.2 backup of a Siemens SINUMERIK 840D operator panel/PCU 50.3 or PCU 70.1 system, the dump operation terminates between 0% and 100% with a Ghost error log entry that matches the following pattern:

********************** Backup/Restore Log File **********************
Error: Error while running Ghost!
Parameter:
-batch -z2 -sure -fis -clone,mode=dump,src=1,dst=O:\del2.gho
Ghost Error File:
Date : Sun Dec 16 16:36:32 2007
Error Number: (657)
Message: Available space is less than the estimated image file size.
Version: 8.2.0.1117 (Aug 26 2004, Build=1117)
OS Version: Professional (Build 3790)
Command line arguments: -script=d:\images\\para.dat -afile=d:\images\\Ghosterr.txt
Active Switches :
AutoName

The failure is reported in the HMI's Ghosterr.txt file located on the boot media (typically D:\images\). Ghost exits before completing the dump, leaving an incomplete or zero-byte .gho file on the destination share O:\. Most service engineers encounter the abort at 50% completion, immediately after Ghost has processed the operating-system sectors and is moving into the HMI application payload.

Environment Identification

Confirm the operating environment of the failing backup before changing any script switch:

For 840D systems delivered with software releases prior to SW 4.4 SP2, Ghost 8.2 is the standard service tool bundled on the recovery media. Refer to the SINUMERIK 840D sl Service HMI manual on the Siemens Industry Online Support portal (article ID 48832605 in the SINUMERIK archive) for the canonical backup flow that Ghost 8.2 plugs into.

Root Cause Analysis

Ghost 8.2 error 657 is raised by the size estimation module of the dump engine. Ghost walks the source volume, sums the used clusters, applies the requested compression factor, and compares the result against the free space on the destination volume. If the projected final .gho exceeds the destination free bytes, the abort is triggered.

Three root-cause families apply to the 840D scenario:

1. Destination share is genuinely out of space. The most common cause. The network share O: is mounted from a Windows file server, a NAS, or a peer PCU. Previous .gho files, NC archives, or unrelated data have filled it. The AutoName switch writes a sequence of del2.gho, del3.gho, etc., so stale generations often accumulate on the share and are never cleaned up.
2. Compression ratio is lower than Ghost's pre-dump estimate. The HMI partition contains installed binaries, registry hives (SOFTWARE, SYSTEM, NTUSER.DAT), service packs, and machine data archives that are already compressed or random and therefore not compressible below approximately 30%. With -z2 Ghost assumes a higher compression ratio than the real HMI image achieves. The estimate of the required .gho size is therefore optimistic, and the destination fills during the dump.
3. Source partition has grown since the last successful image. The HMI's C: partition grows when trace logs, NC backup archives, or service packs accumulate. If the previous successful image was taken when C: was 4.2 GB and is now 5.1 GB, the same destination share may no longer be large enough even with the same compression switch.

Diagnostic Procedure

Run the following checks on the PCU and the network share host before modifying the script:

1. Mount the network share from a separate Windows workstation. Right-click the drive, choose Properties, and record the free bytes. Compare against the size of the last successful .gho; the share should hold at least 1.2 times the source volume size with -z2 enabled.
2. From a command prompt on the file server, run dir /a /s O:\*.gho to enumerate every previous Ghost image. Old generations from AutoName rotation are frequently forgotten and can total several gigabytes.
3. Boot the PCU into the recovery environment, drop to a Ghost command shell, and execute ghost.exe -dd to obtain the exact free cluster count on the destination volume.
4. Estimate the source volume: from the same shell, run ghost.exe -ntchkdsk on the source partition, or use diruse /M /Q:1 C:\ from a WinPE command line to obtain the used cluster count.
5. Open D:\images\para.dat and verify the switches in use. Older 840D scripts ship with -z2 which delivers a 30% to 40% compression ratio on the HMI image; -z1 lowers CPU load and produces a larger .gho but more predictable sizing.
6. Read the timestamp inside the Ghosterr.txt. If the failure is reported at 50% consistently across multiple runs, the cause is compression ratio, not raw space.

Solution Path 1 - Free Destination Space

If the destination share is the limit, the most direct resolution is to free bytes. Apply the steps in this order:

1. Archive and move every .gho older than the most recent successful image to a long-term storage location (tape, NAS snapshot, off-line disk).
2. Delete redundant .ghs (spanned segment) files if the last dump used -split. Ghost 8.2 leaves the segments behind on abort.
3. Verify the new free space exceeds the source volume size by at least 20% to absorb compression inefficiency.
4. Re-run the same command line. The dump should now reach 100%.

Solution Path 2 - Adjust Compression and Split Options

Edit D:\images\para.dat (or the equivalent *.bat wrapper) and adjust the compression level so Ghost's pre-dump estimate matches the eventual file size:

- Original (fails at 50% on a 5 GB HMI source):
ghost.exe -batch -z2 -sure -fis -clone,mode=dump,src=1,dst=O:\del2.gho

- Alternative A: lower compression
ghost.exe -batch -z1 -sure -fis -clone,mode=dump,src=1,dst=O:\del2.gho

- Alternative B: no compression (fastest, largest)
ghost.exe -batch -z0 -sure -fis -clone,mode=dump,src=1,dst=O:\del2.gho

Trade-off table for typical 840D PCU 70.1 HMI images:

If the destination share can only hold the last image and the source volume is stable at around 4 GB, choose -z2. If a recent dump failed and the new source volume is more than 20% larger than the last successful one, fall back to -z1 or -z0 to eliminate the estimation error.

When the network share is provisioned as multiple smaller drives, use the -split=N switch to split the .gho into 2 GB segments. The flag also forces Ghost to compute the per-segment free space, which in many cases bypasses the 657 estimation failure because the working file no longer exceeds a single chunk's available size:

ghost.exe -batch -z2 -sure -split=2000 -fis -clone,mode=dump,src=1,dst=O:\del2.gho

Ghost then writes del2.gho, del2.001.ghs, del2.002.ghs, etc. The -span switch is a related alternative for spanning across multiple physical drives when the network share is unavailable.

Solution Path 3 - Trim Non-Essential HMI Data

The 840D HMI stores log files, traces, and NC backup archives that do not need to be in the master image. Trim them before running Ghost. From a WinPE command prompt:

del /q /s C:\dh\mb.dir\*.log
del /q /s C:\dh\diag.*
rd /s /q C:\dh\wrk.dir\temp
del /q /s "C:\Documents and Settings\*\Local Settings\Temp\*"
del /q /s C:\Windows\SoftwareDistribution\Download\*

Each of the listed directories can hold 200 MB to 1.5 GB on a long-running PCU. Trimming them before the dump keeps the source below the 657 threshold without changing the compression switch and without touching the installed HMI base.

SINUMERIK-Specific Considerations

Before re-running the backup, ensure the PCU is in a service-friendly state:

• Stop the HMI Advanced service. From Start > Run: net stop "SinuComNCK" and net stop "HMI Advanced". On 840D sl PCU 50.5 / PCU 70.2 systems the service is called SiemensHMI. Stopping these services prevents Ghost from racing against the HMI's own file handles and reporting error 657 on a perfectly good source.
• Disable virus scanners that intercept Ghost's sector-level read. Symantec Endpoint Protection, McAfee Agent, and Trend Micro OfficeScan all hook Ntfsd device calls and cause Ghost 8.2 to estimate a larger image than the volume actually contains. Set the scanner to a two-hour exclusion window for the duration of the dump.
• Re-seat the network cable or replace the switch port. A stalled SMB session is sometimes reported by Ghost as a destination full condition because the live write pointer stops advancing while Ghost keeps reading the source.
• Verify the date and time in the PCU BIOS. Ghost logs the timestamp into the error file. If the BIOS date is earlier than the last good image, ghosting utilities that perform a "compare" step may refuse the write.
• Set the source partition to be the active partition. Ghost 8.2 will skip the dump entirely and return 657 if the source volume is not the bootable primary partition; on 840D PCU 70.1 this is normally partition 1, but a previous failed restore may have left the active flag on partition 2.

Reference the Siemens Service Manual "SINUMERIK 840D sl, HMI Advanced, Service and Commissioning" (publication 6FC5397-0BP10 series) for the canonical backup flow that Ghost 8.2 is expected to plug into, and the HMI Configuration Manual (6FC5397-0BP20 series) for the partition layout that the dump captures.

Verification

After applying a solution, verify the dump is complete and the image is restorable:

1. From a workstation with the network share mounted, open Properties on del2.gho. A complete image is no smaller than the source volume minus the original free space, and not larger than the source volume size.
2. Re-image a test PCU or VM: from a Ghost console, run ghost.exe -clone,mode=restore,src=O:\del2.gho,dst=1 to the same partition number. A successful restore confirms the dump is internally consistent.
3. Check the time stamp in the Ghost session dialog matches the end time of the backup, not the 50% mark. A completed run logs Ghost exit code 0 into Ghosterr.txt.
4. Power up the restored PCU. The HMI must reach the operator area without 120202 (PLC stop - sign-of-life failure) or 120203 (PLC stop - user memory inconsistent) errors. If a PLC stop appears, re-load the PLC project from the card\user\clp.dir\... folder via the HMI Commissioning menu.

Preventive Maintenance

Troubleshooting Matrix

FAQ