# Best Practices for Storing and Archiving Long-Read Sequencing Data: File Formats, Compression, and Long-Term Preservation

Long-read sequencing platforms generate data volumes that challenge conventional storage planning. A single PromethION flow cell can produce hundreds of gigabytes of raw signal data, while PacBio HiFi runs routinely generate terabyte-scale outputs. Without a deliberate storage and archiving strategy, core facilities and individual laboratories face uncontrolled costs, degraded data integrity, and workflows that become unreproducible. This article provides concrete guidance on file formats, compression approaches, checksum verification, metadata practices, and long-term preservation for long-read sequencing data, with specific attention to the distinct requirements of Oxford Nanopore Technologies and PacBio platforms.

## The Storage Problem in Long-Read Sequencing

Long-read sequencing differs from short-read approaches in ways that directly affect storage planning. The raw data from nanopore instruments includes electrical signal measurements that are basecalled into FASTQ files, and these signal files (FAST5 or POD5 format) are often retained for re-basecalling as algorithms improve. PacBio platforms produce raw polymerase reads that undergo circular consensus sequencing to generate HiFi reads, and both raw and processed data may be archived. The result is that a single project can have multiple data layers, each with different retention requirements and compression characteristics.

The scale of the problem is substantial. A typical human genome sequenced on a nanopore platform at high coverage can require several terabytes of raw signal data. When multiplied across a cohort study or a core facility serving multiple investigators, the storage demand grows quickly. Storage costs become a recurring operational expense instead of a one-time equipment purchase, and decisions made at project initiation have financial consequences for years.

The practical question for most laboratories is not whether to store data but what to store, in what format, and for how long. Different data types have different value profiles. Raw signal data may be essential for re-analysis with improved basecallers, but it is also the largest and most expensive data layer. Processed reads in FASTQ format are smaller but still substantial. Aligned data in BAM or CRAM format adds genomic coordinates and is the basis for most downstream analyses. Each layer has a role, and each requires a distinct preservation strategy.

## Core Principles for Sequencing Data Preservation

### Data Integrity Begins at Acquisition

Data integrity for long-read sequencing starts when the instrument writes its first file. The sequencing instrument or the associated compute node should generate checksums for every output file at the time of creation. A checksum is a mathematical digest of a file's contents, and any change to the file produces a different digest. The most common algorithms are MD5 and SHA-256, with SHA-256 preferred for archival purposes because it is less susceptible to collision attacks.

The practical workflow is straightforward. When a sequencing run completes, the basecalling pipeline produces FASTQ files and possibly signal files. The laboratory should compute checksums for these files immediately and record them in a manifest file that accompanies the data. This manifest becomes the reference against which all future integrity checks are measured. Without this initial checksum record, it is impossible to distinguish between a file that was corrupted during transfer and one that was corrupted at the source.

