Full OS Download to Redundant OS Servers in SIMATIC PCS 7: Historical Data Protection and Redundancy Sync

Performing a Full OS Download to a redundant OS Server pair in SIMATIC PCS 7 does not overwrite or delete historical process data. WinCC configuration downloads update target project files, graphics, and scripts, while leaving runtime archive databases (ArchiveManager\AlarmLog and TagLog) intact on the server disk, provided the target project directory is not manually deleted. To perform a full download without losing live data or creating historical gaps, execute a staggered sequential download: download Server 2 while Server 1 runs the plant, activate Server 2, wait for complete redundancy synchronization ('Synchronization finished' message), and only then download Server 1.

Full OS Download vs Delta OS Download: File System Impact

During ongoing plant operation, automation engineers frequently perform Delta OS Downloads ('Changes Only') to deploy modified graphic screens, new tags, or updated alarm limits without interrupting plant supervision. However, after extensive logic modifications, SFC type recompilations, or Safety Matrix changes, delta compilation is often invalidated, making a Full OS Download mandatory.

Engineers commonly fear that selecting 'Entire OS' will wipe historical tag logging, purge operator alarm history, or destroy user trend groups. Understanding the internal architecture of WinCC target deployment dispels this misconception: the download engine updates the configuration database (<ProjectName>.mcp, .mdf project schema) and user interface assets, but deliberately isolates and preserves the runtime archive folder structure.

Preservation of Historical Archives, Trends, and User Data

When a Full OS Download executes across the network from the Engineering Station:

Historical Archive Protection: Runtime archives located in the <ProjectDir>\ArchiveManager\ directory—including AlarmLog, TagLogFast, and TagLogSlow—are ignored by the download transfer engine. The existing segmented SQL database files remain attached and fully intact.
Operator Trends and Compositions: Custom trend curves, ruler settings, and graphic compositions saved by control room operators in WinCC Runtime are stored in dedicated runtime tables and are fully preserved across full downloads.
Critical Caveat: Historical data is only preserved if the engineer allows WinCC to overwrite the existing target project in-place. If an engineer manually deletes the target project directory on the server hard drive prior to download, all historical archives are permanently lost.

The Staggered Redundant Server Download Workflow

To perform a full download on a redundant server pair with zero plant downtime and zero data loss, execute a rigorous staggered procedure:

Audit Partner Status: Confirm that Server 1 and Server 2 are fully operational, redundant synchronization is active, and OS Clients are balanced across both servers.
Download to Standby Server (Server 2): Initiate a Full OS Download to Server 2 from SIMATIC Manager. Server 1 remains fully active, logging alarms and serving operator screens.
Activate Runtime on Server 2: Once download completes, activate WinCC Runtime on Server 2. Server 2 begins logging live data and initiates the redundancy sync handshake with Server 1.
Wait for Synchronization Completion: Allow CCRedundantServer to synchronize all archive records generated on Server 1 while Server 2 was offline.
Failover and Download Primary Server (Server 1): Deactivate Runtime on Server 1. Verify all OS Clients switch transparently to Server 2. Execute the Full OS Download to Server 1.
Reactivate Server 1 and Final Sync: Activate Runtime on Server 1 and await the final redundancy synchronization.

Monitoring Redundancy Synchronization and Process Alarm Messages

The critical failure point during full downloads is interrupting redundancy synchronization by downloading Server 1 before Server 2 has finished catching up, which creates permanent gaps in historical data.

To monitor redundancy progress in WinCC Runtime:

Open the Process Alarms or System Messages list on Server 2.
Watch for the start message: @1000005 Redundancy: Synchronization launched.
Wait patiently until the concluding message appears: @1000006 Redundancy: Synchronization finished.
Depending on the offline duration and archive tag throughput, synchronization typically takes between 5 and 15 minutes.
Note that the WinCC message window does not always auto-scroll; refresh the view periodically or inspect internal tags @RedundantServerState and @RM_Master.

Sequence of Operations: Staggered Redundant OS Download Schedule

The following step-by-step sequence guarantees continuous supervisory availability and data integrity:

Step PhaseTarget StationStation Operational StateAction ExecutedExpected System ResponsePhase 1: Pre-AuditSERV 1 & SERV 2Both in RuntimeVerify Redundancy healthy@RM_Master assigned; clients connectedPhase 2: Target 2 PrepSERV 2Deactivate RuntimeClose WinCC RuntimeClients switch cleanly to SERV 1Phase 3: Download 2SERV 2OfflineExecute Full OS Download from ESProject files overwritten; archives preservedPhase 4: Sync Target 2SERV 2Activate RuntimeLaunch WinCC RuntimeMsg: 'Synchronization finished' appearsPhase 5: Target 1 PrepSERV 1Deactivate RuntimeClose WinCC RuntimeClients switch cleanly to SERV 2Phase 6: Download 1SERV 1OfflineExecute Full OS Download from ESProject files overwritten; archives preservedPhase 7: Final SyncSERV 1Activate RuntimeLaunch WinCC RuntimeMsg: 'Synchronization finished'; full redundancy restored

Pre-Download Safeguards and Recovery Procedures

Prior to executing full OS downloads in production environments:

Backup Active Project: Create a zip archive or use WinCC Project Duplicator to take an offline snapshot of the project directory.
Check Disk Space Reserves: Ensure that drive C: (or project partition) on both servers has at least 20% free space to accommodate temporary SQL synchronization transaction logs during redundancy catch-up.
Avoid ES Runtime Collisions: Never run WinCC Runtime directly on the Engineering Station while downloading to live servers.

Verification

Verify post-download system health across both servers and all clients:

Confirm that both Server 1 and Server 2 show status 'Runtime Active' with balanced client connections.
Open the WinCC Alarm Logging control; verify that alarms logged prior to the download remain visible and searchable in historical views.
Open WinCC Tag Logging trends; verify that continuous historical curves exist across the download window with zero data gaps.
Check the WinCC Diagnose folder on both servers (CCRedundantServer.log) to confirm clean synchronization handshakes.

Limitations and Operational Precautions

Adhere to the following operational precautions:

Never Delete the Old Target Directory: Do not manually delete the target project folder on the OS Server prior to a full download; deleting the folder destroys the ArchiveManager database repository.
Do Not Rush the Second Download: Never deactivate Server 1 while Server 2 is actively synchronizing; prematurely interrupting synchronization creates unrecoverable archive gaps.
Terminal Bus Reliability: Ensure no network maintenance or switch reboots occur on the Terminal Bus during the synchronization phase.

Engineer FAQ

Under what conditions would historical data actually be lost during an OS download?

Historical data is lost only if an engineer manually deletes the target project directory on the server hard drive prior to downloading, or if the SQL database files become corrupt.

How long does redundancy synchronization take after Server 2 restarts?

Synchronization typically takes between 5 and 15 minutes, depending on the volume of alarms and tag records accumulated on Server 1 while Server 2 was offline.

Can operators still control the plant while Server 2 is being downloaded?

Yes. While Server 2 is offline, Server 1 actively services all OS Clients, maintaining continuous plant monitoring, alarm processing, and operator control.