Backup sets provide granular control over how data is backed up, but each additional set adds configuration complexity, and several backup set behaviors depend on how the sets are structured. This article covers when additional backup sets are appropriate, what they do not accomplish, and what to determine before creating one.
For an explanation of what backup sets are and what each one controls, see Backup sets.
How backup sets relate to destinations
Understanding this behavior is necessary before planning a backup set configuration.
A device maintains one archive at each destination. Every backup set that uses a given destination backs up into that single archive. Backup sets are shown separately in the device's configuration, but their data is stored together at the destination.
This has several consequences, described in the sections below and in How exclusions and retention settings apply across backup sets.
Determine whether you need multiple backup sets
A single backup set is sufficient for most devices. Additional sets are appropriate when one of the following conditions applies:
Data must be sent to different destinations. For example, one set backs up working files to the CrashPlan cloud while another set backs up the same or different files to a local external drive. This is the primary reason to create additional sets.
Data requires different backup schedules or priority order. For example, working documents are backed up continuously at high priority, while a large and rarely changed folder is backed up at low priority so that it does not compete for bandwidth.
If neither condition applies, a single set with a well-defined file selection is simpler to manage and easier to troubleshoot.
If you do create multiple sets on one destination, most of their settings remain independent. The exceptions are file exclusions and version and retention settings, which are applied across every set using that destination. See How exclusions and retention settings apply across backup sets.
Common misunderstandings about backup sets
Additional backup sets do not create redundancy on the same destination
Adding a second backup set that contains the same data, and pointing it at a destination you are already using, does not create a second copy of that data. Both sets write into the same archive at that destination.
Redundancy is created by adding a destination, not by adding a backup set. To maintain a redundant copy of your data, configure a backup set that sends the data to a destination that is not already in use, such as a local external drive in addition to the CrashPlan cloud.
Backup sets are not an organizational or browsing tool
Creating separate sets to group files by category, such as a Documents set and a Pictures set that both back up to the same destination with the same settings, provides no benefit. The configuration is more complex to maintain, and the data is not separated at the destination.
To control which files are backed up, use the file selection and file exclusions within a single set.
You cannot restore an individual backup set
When you click Restore Files, you see every file the selected destination holds for the device, across all backup sets that back up to it. You cannot filter the restore menu by backup set.
If your reason for creating multiple sets is to be able to restore them separately, that approach will not produce the result you expect. You can still restore part of your data by selecting the files and folders you want in the restore menu, but there is no way to restore everything from one backup set as a single action.
Selecting the same data in more than one set
The same file or folder can be selected in more than one backup set. This is only useful when the sets back up to different destinations.
Two behaviors apply:
- Removing a file from one backup set does not remove it from other sets that also include it.
- Each destination holds an independent copy of the file, with its own version history.
The second point means that two destinations may hold different version histories of the same source file. If a file was backed up to one destination and later added to a set backing up to another destination, or the sets backing up the file use different frequency or version retention settings, different versions may be available based on the destination chosen when restoring.
Use descriptive backup set names
Backup set names are the simplest way of distinguishing one set from another. Names that identify the destination and purpose of the set, such as Working documents - cloud or Full system - external drive, prevent confusion when making configuration changes.
Do not overlap scheduled backup times
If you schedule multiple backup sets to run between specified times, ensure that the scheduled windows do not overlap. Overlapping schedules can degrade backup performance.
When schedules overlap, a higher-priority set repeatedly interrupts or supersedes the lower-priority set. Because higher-priority sets usually contain the more important files and run on more frequent schedules, repeated interruptions can result in lower-priority sets making little backup progress.
To set a schedule, change the Backup will run setting to Between specified times.
Plan before deleting
Removing a backup set permanently deletes its archived files from every destination, and deselecting files from a set permanently deletes those files from the archive. Neither action can be undone.
Before removing a set or changing a file selection:
- Identify which files in the set you must be able to restore.
- Add those files to a set you are retaining.
- Wait for that set to report Backup complete.
- Remove the original set.
Because CrashPlan uses data deduplication, moving files between sets that share a destination does not require re-uploading them.
For the full procedure, see Can't delete a backup set.