Lordess

Obviously it's his homework.

One can do that with OneDrive too. Incidentally I also have Dropbox and would intend to include it into the same workflow.

You are still relying on only one provider though.

Better to have data in several different locations with different providers.

How about something that can generate file hashes and then compare them later? You would have to research how to get a hash from a file, how to store those, how to align the files later and compare. You could then extend and improve it i.e. by adding multi threading.

Ah ok, so does it create some kind of hash the first time and then all subsequent passes compare against this?

Just curious as to what you use for this integrity check? If an error were found then is there not any parity information present to attempt to correct it? I do agree with you.

Yes very much so. Google Photos allows full uncompressed if chosen as an option. With Amazon Photos so long as one has Prime they allow unlimited RAW storage - full resolution and with OneDrive it is full resolution as well. Just to be clear on my current setup, my NAS is backed up to multiple cloud providers anyway. I wanted to layer this in as well since I have all three platforms available to me, why not make use of them. I would also really like to be backing up the shots I take in real time since I have lost data this way in the past. I can sync my NAS to OneDrive and Amazon Photos but if I enable phone sync then once I offload those photos and order them in my central directory structure on my NAS they will also upload again thus duplicating the photo as it were in the timeline/frontend view of whatever platform. Currently about 100GB. To add an irritation, some are not mine but I am charged with their curation.

It is good to know that you follow that sort of structure too. I've recently been having some reflection on this. I too keep a local drive with a backup of all of my data, critical and not critical. I also keep multiple cloud based backups for just the critical data. The issue is that local HDDs are not generally going to be bit rot protected. It worried me quite a bit because this premis basically suggests all non Btrfs/ZFS protected storage is non viable. Personally I would only use the local HDD to recover the non critical data and defer to online storage for the rest. Just something to think about. I wondered if anyone might have some insight as to a workflow for some of the online photo platforms. I made a separate topic about that here.

I'm at a bit of a loss with this and wondered if anyone might have some suggestions for a workflow. There's Google Photos, Amazon Photos and OneDrive. I have a NAS full of photos and videos and want to back them up on these platforms. I also want to be able to back up the photos I take with my phone in real time (incase the phone gets trashed before I can offload them). Enabling this will create duplicates on all of these platforms that then show up in the timeline view. Am I missing something, is there a better workflow?

By way of a update I consider the research concluded. I asked the question in a number of different places and the consensus was the three tier system separated by media type at the root level: Pictures|Videos->YYYY->YYYY-MM-DD Event->Media Files

Yes I should have been more specific about that. Photos and Videos would be two distinct root directories as you have it. I think it would be ill contrived to combine these types together. Two videos I found useful as reference points where:

I have a mess of digital media to sort out, photos and videos, and I want a robust system to move forward with. I've been doing some research and want to offer up what I've found so far for discussion. Three Tier Format YYYY->YYYY-MM-DD Event->Photos Example 2020 2020-01-04 Sleepover Evening at In Laws Photos 2020-01-05 Sleepover Morning at In Laws Photos 2020-01-05 Walk to the Park Photos 2020-01-05 Dinner at In Laws Photos Comments Flattest, most denormalized methodology Feels like year directories could get very bloated Special events i.e. holidays, that span monthly boundaries would be visually contiguous Complex day events could have further sub directories: Those with many sources such as other people and camera types Events that are long like graduations may be divided into sections Four Tier Variant One Format YYYY->YYYY-MM->YYYY-MM-DD Event->Photos Example 2020 2020-01 2020-01-04 Sleepover Evening at In Laws Photos 2020-01-05 Sleepover Morning at In Laws Photos 2020-01-05 Walk to the Park Photos 2020-01-05 Dinner at In Laws Photos Other Variant Formats YYYY->MM->DD Event->Photos YYYY->MM Name->DD Event->Photos Comments Breaks things down further by month under the year level More nested than Three Tier methodology Holiday events that span month boundaries would be broken up by month so not visually contiguous Same rules possible for complex events and multiple sources as Three Tier Five Tier Format YYYY->YYYY-MM->YYYY-MM-DD->YYYY-MM-DD Event->Photos Example 2020 2020-01 2020-01-04 2020-01-04 Sleepover Evening at In Laws Photos 2020-01-05 2020-01-05 Sleepover Morning at In Laws Photos 2020-01-05 Walk to the Park Photos 2020-01-05 Dinner at In Laws Photos Comments Plus, all the naming variants as in Four Tier Deep nesting Could potentially have one or two directories in days These could contain many or few photos Same rules possible for complex events and multiple sources as Three Tier General Comments With the Three Tier methodology the concern of ‘keys’ is not there because everything is flat under the year directory. > Three tiers then we might start thinking in terms of a relational database i.e. primary and secondary keys: YYYY is a primary key [PK] at level one but is a foreign key at level two and so on YYYY[FK]-MM[PK] YYYY[FK]-MM[FK]-DD[PK] Do we even want such a bloated naming convention with more than three tiers? It might be unwieldy to deal with anything beyond four tiers, we are humans and not computers after all It is undesirable to rely on additional software such as Lightroom The system must be as future proof as possible It should be intuitive for all that may encounter it – this will be handed down and added to through the generations Metadata is nice but it should be an independent concern that can be dealt with later/separately I would greatly appreciate your thoughts and input.