Build a Robot Cell Backup and Recovery Plan You Can Verify

Define the recovery outcome before selecting files

Specify what recovered means for the cell. Restoring a program to a controller is one outcome; restoring coordinated operation with the PLC, tooling, vision system, and production records is broader. Write the acceptable data-loss window and the target time for returning to a reviewed operational state. Mark these as local objectives rather than vendor promises, then identify who can authorize each stage of recovery.

Universal Robots' PolyScope SW5.21 System Backup page describes a full system copy and restoration to a previous state. It provides a concrete manufacturer example, not a universal robot-cell backup procedure. Use it to separate controller recovery from the surrounding dependency problem. Your recovery contract should name the controller identity, software family, external equipment, and validation evidence required. A controller that starts successfully may still be connected to incompatible recipes or an outdated tool configuration.

References: System Backup, PolyScope SW5.21

Distinguish program exports, configuration, and system images

The SW5.21 service documentation lists different Magic File functions for programs and installations, configuration, logs, and uploading programs. The distinction matters: an export of programs and installation files is not interchangeable with a full system backup, and a diagnostic log has a different purpose again. Document the exact approved export mechanism and its contents for your controller. Do not enable disabled security features merely to reproduce an example backup method.

Create an inventory with artifact type, source device, software version, creation time, storage location, and the recovery step that consumes it. Include a human-readable explanation of what the artifact does not contain. Name backups so that an operator can distinguish an accepted configuration from an experimental one without opening every archive. Keep the last accepted set alongside newer candidates until a recovery review establishes which candidate is suitable for use.

References: Using Magic Files, e-Series service documentation SW5.21 · System Backup, PolyScope SW5.21

Capture the dependencies outside the controller

Walk through the cell's dependency chain with its owners. Record PLC project identity, I/O mapping, recipes, tool configuration, vision calibration references, network settings, installed extensions, and any licensed components needed for operation. For each dependency, distinguish a backed-up file from knowledge that exists only in a person's memory. Store access instructions securely and separately from broadly shared technical records, with an approved route for an authorized maintainer to retrieve them.

If the cell uses ROS 2, retain the application source revision, build or deployment description, parameter files, and matching interface definitions. The official Jazzy recording tutorial describes saving and replaying message data; that makes bags useful diagnostic evidence, not a substitute for the application and configuration inventory. Give recorded data its own purpose and retention rule. Recovery should not depend on guessing which executable, model, or parameter file originally produced a saved trace.

References: Recording and playing back data, official ROS 2 Jazzy documentation source

Preserve a consistent accepted set

Choose a controlled point at which the controller, external projects, and recipe records describe the same accepted cell configuration. Have each owner confirm the version they contributed. A collection of individually recent files can still represent a combination that never operated together. Record a manifest that ties the pieces to the same change record, and explain any component that could not be captured at that point.

After export, verify that the artifacts exist, are readable through appropriate tools, and match the manifest. Generate integrity hashes for transfer checking where your approved tooling supports them. Keep a separate protected copy and periodically establish that an authorized person can retrieve it. An integrity match proves the copied bytes match; it does not prove the configuration is correct or recoverable. Maintain distinct evidence for successful export, successful retrieval, and a completed restore rehearsal.

References: Using Magic Files, e-Series service documentation SW5.21 · System Backup, PolyScope SW5.21

Check identity and version compatibility before restoration

Record the exact controller and robot identity before choosing a restore target. The SW5.21 System Backup documentation identifies a serial-number matching requirement when restoring with a new SD card image. The SW5.20 service guidance also places restrictions on software downgrades. These are manufacturer-specific compatibility constraints, not instructions to move backups freely between robots. Use the service documentation applicable to the actual hardware and software, and escalate unresolved compatibility questions to qualified support.

Prepare a decision sheet covering the original target, a supported replacement target, and the evidence needed for each. Separate restoring known data from repairing a physical fault; loading an archive cannot establish that a replaced device has been correctly integrated. Keep uncertain backups quarantined until their provenance is understood. Before any destructive restoration, preserve available diagnostic evidence and the current configuration through approved procedures so that investigation and rollback options are not unnecessarily lost.

References: System Backup, PolyScope SW5.21 · Downgrading vs. Restoring system backup, SW5.20

Rehearse recovery in stages with explicit release points

Begin a rehearsal with document retrieval and compatibility review. Continue with supported offline or isolated checks where available, then a manufacturer-supported restore on an approved target under the responsible team's control. Record elapsed time and unexpected dependencies at each stage. Do not describe an archive-opening exercise as a full recovery test: it validates only that limited step. Name the boundary of the rehearsal in its result.

Before physical operation, qualified personnel must verify the restored configuration against the actual installation, including relevant tool, frame, I/O, and safety arrangements. Keep startup and restart behavior in the review. The SW5.21 I/O setup documentation allows inputs to trigger program actions, which is a concrete reason to examine external requests during recovery. Restoring power or communications must not become an unreviewed motion command. Follow the applicable isolation, commissioning, and validation procedures rather than improvising live tests.

References: System Backup, PolyScope SW5.21 · I/O Setup, PolyScope SW5.21

Worked hypothetical example: the missing vision recipe

Suppose a rehearsal restores the robot program successfully, but the vision computer contains a newer recipe than the accepted cell manifest. This is an invented scenario. The team should stop at the configuration release point, identify which recipe belongs with the restored program, and recover or reconstruct it through the vision owner's procedure. A successful controller restore is recorded as evidence for that stage, while complete cell recovery remains unproven.

The corrective action is more specific than taking backups more often. Add the vision recipe to the accepted-set manifest, assign its export owner, and define the compatibility check that catches the mismatch. Repeat the affected rehearsal stage after correction. If the missing artifact cannot be recovered, document a recommissioning path and revise the expected recovery time. This turns a rehearsal failure into an actionable dependency fix while preserving an honest record of what was actually demonstrated.

References: System Backup, PolyScope SW5.21

Maintain the plan through changes and incidents

Make accepted configuration changes trigger an update to the recovery set. Identify which changes require a new rehearsal: controller replacement, software migration, tooling changes, or a different external dependency may invalidate earlier evidence. Keep incident recovery notes separate from routine backup records, but feed newly discovered dependencies back into the plan. Assign a maintainer and a review date so the procedure does not become an abandoned commissioning document.

Close each rehearsal with a concise result: target identity, backup set, stages attempted, evidence retained, elapsed time, unresolved issues, and release authority. Record whether physical operation was included and under which procedure. For ROS recordings, ensure diagnostic playback cannot accidentally reach motion-command consumers outside an approved test. The lasting deliverable is a recovery capability with known limits, not a folder labeled backup whose contents nobody has ever tried to retrieve or use.

References: Using Magic Files, e-Series service documentation SW5.21 · Recording and playing back data, official ROS 2 Jazzy documentation source

Checklist

• Define recovery scope, data-loss objectives, and responsible release authority.
• Inventory program exports, configuration files, diagnostic evidence, and full backups separately.
• Connect external projects and recipes to the same accepted configuration manifest.
• Verify readability, integrity, protected storage, and authorized retrieval.
• Check robot identity and supported software compatibility before restoring.
• Rehearse in approved stages and state exactly which stages passed.
• Require qualified configuration and safety validation before physical operation.
• Refresh recovery evidence after relevant equipment or software changes.

Common questions