"How many copies do you have?" is one of the first questions any digital preservation program has to answer, and one of the hardest to answer precisely. The word "copy" is used loosely across the field, sometimes interchangeably with "backup," "replica," or "instance," even though these terms describe meaningfully different things in terms of risk. A system with three backups is not the same as a system with three copies, and confusing the two can leave an organization with a false sense of security about how well its content is actually protected.
This distinction is not just semantic. The NDSA Levels of Digital Preservation build entire tiers of practice on the concept of "complete copies" in separate locations, and the Digital Preservation Storage Criteria Usage Guide's treatment of independence across copies gives the underlying logic for why location and completeness alone are not sufficient. Getting the vocabulary right is a prerequisite for using either framework correctly.
Why is independence the operative concept?
The Digital Preservation Storage Criteria Usage Guide frames the core problem this way: preservation storage risk management depends on ensuring that no single event, agent, or technology can cause irreparable loss. The guide groups the ways copies can fail to be independent into three categories: organizational, geographical, and technical, as summarized in Figure 1. Organizational independence covers risks like a bad management decision, a coding error, an operator mistake, an insolvent vendor, or reliance on a single service provider for multiple "copies." Geographical independence covers distance, natural disaster exposure, proximity to targets, and geopolitical risk. Technical independence covers the media, hardware platform, hardware supplier, operating system, and software stack.
The NDSA Levels of Digital Preservation translate this into a practical progression. Level 1 asks for two complete copies in separate locations. Level 2 raises that to three complete copies with at least one in a separate geographic location. Level 3 asks for a copy in a location with a different disaster threat and a copy on a different media type. Level 4 asks for three copies in separate locations, each with a different disaster threat, and a diversified set of storage solutions to avoid single points of failure.
Two words in that progression do a lot of work: "complete" and "separate." A copy has to be a full, independently verifiable instantiation of the object, not a partial or dependent one. With that grounding, the rest of the vocabulary sorts itself out more easily.
Copy
A copy is a complete, independently managed manifestation of a digital object that sits in its own risk environment. It is not linked to any other copy in a way that would let an event affecting one copy also corrupt or overwrite another. This rules out unmanaged duplicates scattered across a drive, which may be complete but are not actively managed, monitored, or protected against overwriting. A copy should be verifiable on its own terms, typically through independent fixity checking, and its loss should not cascade to any other copy.
Whether a given copy actually counts toward the independence required by the NDSA Levels depends on its alignment with the organizational, geographic, and technical criteria above. A second copy stored with the same vendor on the same underlying infrastructure is not independent as the framework intends, even if it sits in a different building.
Backup
A backup is not an independent copy. It is a redundancy mechanism tied to a specific copy, such as a snapshot, a RAID array, or a replication job that keeps a copy's storage system resilient against a technical failure. Backups typically live within the same administrative domain as the copy they protect, often the same facility, the same storage system, or the same operator, and they are frequently subject to the same organizational and technical risks. They also tend to have a limited retention window, rotating or expiring on a schedule suited to operational recovery rather than long-term preservation.
Backups matter. They reduce the odds that a single technical fault destroys a copy before anyone notices. But they should not be counted as separate copies in a preservation storage inventory, because the criteria that make a copy independent (a different organization, a different location, a different technology stack) are usually exactly what a backup lacks relative to the copy it protects.
Version
A version is not a copy at all. It is a distinct object that represents an intentional change to content, whether that is a new edit, a migrated format, or a revised structure. Because it is a different object, a version needs its own set of copies to meet the same preservation criteria as everything else in a repository. Treating versions as interchangeable with copies is a common source of confusion: an organization might believe it has three copies of an object when it actually has three different versions, none of which is independently protected to the degree the others are.
The practical test is whether the content itself has changed. If it has, the object is a version and requires its own preservation plan if it’s your policy to retain multiple versions. If nothing has changed except the storage location or technology, the object is still the same version; what has changed is how many independent copies of it exist.
Replica
Replica is a genuinely imprecise term in this context, and that is worth naming directly. It is sometimes used as a plain synonym for copy, and sometimes used in a storage or database engineering sense to describe redundancy that a system manages automatically, such as cross-region replication offered by a cloud storage provider. That kind of replication can satisfy geographic independence while still failing organizational independence, since every replica remains dependent on the same single provider. That is precisely the non-diversification risk the Digital Preservation Storage Criteria Usage Guide calls out: copies managed by the same service provider share a fate if that provider makes a critical error or exits the market.
Replica is a useful word for describing a technical mechanism. It is not a reliable word for counting preservation copies without first checking what kind of independence, if any, that replication mechanism actually provides.
Instance and instantiation
This is the term most worth being careful with, because it gets used in at least two ways that pull in opposite directions.
In computing generally, an instance is a specific, deployed occurrence of something: a running server, a container, a database. That everyday sense does not carry any built-in implication of independence. An instance is often one of several occurrences managed by the same system, orchestration layer, or provider, which is closer to the opposite of independence. A second instance spun up in the same cloud account, under the same account credentials and the same platform, is not automatically an independent copy just because it is a separate instance.
In a preservation context, "instantiation" can also refer to a specific technical realization of content, distinct from the abstract idea of the object itself. This sense is closer to representation than to redundancy: a document instantiated as a PDF and instantiated as a TIFF-plus-metadata bundle are two representations of related content, not two independent copies of the same bitstream.
Given that ambiguity, it is worth using instance and instantiation narrowly and explicitly, rather than as general synonyms for copy. If the intended meaning is "a deployed occurrence of a storage system or service," say that, and then run it through the same independence checklist applied to any other candidate copy. If the intended meaning is "a particular representation or rendering of the content," that is a question about format and representation, not about redundancy, and it should not be folded into a copy count at all.
Putting it together
Figure 2 lays the five terms side by side against the questions that actually matter: whether each one is a distinct object, whether it sits in its own risk environment, and whether it counts toward an NDSA copy count.
Copy, backup, version, replica, and instance describe different relationships to risk, not different flavors of the same thing. A copy counts toward the independence targets in frameworks such as the NDSA Levels. A backup supports a copy but does not add to that count. A version is a different object entirely, requiring its own copies. A replica may or may not be independent, depending on the mechanism behind it. An instance, in the sense relevant to storage, is a candidate copy that still has to pass the same organizational, geographic, and technical independence test as everything else, and in the sense relevant to content, is not about copies at all.
None of this vocabulary is fixed by a single authoritative standard, and organizations will reasonably use these words somewhat differently depending on their systems and history. What matters is being explicit, internally, about which of these relationships a given piece of storage actually has to the objects it holds, and checking that against the independence criteria before counting it toward a preservation target.