Define project backup and restoration boundaries

Chapter overview

Bottom line: Define on paper the types of data you want to save, restoration roles, and the security evidence index. You do not create a backup in this chapter, nor will you press any backup or restore buttons.

Purpose

Define backup scopes, restore responsibilities, and evidence indexes without environment values.

Prepare

A blank worksheet and a pinned source; without opening a project or execution environment.

Time

About 20 minutes

System change

Do not create or restore real environment backups; only compile de-identified offline backup and restore drill lists.

Expected result

Define backup scope, custody, checks, and restoration gates without treating the existence of a backup as proof that it can be restored.

Stop conditions

• A backup or record contains confidential, environment-identifying, or unapproved content.
• The task requires restoring a backup or overwriting state in a real environment.

Scope and safety boundaries

This chapter works only on paper. Read only pinned sources and fill out forms with "Data Category" and "Responsible Role". Read-only views of any running environment are approval-required and will not become safe just because it makes no changes.

• Safe: Only offline read-only pinned sources, or no access to placeholder categories of the execution environment at all.
• Isolated test: Projects with clear written approval, a non-production test environment, administrator presence, limited network exposure, and a proven stop-and-recovery plan can be evaluated; this chapter does not perform them.
• Approval required: Viewing or changing the live/running environment falls into this category; the same goes for read-only. This chapter does not provide such procedures.
• Never automate: Do not read or write groups, send a KNX telegram, perform ETS programming or downloads, connect a KNX interface or bus, or control physical equipment. The test bus is no exception.

Joining the repository, installing or starting also requires full isolation gates, written approval, approved immutable artifact/image digest and source-to-build attestation. Stop if any item is missing; these actions are not performed in this chapter.

Core concepts

The backup role manages retention and expiration. The restoration role decides when a separate restoration exercise may begin. The independent-review role checks scope, evidence limits, and privacy. A statement that "someone is responsible" cannot replace these three distinct assignments.

Preparation and prerequisites

Prepare a blank index that does not contain live values. Only fill in each field with category, role or status.

• Purpose column: Only write save, audit or restore plan, do not default to restore.
• Scope column: Lists data categories, exclusion categories, and retention policies, but does not list project names or content.
• Responsibility column: lists the roles of creation, custody, restoration decision-making, independent review and exception approval.
• Evidence column: Lists source version, creation record type, completeness status, review status and evidence gaps.
• Privacy check: Confirm that there are no secrets, accounts, endpoints, hosts, networks, paths, serial numbers, addresses, scopes, or environment names.

Time data rules: Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed. When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.

Pinned sources do not have precise backup or restore procedures for ETS projects. Therefore, programs, formats, compatibility and restoration results are marked as unverified.

Steps

The following six steps only organize paper management information. You will not open a formal project, nor create, import, or overwrite any content.

1. Write down the purpose of saving. Explain in one sentence why backup management is needed, and state that this chapter does not perform backup or restore.
2. Define the backup scope. Only the data categories that need to be saved and those that must be excluded are listed. Do not fill in any live values.
3. Assign responsibilities. Assign custody, restoration decision-making, independent review and exception approval roles respectively. Then write the retention policy and handover conditions.
4. Create a privacy-safe index. Document status, source version, retention policy and evidence limit for each preservation category. Replace actual content with “Redacted” or "Pending Verification".
5. Mark the evidence limit. Separate "copy existence", "offline integrity record" and "recoverability". The first two items cannot endorse the last item.
6. Submit the index for independent review. Confirm that the index does not identify the environment or state unverified results as facts. If anything is missing, return it for correction.

When filling in the deadline: Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed. When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.

Verification and evidence

The completion criterion is that the index is safe for review, not that the environment is restorable.

• The purpose of preservation, inclusion and exclusion categories are all clear, and there are no environmental values.
• Custody, restoration decision-making, independent review and exception approval each have responsible roles.
• The evidence index only contains category, status, retention policy and source version.
• Environment/event timestamps, log timestamps, backup creation times, execution times, or any time that can be associated with family activities/system events are not allowed.
• When there is a real need for governance, and the data is not derived from live events and the environment cannot be identified, the reviewed formalized policy deadline or abstract expiration status can be used. When precise dates are not required, relative/status classifications such as "not expired", "to be renewed", and "expired" are preferred.
• A copy's existence and offline integrity are not described as proof of a successful restore.
• Accurate backup procedures, compatibility and restore results are still marked as unverified.
• All environment, KNX bus, ETS and integration results remain unproven.

Next step: Go to Chapter 18, check for minimum exposure with an offline worksheet.

Troubleshooting

• The scope reads like a list of contents: Replace it with data categories and remove names, locations, and values.
• The restore responsible role cannot be found: Leave unassigned and stop. Don't automatically assume that the custodial role is a restoration decision-making role.
• A copy is described as restorable merely because it exists: Limit the conclusion to “copy recorded,” and mark parsing, compatibility, and restoration as unverified.
• Index contains sensitive information: Stop sharing and withdraw the copy. Minimize it again and give it to a different role for review.
• Someone asked for the operation screen: Refuse. There is no live backup or restore procedure in this chapter.
• Someone asked to join or start the tool: Stop. In the absence of an approved immutable provenance gate, it will not join, install or start.

FAQ