TIP: Map backup data to the /storage folder to prevent migration headaches and for security

[Tek4]

This is offered as a tip only. It is an issue I solved and wish to share.

The Original "Bad" Plan

My original folder mapping scheme didn't use the '/storage folder. Instead, I chose to map entire volumes by name, as follows:

-v /volume1:/volume1:ro
-v /volume2:/volume2:ro

This seemed easy. I use could easily choose the various backup target folders I want from /root/volume1 and /root/volume2.

The Problem Arises

I recently moved a large chunk of media content on my Synology from volume2 to volume1. I realized two problems with my existing regime. First, is security. By mapping entire volumes, I exposed all my files to the CrashPlan docker container. This isn't a huge issue, but it's not best practice.

The second issue is the change in path names which occurs when migrating data. When I moved my Media folder from volume2 to volume1, the CrashPlan target folder path /volume2/Media became /volume1/Media. Thus, I had concerns about CrashPlan deleting all the content in the newly missing volume2 path. This might mean having to re-upload everything in the new volume1 location from scratch!

To overcome this, I considered mapping my new Media folder to both volume1, and, a "phantom" volume2 that would exist only to preserve the former path name:

-v /volume1:/volume1:ro
-v /volume1/Media:/volume2/Media:ro

By doing this, I could set CrashPlan to recognize both the "old" volume2 path, as well as the "new" volume1 target. CrashPlan de-duplication will eventually harmonize the duplicate content. After become completely synchronized, I'd stop CrashPlan and remove the old "phantom" volume2. The process requires a couple days for the Synology and CrashPlan to slog through multiple terabytes of de-duplication.

The Light Comes On

I suddenly realized why the /storage folder is useful. First, it eliminates the security concern because you only map backup target folders instead of exposing the entire volume. Second, it allows you to hide (translate) the actual path to your backup target folders.

The Better Plan

I should have utilized the /storage folder the Docker container is designed with. Just map the specific folders you want to back up using a name that doesn't rely on the path to where the content is stored:

-v /volume2/Media:/storage/Media:ro

Had I done so, I could have easily stopped CrashPlan and quickly changed the Docker container to re-map /storage/Media to point to volume1:

-v /volume1/Media:/storage/Media:ro

Using this scheme, CrashPlan continues to see \storage\Media as the same backup target—even though the data has been moved—and I wouldn't have to suffer through the lengthy de-duplication process I am now going through.

Conclusion

I am now migrating all of my target folders from named volumes to the \storage folder. Presently, I have duplicate mappings to preserve existing paths and create the new path:

-v /volume1/Media:/volume2/Media:ro
-v /volume1/Media:/storage/Media:ro

I had to select the new path in CrashPlan (under "Manage Files") and let it synchronize alongside the old path. When de-duplication completes, I will have to de-select (i.e., delete) the former volume2 path in CrashPlan. Then I will have to re-create the container with just the single new folder mapping:

-v /volume1/Media:/storage/Media:ro

Live and learn.

[RichSteele]

Thank you so much for this! Going a bit bonkers trying to figure out why CrashPlan wasn't showing any of the contents of my new volume. I'm just a bit daft these days.

Also, appreciate the idea of mounting just what you want backed up--a little more maintenance as I add more shared folders but far safer and more manageable in the CrashPlan UI.