List collections rather than only devices
Create a table with the data collection, working location, responsible person and backup destination. One entry might cover current quotations on the office computer, another completed projects on the NAS. Add the last verified backup date and whether multiple versions are retained.
Identify synchronisation explicitly. The same folder on two computers may immediately reflect a shared deletion. Being visible twice therefore does not by itself make it an independent backup. For cloud files, also establish whether local entries contain the full download or only placeholders.
Find gaps and shared dependencies
Look for collections without a backup destination and destinations on the same device. A backup archive on the same internal disk does not protect against that disk failing. An external medium not connected for months may contain only an old state. Record these limitations specifically rather than using a vague protected label.
Also note which account or application is required for recovery. Credentials belong in protected storage, not in the inventory. A reference to their storage location helps without distributing secrets unnecessarily. For shared data, establish who is authorised to use that information when needed.
Confirm the map through a small test
Choose a non-sensitive file from every important collection and check that it can be found at the stated backup destination. Restore it into a separate test folder. This turns an assumed relationship into a verified one. Record the result and date rather than marking every collection as backed up without checking.
Update the map after new projects, account changes and equipment replacement. It does not need to list every file individually. Its purpose is to keep the main storage paths understandable and give deletion, migration or replacement decisions a traceable basis. Keep a copy accessible even when the main network storage is unavailable.
