CLARIFICATION: Backup strategy?

Hello.

I’m evaluating Photostructure, and trying to understand automatic library organisation.

For backup, I need after organisation to end up with a single hierarchical directory containing all of my de-duplicated photos. (On my Synology, I have a task that runs nightly to backup the photos directly to an external hard drive).

I can’t understand the user guide (PhotoStructure | Automatic library organization) on this point. If I’m reading this correctly, what I’ll end up with is path dependent: if I select it at the start, my photos will be in a directory maintained by Photostructure; but if I don’t, my photos (including possible duplicates) will be scattered throughout my file system.

I’m evaluting this in free mode, so haven’t been able to select automatic library organisation. As far as I can tell, this means that all the files I’ve processed so far will remain where they are and not get copied into the library directory hierarchy.

Have I misread this? Is there the facility after creating the library to consolidate all managed photos into a single directory, from which backups can be made? If not, how does creating yet another pile of photos contribute to the problem of keeping track of piles of duplicated photos everywhere, and how do photostructure users back up their “master” list?

Many thanks.

Howdy, and welcome the PhotoStructure, @richardjlyon!

My users seem to come from two camps:

  1. They’ve already got their files pretty much entered they want them (and auto organization isn’t a feature they need), or

  2. They’re like me, and have tons of old HDDs filled with backups or main partitions of old servers.

PhotoStructure doesn’t (currently) move files during automatic organization:

I was mostly concerned of the scenario where a user messes up a bind mount for their originals directory within docker, such that those files are only temporarily saved with the container. If I moved files instead of copying, this would result in PhotoStructure effectively deleting the source files during automatic organization because container contents are destroyed when the container image is updated. As far as I know, there isn’t a way to detect this issue (but if anyone knows a solution to this, please share!)

There is a feature request to enable copy-or-move behavior specific to a directory, which I think may be a reasonable solution, as it is evidence that the user read through the documentation at least enough to set up that configuration, but it is months out before I can get to that feature.

Just to explicitly connect the dots, users in camp 1 just back up their already organized photos. Users in camp 2 use the auto-organization feature, and they can back up the auto-organized folder.

I don’t suspect there are many users with their photos in multiple locations that are not using auto-organization.