The [NCBI Data Resources](https://www.ncbi.nlm.nih.gov/) documentation describes how sequence data submitted to public repositories must include appropriate metadata and file validation, and the same principles apply to local storage. The discipline of recording checksums at acquisition is the foundation for all later integrity verification.

### The 3-2-1 Rule Applied to Sequencing Data

The classic data preservation rule states that you should maintain three copies of your data, on two different storage media, with one copy offsite. For sequencing data, this rule translates into a concrete operational plan. The primary working copy lives on high-performance storage attached to the analysis cluster. A second copy resides on a different storage system, ideally with different hardware characteristics. The third copy is stored offsite, either in a cloud object store or at a different physical location.

The 3-2-1 rule is not a suggestion but a minimum standard for data that cannot be regenerated. Sequencing data is unique in a way that most laboratory data is not. A failed PCR reaction can be repeated. A degraded protein sample can sometimes be re-purified. But a sequencing run that produces biologically important data cannot be repeated if the original sample is exhausted or the instrument is no longer available. The irreplaceable nature of sequencing data justifies the storage cost of multiple copies.

For long-read data specifically, the offsite copy should be planned at project initiation instead of after the data has accumulated. Uploading several terabytes to a cloud provider takes time and bandwidth, and the transfer should be scheduled as part of the data production workflow instead of treated as an afterthought.

### Storage Media Selection and Its Limitations

The choice of storage media affects both cost and data durability. Active storage on spinning disks or solid-state drives provides fast access but carries ongoing power and cooling costs. Tape storage offers lower cost per terabyte and good longevity but requires specialized hardware and slower retrieval times. Cloud object storage provides geographic redundancy but introduces egress fees when data is downloaded.

For long-read sequencing data, a tiered approach is usually most practical. Active projects keep data on fast local storage. Completed projects move to a lower-cost tier, either on local tape or in cloud cold storage. The archival copy, which may never be accessed again, goes to the lowest-cost tier that still provides integrity checking and redundancy.

The [EMBL-EBI Training](https://www.ebi.ac.uk/training) materials on data management emphasize that storage decisions should be made with the full data lifecycle in mind. A file that is archived today may need to be retrieved in five years, and the retrieval process should be tested before the data is needed. Many laboratories have discovered that their tape archive is unreadable because the tape drive is no longer supported or the archive software has been discontinued. Regular test retrievals are the only way to verify that the archive actually works.

## At a Glance: Data Layer Retention and Format Decisions

| Data Layer | Typical Format | Relative Size | Primary Retention Purpose | Recommended Archival Approach |
|---|---|---|---|---|
| Raw nanopore signal | FAST5 or POD5 | Largest (3 to 5 times FASTQ) | Re-basecalling with improved algorithms | Retain for defined period, migrate formats when obsolete |
| Processed reads | FASTQ | Large | Primary sequence data for analysis and re-analysis | Compress with gzip, retain as master copy |
| Aligned reads | BAM or CRAM | Medium to large | Variant calling, structural variant detection, transcript quantification | Use CRAM for archival when reference-based compression is effective |
| Analysis results | VCF, BED, TSV | Small | Reproducibility and reporting | Retain indefinitely with full metadata |

## File Formats for Long-Read Data

### FASTQ as the Universal Read Format

FASTQ is the standard text format for nucleotide sequence reads with quality scores. Each read is represented by four lines: a header line beginning with @, the sequence, a separator line beginning with +, and the quality string. For long-read data, FASTQ files can be very large because individual reads are thousands to hundreds of thousands of bases long.

The simplicity of FASTQ is both its strength and its weakness. The format is human-readable and universally supported by analysis tools. However, the text representation is inefficient. A nucleotide is stored as a single ASCII character, and quality scores are stored as ASCII characters that each represent a Phred score. The format does not include alignment information, so aligned data requires a separate file.

For long-read data, FASTQ files are typically the primary processed data product. The basecaller produces FASTQ output, and downstream analysis tools accept FASTQ as input. The [Galaxy Training Network](https://training.galaxyproject.org/) provides practical tutorials on working with FASTQ data, including quality assessment and filtering steps that are relevant to long-read analysis workflows.

### BAM for Aligned Data

The BAM format is the binary compressed version of the Sequence Alignment/Map (SAM) format. BAM files contain read sequences, quality scores, and alignment information including genomic coordinates, mapping quality, and alignment flags. The binary format is more compact than SAM text and supports random access through an associated index file.

For long-read data, BAM files serve several purposes. They are the standard input for variant calling, structural variant detection, and transcript quantification. They also provide a record of how reads were aligned to the reference genome, which is essential for reproducing downstream analyses. The [Bioconductor](https://bioconductor.org/) project provides R packages for working with BAM files, including functions for reading, filtering, and summarizing aligned reads.

The size of BAM files for long-read data depends on coverage and read length. A human genome at 30x coverage with PacBio HiFi reads produces a BAM file of roughly 50 to 100 gigabytes. Nanopore data at similar coverage is larger because the reads have higher error rates that require more complex alignment representations.

### CRAM as a Compression Alternative

CRAM is a reference-based compressed format for aligned sequence data. The format stores only the differences between each read and the reference genome, which dramatically reduces file size for data that aligns well to the reference. CRAM files require access to the reference sequence to be decompressed, so the reference version must be recorded in the file header and preserved alongside the data.

The compression ratio for CRAM depends on the divergence between the reads and the reference. For human data aligned to the human reference genome, CRAM files are typically 30 to 50 percent smaller than the equivalent BAM files. For highly divergent samples, such as bacterial isolates aligned to a distant reference, the compression benefit is smaller.

The tradeoff with CRAM is complexity. The format requires reference-aware tools for reading and writing, and some downstream analysis tools do not accept CRAM input directly. The [nf-core Documentation](https://nf-co.re/docs) describes how community pipelines handle CRAM files, including the requirement to specify the reference genome for decompression. Laboratories that adopt CRAM for archival storage should verify that their analysis pipelines can read CRAM input or plan to decompress to BAM before analysis.

### Signal Data Formats for Nanopore

Nanopore sequencing produces raw electrical signal data that is stored in FAST5 or POD5 format. These files contain the time-series measurements from the nanopore array, along with metadata about the sequencing run and the pore. The signal data is the input to basecalling, and retaining it allows re-basecalling with improved algorithms.

The decision to retain signal data is a significant storage commitment. Signal files are typically several times larger than the corresponding FASTQ files. A project that produces 500 gigabytes of FASTQ data may have 2 to 3 terabytes of raw signal data. The retention decision should be made with input from the bioinformatics team, who can assess whether re-basecalling is likely to provide meaningful improvements for the specific project.

The [NCBI Data Resources](https://www.ncbi.nlm.nih.gov/) accepts nanopore signal data in some submissions, and the [EMBL-EBI Training](https://www.ebi.ac.uk/training) materials describe the data formats accepted by European repositories. Laboratories planning to submit data to public repositories should check the current submission requirements before deciding which data layers to retain.

## Compression Strategies for Long-Read Data

### General-Purpose Compression

The simplest compression approach is to apply a general-purpose compressor such as gzip to FASTQ files. Gzip is universally supported, fast, and produces reasonable compression ratios for text data. A typical FASTQ file compresses to about 25 to 30 percent of its original size with gzip.

The limitation of gzip is that it treats the FASTQ file as generic text and does not exploit the structure of the data. The sequence lines contain only four characters (A, C, G, T, and occasionally N), while the quality lines contain a wider range of ASCII characters. A format-aware compressor can achieve better compression by handling these lines differently.

For long-read data, gzip compression is often sufficient for archival purposes. The compression ratio is predictable, the tools are reliable, and the compressed files can be read by any downstream tool that supports gzip. The [The Carpentries Lessons](https://carpentries.org/lessons) include practical instruction on using gzip and other compression tools from the command line, which is useful background for laboratory staff who manage sequencing data.

### Reference-Based Compression

For aligned data, reference-based compression through CRAM provides better compression than generic approaches. The CRAM format stores only the differences between reads and the reference, which is highly efficient for data that aligns well. The format also supports lossy compression of quality scores, which can further reduce file size at the cost of some information loss.

The decision to use lossy quality score compression should be made carefully. Quality scores are used by variant callers to assess the confidence of base calls, and degrading quality scores can affect downstream results. For archival purposes, lossless compression is generally preferred unless storage constraints are severe and the downstream analysis does not depend on fine-grained quality information.

The [nf-core Documentation](https://nf-co.re/docs) provides guidance on CRAM usage in production pipelines, including the recommendation to preserve the reference genome version used for alignment. This metadata is essential for decompressing CRAM files in the future.

### Specialized Compression Tools

Several specialized compression tools have been developed for sequencing data. These tools typically combine multiple strategies, such as separating sequence and quality lines, using reference-based compression, and applying entropy coding. Some tools achieve compression ratios that are significantly better than gzip for FASTQ data.

The tradeoff with specialized tools is compatibility and longevity. A compression tool that is not widely adopted may become unavailable or unsupported, making the data inaccessible. The [Bioconductor](https://bioconductor.org/) project and the [Galaxy Training Network](https://training.galaxyproject.org/) provide guidance on tools that are actively maintained and integrated into standard workflows.

For most laboratories, the practical recommendation is to use gzip for FASTQ archival and CRAM for aligned data archival. These formats are widely supported, well documented, and likely to remain readable for the foreseeable future. Specialized tools can be considered for specific use cases where storage savings are critical, but the risk of format obsolescence should be weighed against the cost savings.

## Metadata and Documentation for Archival Data

### Minimum Metadata Requirements

Archived sequencing data is only useful if it can be interpreted correctly in the future. The minimum metadata for a long-read sequencing dataset includes the sample identifier, the sequencing platform and instrument, the library preparation protocol, the basecalling software and version, the reference genome version, and the alignment software and parameters. This information should be recorded in a machine-readable format that accompanies the data files.

The [NCBI Data Resources](https://www.ncbi.nlm.nih.gov/) documentation describes the metadata standards for sequence submissions, and the same standards are useful for local archival. The metadata should be recorded at the time of data production, not reconstructed later. Laboratories that attempt to reconstruct metadata from laboratory notebooks or email correspondence often find that critical details are missing.

### File Naming Conventions

File names should be descriptive and consistent across projects. A recommended convention includes the project identifier, sample identifier, data type, and version. For example, a file name such as `PROJ001_SAMPLE003_FASTQ_v2.fastq.gz` conveys the project, sample, data type, and version. The file name should be unique within the archive and should not change over time.

The [The Carpentries Lessons](https://carpentries.org/lessons) emphasize the importance of consistent file naming and directory structure for reproducible research. A well-organized archive with clear naming conventions is easier to navigate and less likely to suffer from accidental file overwrites or deletions.

### Directory Structure and README Files

The archive should have a defined directory structure that separates raw data, processed data, analysis results, and documentation. A README file at the top level of each project directory should describe the contents, the data production workflow, and any known issues. The README should be written with the assumption that the reader has no prior knowledge of the project.

The [EMBL-EBI Training](https://www.ebi.ac.uk/training) materials on data management recommend that README files include the date of data production, the names of the personnel responsible, and the software versions used. This documentation is essential for reproducing the analysis and for troubleshooting problems that may arise years after the data was produced.

## Practical Implementation Steps

### Step 1: Define Retention Policies Before Data Production

Retention policies should be established before the first sequencing run, not after the data has accumulated. The policy should specify which data layers are retained, for how long, and in what storage tier. The policy should also specify who is responsible for data management and what happens to the data when the project ends or the principal investigator leaves the institution.

A typical retention policy for long-read data might specify that raw signal data is retained for one year, processed FASTQ data is retained for five years, and aligned BAM or CRAM data is retained indefinitely. The policy should be reviewed annually and updated as storage costs and project needs change.

### Step 2: Automate Checksum Generation and Verification

Checksum generation should be automated as part of the data production pipeline. The basecalling or alignment workflow should produce a manifest file that lists every output file and its checksum. This manifest is stored alongside the data and is used for all future integrity checks.

Periodic integrity verification should be scheduled, typically on a quarterly or annual basis. The verification process reads each file, computes its checksum, and compares it to the manifest. Files that fail verification are flagged for restoration from the backup copy. The [Galaxy Training Network](https://training.galaxyproject.org/) provides practical instruction on automating data management tasks, including checksum verification.

### Step 3: Test the Archive Retrieval Process

The archive is only useful if data can be retrieved when needed. Laboratories should perform test retrievals on a regular basis, selecting files from different storage tiers and verifying that they can be read and analyzed. The test retrieval should include decompression and, for CRAM files, alignment to the reference genome.

The [nf-core Documentation](https://nf-co.re/docs) describes how pipelines handle data retrieval and validation, and the same principles apply to manual retrieval processes. A test retrieval that fails indicates a problem with the archive that must be addressed before the data is actually needed.

### Step 4: Document the Archival Workflow

The archival workflow should be documented so that any member of the laboratory can execute it. The documentation should include the commands used for compression, checksum generation, and file transfer, as well as the storage locations and access credentials. The documentation should be version-controlled and updated whenever the workflow changes.

The [The Carpentries Lessons](https://carpentries.org/lessons) provide instruction on version control with Git, which is useful for managing documentation and workflow scripts. A version-controlled archival workflow is reproducible and auditable, which is important for laboratories that are subject to institutional or funding agency data management requirements.

## Records and Measurements for Archive Management

### Tracking Storage Utilization

Laboratories should track storage utilization by project, data type, and storage tier. This tracking provides the data needed to forecast storage costs and to identify projects that are consuming disproportionate resources. A simple spreadsheet or database can record the project identifier, data type, file count, total size, storage tier, and retention date.

The [NCBI Data Resources](https://www.ncbi.nlm.nih.gov/) provides tools for estimating submission sizes, and similar calculations are useful for local storage planning. The tracking data should be reviewed quarterly to identify trends and to adjust retention policies as needed.

### Monitoring Archive Integrity

Archive integrity should be monitored through regular checksum verification and through monitoring of storage hardware health. Storage systems that report SMART errors or other hardware failures should be investigated immediately, and data on failing drives should be migrated to healthy storage.

The [EMBL-EBI Training](https://www.ebi.ac.uk/training) materials on data management emphasize that data integrity is an ongoing process, not a one-time event. The monitoring process should be documented, and the results of integrity checks should be recorded for audit purposes.

### Recording Data Access and Usage

The archive should record when data is accessed and by whom. This access log serves several purposes. It provides a record of data usage for reporting to funding agencies, it helps identify data that is frequently accessed and may need to be moved to a faster storage tier, and it provides an audit trail in case of data misuse or security incidents.

The access log should include the date and time of access, the user identifier, the files accessed, and the purpose of the access. The [Bioconductor](https://bioconductor.org/) project provides tools for tracking data access in R-based workflows, and similar tools are available for other analysis environments.

## Common Failure Patterns in Sequencing Data Archives

### Silent Data Corruption

Silent data corruption occurs when a file is modified without any error being reported. This can happen due to bit rot on storage media, memory errors during data transfer, or software bugs that write incorrect data. The only defense against silent corruption is regular checksum verification, and laboratories that skip this step may discover corrupted data only when they attempt to use it.

The [NCBI Data Resources](https://www.ncbi.nlm.nih.gov/) documentation describes the validation processes used for submitted data, and the same rigor should be applied to local archives. A file that fails checksum verification should be restored from the backup copy, and the source of the corruption should be investigated.

### Format Obsolescence

File formats can become obsolete when the software that reads them is no longer available or supported. This is a particular risk for proprietary formats and for formats that are tied to specific software versions. The [EMBL-EBI Training](https://www.ebi.ac.uk/training) materials recommend using open, widely supported formats for archival data and migrating data to new formats when the old formats become obsolete.

For long-read data, the risk of format obsolescence is real. The FAST5 format used by Oxford Nanopore has been supplemented by POD5, and the older format may not be supported by future basecalling software. Laboratories that retain signal data should plan to migrate to the current format or to retain the software needed to read the old format.

### Incomplete Metadata

Archived data without adequate metadata is effectively lost. A FASTQ file with no information about the sample, the sequencing platform, or the basecalling parameters cannot be interpreted correctly. The [Galaxy Training Network](https://training.galaxyproject.org/) emphasizes the importance of metadata for reproducible analysis, and the same principle applies to archival data.

The most common metadata failure is recording information in a location that is not associated with the data. A laboratory notebook entry that describes the sequencing run is useless if the notebook is lost or if the connection between the notebook entry and the data files is not documented. Metadata should be stored in files that accompany the data, not in separate locations.

### Storage Media Failure

All storage media eventually fails. Hard drives have a finite lifespan, tape degrades over time, and even solid-state drives have limited write endurance. The [The Carpentries Lessons](https://carpentries.org/lessons) provide practical instruction on data backup and recovery, and the same principles apply to sequencing data archives.

The defense against media failure is redundancy. The 3-2-1 rule provides three copies of the data, and the copies should be on different media types so that a failure of one media type does not affect all copies. Regular integrity checks identify failing media before the data is lost.

## Quality Controls and Verification Protocols

### Establishing a Verification Schedule

A verification schedule should be established and documented as part of the archival workflow. The schedule should specify which files are verified, how often, and by whom. For active projects, verification may occur monthly. For completed projects in archival storage, quarterly or annual verification is typically sufficient.

The verification process should be automated where possible. Scripts can walk the directory structure, compute checksums for each file, and compare them to the manifest. The results of each verification run should be logged, and any failures should trigger an alert to the responsible personnel. The [Galaxy Training Network](https://training.galaxyproject.org/) provides practical instruction on automating data management tasks, including checksum verification.

### Validating File Integrity After Transfer

File transfers are a common source of data corruption. Whether data is moved between storage tiers, uploaded to a cloud provider, or transferred to a collaborator, the integrity of the transferred files should be validated after the transfer completes. The validation process compares the checksums of the source and destination files.

For large datasets, the transfer validation should be built into the transfer workflow. Many transfer tools support automatic checksum verification, and the [nf-core Documentation](https://nf-co.re/docs) describes how community pipelines handle data validation during transfer. Laboratories that use manual transfer methods should verify checksums as a separate step after each transfer.

### Documenting Quality Control Results

The results of all quality control checks should be documented and retained. This documentation provides evidence that the archive is being maintained properly, which is important for institutional compliance and for funding agency reporting. The documentation should include the date of each check, the files checked, the results, and any actions taken in response to failures.

The [EMBL-EBI Training](https://www.ebi.ac.uk/training) materials on data management recommend that quality control documentation be stored alongside the data it describes. This ensures that the documentation is available when the data is accessed and that it is not lost when personnel change.

## Limitations and Professional Escalation Criteria

### When to Seek Professional Help

Laboratories that lack dedicated bioinformatics support should seek professional help when planning a large-scale long-read sequencing project. The storage and archival requirements for a project that will produce tens of terabytes of data are substantially different from those for a small pilot project, and the planning should involve someone with experience in data management.

The [Bioconductor](https://bioconductor.org/) project and the [nf-core Documentation](https://nf-co.re/docs) provide resources for finding bioinformatics support and for learning about best practices. Professional help should also be sought when the laboratory is preparing to submit data to a public repository, as the submission requirements can be complex and the consequences of incorrect submission are significant.

### Escalation Criteria for Data Integrity Issues

Data integrity issues should be escalated to the laboratory director or the institutional data management office when they affect data that cannot be regenerated. A checksum failure on a file that has a backup copy is a routine issue that can be resolved by restoration. A checksum failure on the only copy of irreplaceable data is a serious incident that requires immediate attention.

The [NCBI Data Resources](https://www.ncbi.nlm.nih.gov/) provides guidance on data validation and quality control, and the same standards should be applied to local data. Laboratories that discover widespread data corruption should investigate the storage infrastructure and consider migrating to more reliable storage.

### Escalation Criteria for Storage Capacity

Storage capacity issues should be escalated before the storage system reaches full capacity. A storage system that is more than 80 percent full is at risk of performance degradation and may fail to accept new data. The laboratory should have a plan for adding capacity or for archiving data to a lower-cost tier before the system reaches capacity.

The [EMBL-EBI Training](https://www.ebi.ac.uk/training) materials on data management provide guidance on capacity planning and on the costs associated with different storage options. The escalation should include a review of retention policies to identify data that can be deleted or moved to a lower-cost tier.

## Long-Read Data Analysis Context and Storage Implications

### Structural Variant Detection and Data Retention

Long-read sequencing provides substantial advantages for structural variant detection because reads span repetitive regions and complex rearrangements that are difficult to resolve with short reads. The [Tandem Repeat Genotyping Tool (TRGT)](https://pubmed.ncbi.nlm.nih.gov/38168995) demonstrates how PacBio HiFi data can be used to profile tandem repeats across the genome, determine consensus sequences, and assess methylation levels. Tools like TRGT require access to aligned reads, which means the BAM or CRAM files must be retained for the analysis to be reproducible.

The storage implication is that structural variant analyses often require retaining aligned data for extended periods. The aligned data may need to be re-analyzed as new variant calling tools become available or as the reference genome is updated. Laboratories that plan structural variant studies should budget for the storage of aligned data and should document the alignment parameters and reference version in the metadata.

### Transcriptome Analysis and Signal Data Retention

Long-read RNA sequencing provides insights into transcript structure that are not available from short-read data. A large human long-read RNA-seq dataset using the Oxford Nanopore Technologies platform identified over 70,000 novel transcripts for annotated genes and characterized allele-specific expression and transcript structure events. The [study](https://pubmed.ncbi.nlm.nih.gov/35922509) highlights the resolution gained from long-read data for understanding transcript diversity and genetic regulatory effects.

For transcriptome studies, the retention of raw signal data may be particularly valuable because basecalling algorithms for RNA data continue to improve. Re-basecalling with updated algorithms can improve the accuracy of transcript structure determination and may reveal novel isoforms that were missed in the original analysis. Laboratories conducting long-read transcriptome studies should consider retaining signal data for a longer period than would be typical for DNA sequencing projects.

### Emerging Storage Technologies and Their Relevance

DNA-based data storage is an emerging technology that may eventually provide an alternative to conventional digital storage for archival purposes. Research has demonstrated that plasmid-based DNA data storage can maintain stability and integrity over extended periods, with [studies](https://pubmed.ncbi.nlm.nih.gov/30966073) showing that DNA stored at controlled conditions of -20 degrees Celsius retained functional and nucleotide integrity comparable to newly produced plasmid DNA. Other approaches have explored [cellulose paper as a storage medium](https://pubmed.ncbi.nlm.nih.gov/37263984) for DNA data, achieving high storage density through electrostatic adsorption.

More recent work has explored [xeno nucleic acid-circular single-stranded DNA hybrids](https://pubmed.ncbi.nlm.nih.gov/42341119) for robust data storage, demonstrating resistance to chemical and enzymatic degradation. These technologies are not yet practical for routine laboratory use, but they suggest that the storage landscape may change significantly in the coming years. Laboratories should monitor these developments but should not delay implementing conventional storage solutions while waiting for DNA-based storage to mature.

## Frequently Asked Questions

### What is the difference between FASTQ, BAM, and CRAM formats for long-read data?

FASTQ is a text format that stores read sequences and quality scores without alignment information. BAM is a binary format that stores aligned reads with genomic coordinates and mapping information. CRAM is a reference-based compressed format that stores only the differences between reads and the reference genome, making it smaller than BAM but requiring access to the reference for decompression. For long-read data, FASTQ is the primary processed data product, BAM is used for aligned data in analysis workflows, and CRAM is an archival format that reduces storage footprint.

### How long should raw nanopore signal data be retained?

The retention period for raw signal data depends on the likelihood that re-basecalling will improve the data and on the storage cost. Signal data is several times larger than the corresponding FASTQ data, and the retention decision should be made with input from the bioinformatics team. A common policy is to retain signal data for one year after the project is completed, which allows time for basecalling improvements to be evaluated. The [NCBI Data Resources](https://www.ncbi.nlm.nih.gov/) accepts some signal data formats for submission, and the [EMBL-EBI Training](https://www.ebi.ac.uk/training) materials describe the formats accepted by European repositories.

### What checksum algorithm should be used for long-read sequencing data?

SHA-256 is recommended for archival data because it is less susceptible to collision attacks than MD5 and is widely supported by storage and data management tools. The checksum should be computed at the time of file creation and recorded in a manifest file that accompanies the data. Regular integrity checks compare the current checksum to the recorded value to detect corruption.

### Is CRAM compression suitable for all long-read data?

CRAM compression is most effective for data that aligns well to a reference genome. For human data aligned to the human reference, CRAM provides significant size reduction compared to BAM. For highly divergent samples or for data aligned to a distant reference, the compression benefit is smaller. CRAM also requires reference-aware tools for reading and writing, and some downstream analysis tools do not accept CRAM input directly. Laboratories should verify that their analysis pipelines can handle CRAM before adopting it for archival storage.

### How should metadata be recorded for archived sequencing data?

Metadata should be recorded in machine-readable files that accompany the data, not in separate locations such as laboratory notebooks. The minimum metadata includes sample identifier, sequencing platform, library preparation protocol, basecalling software and version, reference genome version, and alignment parameters. The [NCBI Data Resources](https://www.ncbi.nlm.nih.gov/) documentation describes metadata standards for sequence submissions, and the same standards are useful for local archival.

### What is the 3-2-1 rule and how does it apply to sequencing data?

The 3-2-1 rule states that you should maintain three copies of your data, on two different storage media, with one copy offsite. For sequencing data, the primary working copy lives on high-performance storage, a second copy resides on a different storage system, and the third copy is stored offsite in a cloud object store or at a different physical location. The rule is a minimum standard for data that cannot be regenerated, and sequencing data is irreplaceable if the original sample is exhausted.

### How often should archive integrity be verified?

Archive integrity should be verified on a regular schedule, typically quarterly or annually. The verification process reads each file, computes its checksum, and compares it to the recorded value. Files that fail verification are restored from the backup copy. The [Galaxy Training Network](https://training.galaxyproject.org/) provides practical instruction on automating data management tasks, including checksum verification.

### What should be done when a checksum verification fails?

When a checksum verification fails, the file should be restored from the backup copy immediately. The source of the corruption should be investigated to determine whether it is an isolated incident or a systemic problem with the storage infrastructure. If the corrupted file is the only copy of irreplaceable data, the incident should be escalated to the laboratory director or the institutional data management office. The [The Carpentries Lessons](https://carpentries.org/lessons) provide practical instruction on data recovery and backup management.

## Related Bioinformatics Guides

- [Long-Read Sequencing for De Novo Assembly of Complex Genomes: Case Studies and Best Practices](/knowledge/bioinformatics/long-read-sequencing-for-de-novo-assembly-of-complex-genomes-case-studies-and-best-practices)
- [Long-Read Sequencing Cost and Market: What to Expect](/knowledge/bioinformatics/long-read-sequencing-cost-and-market-what-to-expect)
- [Long-Read Sequencing for Isoform Quantification: Challenges and Solutions](/knowledge/bioinformatics/long-read-sequencing-for-isoform-quantification-challenges-and-solutions)
- [Short-Read vs Long-Read Sequencing: Pros, Cons, and Selection Criteria](/knowledge/bioinformatics/short-read-vs-long-read-sequencing-pros-cons-and-selection-criteria)
- [Genomic Data Processing: From Raw Sequencing to Analysis-Ready Files](/knowledge/bioinformatics/genomic-data-processing-from-raw-sequencing-to-analysis-ready-files)

## References and Further Reading

- [NCBI Data Resources](https://www.ncbi.nlm.nih.gov/). National Center for Biotechnology Information.
- [EMBL-EBI Training](https://www.ebi.ac.uk/training). European Bioinformatics Institute.
- [Bioconductor](https://bioconductor.org/). Bioconductor Project.
- [Galaxy Training Network](https://training.galaxyproject.org/). Galaxy Project.
- [nf-core Documentation](https://nf-co.re/docs). nf-core.
- [The Carpentries Lessons](https://carpentries.org/lessons). The Carpentries.
- [Transcriptome variation in human tissues revealed by long-read sequencing.](https://pubmed.ncbi.nlm.nih.gov/35922509). Nature, 2022.
- [Long-stranded XNA-cssDNA hybrids for robust data storage.](https://pubmed.ncbi.nlm.nih.gov/42341119). Science advances, 2026.
- [Characterization and visualization of tandem repeats at genome scale.](https://pubmed.ncbi.nlm.nih.gov/38168995). Nature biotechnology, 2024.
- [Long-Term Stability and Integrity of Plasmid-Based DNA Data Storage.](https://pubmed.ncbi.nlm.nih.gov/30966073). Polymers, 2018.
- [Sustainable DNA Data Storage on Cellulose Paper.](https://pubmed.ncbi.nlm.nih.gov/37263984). Small methods, 2023.

> This article is educational and does not replace validated analysis plans, institutional policy, clinical interpretation, or specialist review.