About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Ask a small business how its data is backed up and the answer is often a list of tools: the Windows server backup, a script on the Linux box, Time Machine on the design team's Macs, snapshots on the NAS, and an assumption that Microsoft looks after the email. Each tool may be working perfectly. Each one reports on what it was configured to protect.
The gaps sit between the tools. A folder moved from one share to another, a Linux volume added last year, a Mac whose backup disk has not been plugged in since March, a cloud service someone assumed was covered. None of those show up as a failed job, because no job was ever asked to cover them (our reading).
This guide describes one inventory, organised by data set rather than by tool, and simple read-only checks that compare it with what exists.
Why it matters
The Australian Signals Directorate's Information Security Manual (ISM) control ISM-1511, also part of all three Essential Eight maturity levels, reads: "Backups of data, applications and settings are performed and retained in accordance with business criticality and business continuity requirements." ISM-1810 adds: "Backups of data, applications and settings are synchronised to enable restoration to a common point in time." ISM-1515 requires that restoration "to a common point in time is tested as part of disaster recovery exercises."
All three controls assume you know what your data, applications and settings are, how critical each is, and which backup covers it. With several tools in play, the only place that knowledge can sit together is an inventory (our reading).
The ISM also has two procedural controls, ISM-1547 and ISM-1548, that call for backup and restoration "processes, and supporting data backup procedures" and "processes, and supporting data restoration procedures" to be "developed, implemented and maintained". An inventory is the natural index for those procedures (our recommendation).
What the frameworks ask you to list
NIST SP 800-34 Rev. 1, the United States contingency planning guide, describes a business impact analysis in three steps: determine processes and recovery criticality, identify resource requirements, and identify recovery priorities. Its examples of resources to identify are "facilities, personnel, equipment, software, data files, system components, and vital records." It says recovery priorities should take account of "mission/business process criticality, outage impacts, tolerable downtime, and system resources."
It also asks that backup policies "specify the minimum frequency and scope of backups (e.g., daily or weekly, incremental or full) based on data criticality and the frequency that new information is introduced", and "designate the location of stored data, file-naming conventions, media rotation frequency, and method for transporting data offsite."
NIST SP 800-209, on storage infrastructure security, is more specific about the backup side. Its recommendation CM-SS-R1 is to "Create a comprehensive inventory of all storage devices", including "Data protection appliances", "Backup clients and servers" and "Designated backup servers for hosts or off-site backup". CM-SS-R2 is to "Create a comprehensive inventory of all data and configuration assets", including "File shares and ACLs", "Replicas and snapshots.", "Backup catalog and access rights." and "Users, groups, roles, and rights."
Both documents are written for United States federal systems; their lists are useful starting points for a small business rather than requirements (our reading).
One row per data set
Organise the inventory around data sets, not around tools or machines. A data set is anything that would be restored as a unit: a file share, a database, a mailbox collection, a user's laptop, a website, a line-of-business application with its configuration (our recommendation).
Suggested columns for each row (our recommendation):
| Column | What to record |
|---|---|
| Data set | Plain name, for example Accounts share or Design Macs |
| Business owner | The person who decides how much loss is acceptable |
| Platform and location | Server or service, volume or path, physical site or cloud region |
| Criticality | Your own scale, tied to the business impact analysis |
| Loss tolerance | How much recent work could be lost and re-done |
| Downtime tolerance | How long the business can work without it |
| Backup method | Tool, schedule, what is included and excluded |
| Copies | Where each copy lives, and which copies are on separate infrastructure |
| Retention | How long each copy is kept |
| Who can delete | Accounts that can modify or delete the backups |
| Restore method | Tool and procedure document, including what must exist first |
| Restore dependencies | Keys, passwords, licences, software versions, accounts |
| Last restore test | Date, what was restored, result, where the evidence is |
| Known gaps | Anything not covered, and who accepted that |
The Who can delete column connects to the ISM's access controls. ISM-1707, for example, reads "Privileged user accounts (excluding backup administrator accounts) are prevented from modifying and deleting backups." ISM-1708, at Essential Eight maturity level three, extends that to "Backup administrator accounts" during the retention period. Recording who can delete each copy makes it obvious when one account can remove every copy of a data set (our reading).
The Restore dependencies column is where mixed estates often fail. A backup encrypted with a key held only on the server it protects, or an application that needs a licence server that is not in the inventory, restores as unusable data (our reading).
Platform notes
Windows and Linux servers
Inventory volumes and databases, not just shares. Shares are what users see, but data also sits in application folders, local databases and service accounts' profiles (our reading). The read-only checks below provide scoped discovery views to compare with the inventory. They are not exhaustive data discovery: reconcile missing filesystems, mounts, application stores and provider-managed resources separately.
Macs
Apple's documentation says Time Machine "automatically backs up your Mac and performs hourly, daily, and weekly backups of your files" when it is turned on. It also describes local snapshots: they "are created hourly, stored on the same disk as the original files, and saved for up to 24 hours or until space is needed on the disk", and "Local snapshots are only created on disks using the Apple File System (APFS)."
Apple's own recommendation is that "it's recommended that you back up your files to a location other than your internal disk, such as an external hard disk, a disk on your network, or a Time Capsule." For the inventory, record where each Mac's backup destination is and when it last completed; a local snapshot on the same disk is not a separate copy (our reading).
NAS devices
A NAS is often both a data set and a backup destination. Snapshots on a NAS are kept on the same device as the data, so they help with accidental deletion but do not protect against loss of the device itself (our reading). Give the NAS its own rows: one for the data it holds, and one for each backup set stored on it, so that losing the NAS shows every data set affected.
SaaS and cloud services
Microsoft's shared responsibility page states: "Regardless of the type of deployment, you always retain the following responsibilities". The first listed is "Data - You're responsible for your data, including data classification, data protection, encryption decisions, and compliance with data governance requirements." Accounts and access management are also listed as yours.
Microsoft's consumer Services Agreement goes further: "In the event of an outage, you may not be able to retrieve Your Content or Data that you've stored. We recommend that you regularly backup Your Content and Data that you store on the Service". Business subscriptions are covered by separate terms (our understanding); read the agreement for each service you use and record in the inventory what the provider commits to and what is left to you (our recommendation).
Give each SaaS data set its own row with the same columns. If the only answer under Backup method is the provider's own retention, write that down and have the business owner accept it, rather than leaving the row blank (our recommendation).
Read-only checks
These commands list what exists so you can compare it with the inventory. They change nothing. Keep the output, including any errors or access-denied messages, alongside the inventory.
Windows PowerShell 5.1 or PowerShell 7, on each Windows server:
Get-Volume
Microsoft describes Get-Volume as returning Volume objects through the installed Windows Storage module. Check that module is available in the PowerShell environment and use an appropriately authorised account. Its documentation limits dynamic-volume support to specified other cmdlets; do not treat this output as proof that every dynamic volume is covered. In a Failover Cluster, Storage-module cmdlets operate at cluster scope, so record which machines the output includes. Compare visible drive letters, labels and sizes with the inventory, and reconcile unsupported or inaccessible storage separately.
Bash, on each Linux server:
findmnt --real
lsblk
findmnt --real lists mounted filesystems within its real-filesystem filter; it intentionally excludes pseudo filesystems and does not inventory every data source. lsblk lists available block devices, which is a different view and does not enumerate all network or application-managed storage. Use the two together as aids, recording the host, namespace, permissions and errors. The lsblk manual notes that root permissions are necessary in some configurations. An empty or clean result is not proof that all storage has been found.
Macs: open Time Machine settings and record the backup destination and the date of the latest backup for each Mac (our understanding of the current macOS interface; check on your version).
SaaS: list the services in use from your finance records and identity provider, not from memory, and confirm each has a row (our recommendation).
These checks find unrecorded volumes and services. They do not show what is inside each volume, whether a backup job actually includes it, or whether its restore works. Treat a clean comparison as partial assurance (our reading).
Safe restore rehearsal
The inventory's Last restore test column is only meaningful if the tests are real. Run them in an authorised, isolated environment, not on production systems (our recommendation).
- Pick a sample that covers every platform and every backup tool: at least one Windows, Linux, Mac, NAS and SaaS row each.
- Use synthetic or test data where you can. For rows where only real data exists, restore into an isolated environment with access limited to the people authorised to see that data.
- Before restoring, read the row. Confirm the restore dependencies (keys, passwords, licences, software) are available from where the inventory says they are, without using the production system.
- Restore and compare. Record SHA-256 hashes of sample files from the backup's own catalogue or a known baseline, and compare with the restored files.
- Test the application, not just the files, where the row is an application: does it start, and does it show the expected data?
- Write the result into the row: date, what was restored, what worked, what failed, and where the evidence is kept.
ISM-1810 and ISM-1515 refer to restoring to a common point in time. For data sets that depend on each other, such as an application and its database, restore them together in the rehearsal (our reading).
Diagnosing what you find
- Volume found by the checks but no row: a new disk or mount nobody recorded; data moved from another location; or a volume deliberately excluded without the exclusion being written down.
- Row says backed up, restore finds nothing: the path is excluded in the tool; the job is not running or not reaching that machine; the data was moved after the job was set up; or the job runs under an account that cannot read it. If the data was never captured, no restore will find it; the fix is a new backup that includes it.
- Files restore, application fails: missing configuration, licence, key or dependent service; version mismatch; or a related data set restored to a different point in time.
- Restore dependency missing: the key or password was stored only on the protected system; it was held by a person who has left; or it was never recorded.
Have a qualified person review each rehearsal plan, and take care that a test restore cannot write back to production locations.
Worked example (illustrative)
The following is invented. An architecture practice has a Windows file server, a Linux web server, eight Macs, a NAS and Microsoft 365. Three tools report green every morning.
Building the inventory takes two afternoons. Get-Volume on the file server shows a second data volume added for a scanning project, not in any backup job. findmnt --real on the Linux server shows the website's uploads on a separate filesystem excluded by the backup script. Two Macs have not completed a Time Machine backup in five weeks because staff now work from home. The NAS holds both the project archive and the Windows server's backups, so losing it would take both. Microsoft 365 has no row at all.
The business owner works through each gap: the scanning volume and uploads are added to jobs, the Macs get a network destination, a second copy of the Windows backups goes to separate storage, and a decision on Microsoft 365 is recorded with an owner and a date. The rehearsal the following month restores one row per platform and finds that the web server's database password was only on the server itself; it goes into the restore dependencies column and a secure store.
Risks and limits
- An inventory goes stale. Re-run the read-only checks on a schedule and whenever systems change (our recommendation).
- The inventory itself is sensitive: it says where every backup is and who can delete it. Protect it as you would the backups, and keep a copy that does not depend on the systems it describes (our recommendation).
- ISM-2152 calls for backup infrastructure to be "segregated from production environments" with "a separate authentication mechanism for administrative access". An inventory that records this does not create it.
- The NIST documents are for United States federal systems and date from 2010 and 2020; the ISM and Essential Eight are the Australian references.
- No command or restore in this guide was run in a lab. Test each step in an isolated environment first.
Sources
All accessed 14 November 2026.
- Australian Signals Directorate, Guidelines for system management (Information Security Manual, September 2026): https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/ism/cyber-security-guidelines/guidelines-for-system-management
- Australian Signals Directorate, Essential Eight maturity model (November 2023): https://www.cyber.gov.au/business-government/asds-cyber-security-frameworks/essential-eight/essential-eight-maturity-model
- NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (May 2010): https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-34r1.pdf
- NIST SP 800-209, Security Guidelines for Storage Infrastructure (October 2020): https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-209.pdf
- Microsoft Learn, Shared responsibility in the cloud: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
- Microsoft Services Agreement (Australia): https://www.microsoft.com/en-au/servicesagreement
- Apple Support, Back up your files with Time Machine on Mac: https://support.apple.com/guide/mac-help/back-up-your-mac-with-time-machine-mh35860/mac
- Microsoft Learn, Get-Volume: https://learn.microsoft.com/en-us/powershell/module/storage/get-volume
- findmnt(8) manual page: https://man7.org/linux/man-pages/man8/findmnt.8.html
- lsblk(8) manual page: https://man7.org/linux/man-pages/man8/lsblk.8.html
Related future topics
- Writing restore procedures that someone other than the author can follow
- Who should be able to delete a backup: mapping ISM backup access controls to a small team
- SaaS backup decisions: reading the provider's terms before choosing
This article was originally published on .