Which parameters and programs should be backed up before service work? ART-429

A backup is a recorded state, not an unnamed folder

A useful copy answers four questions: which machine it came from, when, in what state, and who made it. A file named `backup_final` without a date, version and description can be older than required or belong to another configuration. Worse still is applying it to another machine merely because the model name looks similar.

Before service, agree who is responsible for the data. This person need not be a repair specialist, but must ensure the copy is stored under the rules, has a clear name and that service knows its contents. Do not copy data to a random personal device or send configuration files through an unsecured channel.

Procedure before service

Start with the scope of work. Ask service whether software, the controller, parameters or storage are expected to change, or whether the work is mechanical only. This is not diagnosis; it helps identify which data are especially critical. If the nature of the intervention is unknown, at minimum make a full inventory of available standard copies and logs without trying to extract hidden system data yourself.

Then verify identification: model, serial number, software version and the date of the last normally confirmed operation. Keep these beside the file or in a controlled register. Record the time zone if production runs across several shifts: it matters when comparing an alarm log with a service event.

Export only through the manufacturer-provided standard function and from an account with the appropriate permissions. Do not install third-party software, connect unknown USB media, copy system directories “just in case,” or disable antivirus or access policies. For industrial systems, cybersecurity and data integrity are part of operational risk, not a separate IT formality.

After creation, seeing a file is not enough. Check its name, date, size where needed, storage location and completed-operation indication if the standard system provides one. A recoverability check does not mean trying to restore data on a production machine. The manufacturer or service must define the method: sometimes an integrity check is enough; sometimes a test environment is needed.

Keep controlled copies according to the company policy and data risk, but do not invent a universal media scheme. Separation of access, protection against accidental overwrite, version control and a clear owner matter more. In the log, state where the copy is held without publishing secret paths, passwords or keys in production chats.

How to name and document copies

A name should be readable: machine identifier, data type, date, time, version and status. For example, the logic `identifier_type_date_version` is better than the generic word “new.” Do not put a password, personal data or a confidential order description in the name. Store a short description file or register entry beside it: who created the copy, under which standard procedure, what it contains and whether it was checked by the defined method.

Distinguish an “archive before service,” a “working version after service,” and an “unconfirmed file.” The last must not become the baseline copy merely because it has a newer date. When work is complete, service should describe what changed, and the responsible person should record which new version became the controlled state after verification.

Common mistakes

• Keeping the only copy solely on media permanently connected to the machine.
• Failing to record the model, serial number, date and software version.
• Restoring an old copy “to see if it helps.”
• Sending archives with passwords in an open chat.
• Clearing the error log before service.
• Assuming that cutting programs replace the system configuration, or vice versa.

Questions to ask service before copying

Before work starts, agree in writing exactly which data service expects to receive and in which format. Ask whether log export is needed for a defined period; whether a version update is planned; whether there are special media requirements; who may create and receive the archive; and whether additional agreement with IT or cybersecurity is needed. Do not ask service for a universal list for every machine: the correct answer depends on the model and planned intervention.

Separately agree what is not included in a normal copy. Passwords, keys, licence data, network configurations, personal accounts and access secrets must not automatically enter a general archive. If service needs access, use an agreed controlled method rather than an email or message attachment.

Version, integrity and authorization to restore

A copy has value only together with its compatibility context. System software version, controller type, machine options and creation date can be critical for restoration. Therefore, do not call a file a “universal backup” and do not move it between machines, even if they look identical. Restoring on operating equipment without manufacturer or service authorization can change not only data but also the system’s safe state.

An integrity check confirms that the recorded copy was not interrupted and can be identified; it is not an instruction to deploy it. The standard system or service determines the control method. If standard export reports an error or the media cannot be read, do not repeat the operation indefinitely or seek a software workaround: record the symptom and pass it to the responsible person.

After service work is complete

Ask for a record of whether versions, parameters, libraries or configuration changed. After an agreed check, a new controlled state is created, but the pre-service copy is not overwritten: it may be needed to analyse changes. Mark the new archive “after service, verified by procedure” only when that is actually confirmed. If verification is postponed, state that clearly.

Backup should be part of a regular process, not a reaction to a failure. Frequency, responsibility and storage are determined by data risk, system changes and company policy. A general article does not set these values.

Role matrix: who owns the data and who makes the decision

