> For the complete documentation index, see [llms.txt](https://documentation.dnanexus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.dnanexus.com/faqs/backups-of-customer-data.md).

# Backups of Customer Data

For customer data, such as data files, customer-specific apps, and pipelines, DNAnexus relies on the high durability of the underlying cloud storage to protect against infrastructure-level failures, such as disk corruption. This durability is achieved through replication of the data.

In projects with [data retention](/user/objects/data-retention.md) enabled, deleted data objects remain recoverable from the project's recycle bin until their retention period ends. After an object is permanently deleted, DNAnexus cannot recover it. Customers are responsible for maintaining backups for data not covered by data retention and for recovery needs beyond the retention period, including disaster recovery.

Identify the data that must be backed up. That scope is probably not everything in your directory. Set the backup scope to include data files from your sequencer, final analysis results, any applications you added to the platform and configured on the platform, and your pipelines. You can decide whether the intermediate results of your pipeline can be reproduced and therefore probably do not need to be backed up. Files shared with you may or may not be in scope (if you have the rights to make copies of these files).

The Platform provides at least four ways to backup your files in scope:

1. Make a deep copy (new objectID) of the objects you want to back up into a new "backup" project, and make sure it is not accessible to anyone who can accidentally delete them. Remove access for all users other than the project owner from this "backup" project. You might consider putting the data in a separate org. Archive these items. Archiving "moves" the files from the working directory into the archive. To test the integrity of the data archived, you unarchive and run your tests to prove your backup works. While the archive is in the same cloud region, it is probably not in the same physical location as the primary storage tier. This is the simplest and least expensive option. Make sure to use a deep copy (new objectID) and not a shallow copy (same objectID), as the latter is merely a pointer and not a physically separate object.
2. Make full replicas of the files in scope to another cloud within your license. You can copy from AWS-Frankfurt to Azure-Amsterdam, for instance. On AWS and Azure, you pay egress charges, from the source. If you are concerned about the storage charges on the destination location, then you can archive these files in the destination location. Make sure you have the "archive" license from DNAnexus. If you're not sure whether you have this license, [contact DNAnexus Sales](mailto:sales@dnanexus.com).
3. Download the files and store them outside the DNAnexus account. Unlike the two options above, the security and traceability of the copied files become the responsibility of the customer. This option may be a requirement of your institution.
4. Treat all files on DNAnexus as work products and keep a "gold" copy locally and download pipelines and output files of runs on the DNAnexus Platform.

All approaches involving making a deep copy of an object, where a new object is created, make provenance tracking a challenge. The initial record of a copied file references the job that creates it, but the reviewer needs to review the job log to understand and provide a linkage. Solutions include adding metadata in the target file that points back to the source.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://documentation.dnanexus.com/faqs/backups-of-customer-data.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.