Skip to content

Backup and Recovery

View as Markdown

Two mistakes are common: replacing a file and deleting it. CloudRepo guards against the first in a Maven, Python or npm repository that holds your own files, with Overwrite Protection, and gives you a way back from the second in a Maven or Python repository that holds your own files, with the Trash. For anything else, keep your own copy of what you cannot rebuild.

Replacing a file

Section titled “Replacing a file”

Overwrite Protection is on by default for a Maven, Python or npm repository that holds your own files. A publish that would replace a file already stored at the same path is refused with 409 Conflict, and the file in the repository is left as it is.

On a Maven repository two kinds of file are not protected, because Maven rewrites them on every publish: a file in a -SNAPSHOT version directory, and maven-metadata.xml with its checksum and signature files. A publish that replaces one of those is accepted. See Maven: SNAPSHOT and Metadata Are Exempt.

Overwrite Protection is a setting of each repository. On a repository where it is off, a replacement is accepted. A file that was replaced, in either case, is not listed in the Trash, because the Trash lists files that were deleted.

Deleting a file

Section titled “Deleting a file”

In a Maven or Python repository that holds your own files, a file or folder you delete is listed in the repository’s Trash tab. See Trash and Recovery. The tab carries its own notice about how long deleted items stay: read it before you rely on the Trash. An npm or Docker repository has no Trash tab, so for one of those your own copy is the way back.

Only someone with the Manage Repositories permission can see what the Trash holds and restore from it (see User Management). Deleting a file needs only write access, so a member who can delete a file may be unable to restore it: ask someone who has the permission. A proxy repository refuses a restore.

In the portal, deleting a folder, deleting several items at once and purging from the Trash ask you to confirm your identity. A repository token cannot run any of them.

If the file is not in the Trash

Section titled “If the file is not in the Trash”

Write to support with what you can tell us: the organization, the repository, the path, roughly when the file was last there and whether it was deleted or replaced. See Support for what to include. We can look into it, but this page does not promise a recovery. A restore from the Trash, by someone who can manage repositories, and your own copy are the ways back you can count on.

Keep your own copy

Section titled “Keep your own copy”

Keep a copy of anything you cannot rebuild from source: a release you published once and every build now depends on, a file nothing generates. Two ways:

  • Copy at publish time. Have the job that publishes also store the same files in your CI platform’s artifact storage, or in storage of your own.
  • Download later. Keep a list of the paths you want, one per line, relative to the repository. The path of a Maven file is its group (dots become slashes), its name, its version and the file name. Then download each one. The loop reads your credential from ~/.netrc (see Maven Repositories), so no token is in the script or on a command line:
Terminal
while IFS= read -r path; do
  curl --netrc --fail --silent --show-error --create-dirs \
    --output "backup/$path" \
    "https://your-org.mycloudrepo.io/repositories/your-repo/$path"
done < paths.txt

--create-dirs makes the folders under backup/ that each path needs. Run it from a job on a schedule you choose.

A copy you have never restored is a guess. Now and then, publish a copy into a scratch repository and build from it.

Where CloudRepo hosts your data

Section titled “Where CloudRepo hosts your data”

How CloudRepo stores and protects your data, and how it recovers from failures, is described on CloudRepo’s security practices page.

For whether CloudRepo is having a problem right now, see status.cloudrepo.io.

Next steps

Section titled “Next steps”