Storage, Backing Up & Restoring in ProGet
Storage, Backing Up & Restoring in ProGet
Protecting package data, build artifacts, and compliance information is an important part of maintaining a reliable package management environment.
Both Sonatype Nexus Repository and ProGet support backup and recovery workflows, but they differ in how package data and metadata are stored and managed.
This article covers:
Storage Architecture in Sonatype and ProGet
Sonatype Nexus Repository uses a blob-based storage model. Package files and components are stored as binary large objects (blobs), while repository metadata, configuration data, and repository structure are maintained separately within a database.
Because blob files are stored using generated internal identifiers, the underlying storage structure is not intended to be human-readable or directly navigable outside the platform itself. The associated metadata database is required to interpret and reconstruct repository contents.
Package Storage in ProGet
ProGet uses a file-based storage model designed to keep package data transparent and accessible.
Metadata and configuration data are stored within a PostgreSQL database, while package files can be stored on:
- local storage
- network-attached storage
- cloud storage providers such as Amazon Web Services S3, Google Cloud Storage, or Microsoft Storage
Package files retain readable names and directory structures, making it easier to identify, verify, and recover package data outside the platform when needed.
For example, a package such as:
Newtonsoft.Json.13.0.3.nupkg
remains directly identifiable within storage.
Backup and Restore Workflows
In Sonatype Nexus Repository, backup operations require coordinated backups of both:
- blob storage
- repository metadata databases
Because blob storage relies on metadata to reconstruct repository contents, both components must remain synchronized during backup and recovery operations.
ProGet follows a similar operational model and typically requires backups of:
- configuration files
- PostgreSQL databases
- package storage locations
The primary difference is that ProGet package files remain directly readable and accessible within storage, simplifying validation and recovery workflows.
Restoring a ProGet Environment
Restoring ProGet involves restoring:
- configuration files
- database contents
- package storage
Once restored, package data can be verified directly through the underlying storage structure because packages retain their original names and organization.
This approach helps simplify operational validation and recovery workflows while maintaining compatibility with standard backup strategies used in repository management environments.
Conclusion
Both Sonatype Nexus Repository and ProGet support reliable backup and recovery workflows for package management environments.
While the overall operational process remains similar, ProGet uses a more transparent storage structure that keeps package data directly readable and accessible outside the platform.
To help manage package growth and long-term storage usage after backup and recovery workflows are established, the next article covers retention policies for packages, builds, and related package management data.