Google Photos isn't 'safe' or versatile enough to be a good location for your master copy. It works better as a convienient photo browser with some backup and sharing features. There is a rclone backend for Google Photos but it has a few limitations due to the api. Theoretically you can use this to mount Google Photos locally but there are a few restrictions.

Personally, I think that using any of these services as your master is a mistake. But I realize it's what many consumers do. (And, to be fair, it probably is safer for most people than storing one copy on a spinning disk drive was. Which is also what many consumers did.)

Just a simple google search on terms "github google takeout photos" gives a link to a script https://github.com/TheLastGimbus/GooglePhotosTakeoutHelper plenty of other projects to use or get an idea for your own. Even if you are not a programmer writing a python script is not hard.

The backblaze part you can automate with rclone or 10's of other commercial software or any from this page https://www.backblaze.com/b2/integrations.html

Thanks. I've done all of that and is what I'm trying to avoid.

The organization and data which is in that takeout is a complete mess of years of design changes from picasa -> photos, empty folders, duplicate date folders, hidden old crap from your Google+ account (like banner pics) which you can't see anymore to delete, just stuff everywhere inside those zip files. $0.02 if you ever have to actually deal with them, add time to first normalize what you unzip.

In all fairness, organizing old photos in general (especially scanned in pre-digital ones) is pretty much a horrid task in most cases. I'm dealing with it right now and stuff is linked to all over my hard drive, dupes in different formats at different levels of quality, limited metadata, etc. New stuff suffers from there being just so much of it--much of it repetitive--but at least it's in some semblance of order.

Afew years ago, I ran all my family photos through a script that renamed them based on the year, month, and date. I may have retained the old name in the metadata.

I'm looking for the script I used. I also have some tools that compare hashes and find duplicates.

You can google that stuff, or if you want to hire me to help, PM me.

I sorted stuff by ages and, very roughly, by content ages ago. So it's not horrible. By biggest issue is that when I first started using Lightroom I didn't really have a good orderly ingestion workflow so there's a duplication of raw scans, PSDs, JPGs, different versions of edits, etc. It's hard to automate and what to save and what to toss from the catalog is somewhat a matter of judgement.

>I ran all my family photos through a script that renamed them based on the year, month, and date.

I actually don't care about the filename, although maybe once things are cleaned up I'll do an export of everything. It's all in a Lightroom catalog now. It's "just" a matter of adding more primarily location-based metadata and making sure everything I especially care about is in appropriate Collections.

Years ago when Flickr made a big change and I needed to extract my original uploaded content (almost same exact scenario as this thread), I found this script as a starting point (it uses jhead): http://neverfear.org/blog/view/148/Rename_all_jpeg_files_by_...

For me, Flickr has always just been about copies of local files. At some point though, I do need to look at what all I've uploaded there. At one point, my Lightroom database got corrupted. I was able to recover it but I lost the local service mirror of what I had uploaded. (And a fair bit of stuff pre-dated using Flickr in any case.)

I discovered ratarmount the other day (pip3 install ratarmount), which fuse-mounts tgz. Fancier, you can glob all your Takeouts into a single merged directory (ratarmount *.tgz ~/takeout). Even fancier, PhotoStructure will then read and de-dupe that directory hierarchy. I just added person and album metadata parsers (those will be in the next release), which were the last bits that we're missing.

zip files suck for jpg, it's already compressed. If you're storing raw formats, it might help some.

I agree but I use zip as a handy container format. Assuming I have 50 image files I use the -0 option for no compression. It runs a lot quicker and it is easier to send/upload/download 1 file than 50 individual files.

zip -r -0 file.zip dir

Google takeout delivers the results in an archive (.tgz, .zip, etc.) you grab via URL; it's just a delivery mechanism from Google to your hands for the data drop/transfer.

I use the google api and this, https://github.com/gilesknap/gphotos-sync

I backup everything to my local server.

I also do some side work, feel free to email me if you would like me to help you set this up, if you have a server, we can do it all remotely. p n u t@ (borowicz).org, remove spaces and ()

'rclone' is built into the rsync.net platform which means that you can do your google takeout and then directly back it up to your rsync.net account:

  ssh [email protected] rclone gdrive:/blah /rsync/account

No download/upload over your home connection and no intermediate transfer required.

There is special pricing for this kind of 'expert' account:

https://www.rsync.net/products/rclone.html

... and we are all very enthusiastic about supporting and documenting workflows like this so please come try this and show us how you want it to work.

... oh and now that I think about it, rclone connects directly to google photos so I think you can skip the google takeout and just:

  ssh [email protected] rclone gphotos:/what/ever /rsync/account

This sounds wonderful. I'll try the gphotos (or maybe both) route and write about my experince.

Thanks!

... to clarify, I made up that 'gphotos' alias in the command line - I have no idea what the actual alias is ... but it is all documented here:

https://rclone.org/googlephotos/

... and you can, indeed, rclone directly from google photos to your rsync.net account, etc.

I use Microsoft OneDrive to instantly upload my photos to the Camera Roll, and then I use a rclone daemon to move the images to 2 backup locations (after applying encryption).

I tried the way of uploading directly to my target backup locations from my phone using RCX (rclone for Android), but uploading camera roll at convenient times, automatic retry, and features like automatic albums and such are nice to have and hard to get in open-source software, so I stuck with OD.

rclone has a dedicated googlephotos source/sink module, so you can look into it.

I second rclone. It's rock-solid (at least until Google changes their Photos API), and should be fine to automate via cron: https://rclone.org/googlephotos/

plus one

OneDrive backup unfortunately is very buggy on iOS

Check this thread out:

https://www.reddit.com/r/selfhosted/comments/k5nzkj/google_p...