Plan and prepare
List the records you cannot easily recreate and where each currently exists. Include personal documents, project inventories, permission records, and the instructions needed to open them. Then ask what single event could remove every copy: a lost laptop, a damaged room, an account lockout, or an accidental deletion synchronized across devices.
Plan copies with different failure paths. A second folder on the same drive offers little protection from losing that drive. A cloud copy may help with local damage but can depend on the same credentials as the primary copy. A disconnected copy can help separate routine mistakes or attacks from the backup.
Use a clear process
Choose an update schedule based on how much recent work you could accept losing. Record who performs the backup, what is included, where it is kept, and how completion is checked. Keep sensitive records appropriately protected and make a deliberate recovery-access plan; a backup nobody can unlock is not usable.
Use versioned backups when possible so that an unwanted change does not immediately erase every earlier state. Distinguish synchronization from backup in your notes: synchronization usually aims to keep locations alike, including some mistakes. Confirm the chosen service's actual behavior rather than relying on the word 'backup' in a product name.
Worked example
Consider a project whose laptop and external drive are both kept in the same office, while a cloud folder synchronizes automatically from the laptop. The three locations look like multiple copies, but a building incident could affect the first two and a mistaken deletion could propagate to the cloud folder. Map these relationships before buying another device. The project may need a protected versioned backup, a suitably secure copy in another location, or both, depending on the records and the capabilities of the tools it actually uses.
Decisions and exceptions
Write down a realistic recovery objective in ordinary language. For example, the team might accept recreating a day's routine catalog edits but not losing a year of scanned originals. That distinction can guide how often different material is copied. Identify who notices a failed backup and what they do next; an automated job that silently stops is not a dependable routine. Keep a short completion log with the date, scope, destination identifier, and result. Do not put passwords, private storage addresses, or recovery keys into a public maintenance summary.
Check and improve
Review the plan for human dependencies as well as devices. If one person alone knows the account recovery process, their absence can make every cloud copy inaccessible. If a volunteer's personal account is used, clarify ownership and future access before relying on it for community records. Arrange authorized recovery securely and test it through the provider's supported process. At a regular review, ask whether each copy is current, independently protected, readable, and recoverable by the people responsible. A backup plan should remain understandable when a custodian leaves, a subscription changes, or the usual computer is replaced.
Solo and community application
Alone, start with one small collection and a routine you can sustain. A community archive can assign a primary custodian and a backup custodian, with authorized recovery access handled securely. Avoid publishing storage locations or access details in the public catalog. Record only the information ordinary readers need.
Reference guidance
CISA recommends offline backups and regular recovery testing, and warns against leaving external backup drives connected unnecessarily. The dependency questions here help apply that guidance. Finish the plan with a test restore to a separate location, then review it when devices, accounts, or custodians change.