Before service work, it is useful to name not only the person who performs the export but also the owner of every decision. The data owner maintains the register of copies, checks file identification and ensures their information is available to the next shift. Service determines which data are needed for a specific intervention and describes what changed after the work. IT or the cybersecurity responsible person agrees the permitted storage location, transfer channel and access to sensitive materials. The area manager organizes machine time and status but does not replace any of these roles with a technical decision.

One person may perform several roles only with formally granted authority. It is especially risky when an operator rushing to finish a shift simultaneously decides which configuration data to copy, where to send them and whether something can be restored from them. If there is no owner or the role is unclear, the safe result is to pause and escalate to the responsible person, not to search for a “universal” copying method.

A role matrix can be kept as one short record alongside the service request: role, person or department, permitted action, contact channel and status. It need not include passwords, keys, internal addresses or configuration details. Its purpose is to make clear who answers a specific question when the previous performer is unavailable.

A copy register without sensitive data

The register must not contain the files themselves or secrets. Its sufficient safe content is: machine identifier, data class, creation date and time, responsible role, version or status, controlled storage location at policy level, completion-confirmation method, related service request and an access-restriction note. For example, instead of an exact network path, state “approved service-archive storage, role-based access.”

Keep copy status separately from its date: “created,” “accepted into the register,” “awaiting verification,” “approved as a controlled state,” “obsolete,” or “do not use.” This prevents a newer file from automatically displacing a verified one. If a file has an unknown origin, do not rush to delete it or move it to the machine: record the fact and pass it to the data owner.

How to document changes after service

When work is complete, obtain not only a “service completed” note but also a controlled description of changes. The record should include the request number, date, performer, documents or report, general type of changes without technical instructions, result of the agreed check and status of the new copy. The word “updated” without a version, date and reference to a report does not show what should be compared in the future.

Keep the old pre-service archive as a historical fact; do not overwrite it with a new copy. A new copy can become the controlled state only after service and the responsible role confirm it through their procedure. If verification is still incomplete, the honest status “awaiting confirmation” is more useful than “ready.” The next shift then sees the decision boundary and does not use unverified data.

If a question about access, format or compatibility arises after service, do not resolve it through independent restoration or configuration editing. Record the question, record version and responsible addressee. A backup helps service restore context, but it does not itself grant authority to restore.

Passing context without passing secrets

Service and the next shift often need not the archive itself but a clear description that it exists. A handover need only state the machine identifier, copy class, creation date, verification status, related request number and the role that has access. This preserves traceability without exposing passwords, direct-access links, licence data or configuration contents in a work chat.

If a copy must be sent to external service, first agree the recipient, purpose and channel. The data owner must confirm that the package matches the agreed list, and the cybersecurity responsible person that the channel is permitted by company policy. A request to “send everything you have” is not sufficient grounds to assemble a broader archive. Resolve uncertainty by clarifying the scope, not by excessive data disclosure.

After transfer, update the register with fact, not assumption: when it happened, to whom by role, which request it is connected to and whether a response is expected. Do not record the secret credentials or technical details needed only by an authorized specialist. This makes the log useful for auditing actions and safe for everyday use.

When to stop backup and escalate

Stop if standard export reports an error, there is no confirmed access right, the machine identifier does not match the record, or service requests data outside the agreed list. Do not compensate by copying system folders, changing an account, disabling protective policies or using third-party media. Record only the observed fact in the log and pass it to the data owner, service or IT role through the internal route.

Escalation does not mean abandoning preparation for service. While the question is being resolved, you can preserve non-conflicting non-technical data: request number, time, current status and the list of already available permitted materials. This gives service context while the team retains control of what was prepared and why the next step was deferred.

What cannot be determined without data

Without the model documentation and the service position, it is impossible to determine the complete file list, backup compatibility, permitted media, copying interval, verification procedure or restoration procedure. It is not possible to guarantee that a copy from another software version, another machine or an unknown origin is safe to use.

Checklist

• [ ] The scope of service work and the data owner are agreed.
• [ ] Machine identifier, date and software version are recorded.
• [ ] Programs, libraries, configuration data and logs are separated by class.
• [ ] Export is performed by the permitted standard method.
• [ ] The copy has a clear name, description and controlled storage location.
• [ ] Alarm logs are preserved before intervention.
• [ ] Restoration is not planned without a manufacturer or service procedure.

Need a service check?