Skip to content
Google Photos and Albums backup with Google Photos Library API
Python TSQL Other
Branch: master
Clone or download
gilesknap Merge:
  Stefano's work on filesystem checks
  fix windows dependencies
  remove redunant GPS scraping code

Undo black formatting for the moment to enable easy merge.
Latest commit de64c41 Oct 7, 2019
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
etc update to python3.6 readme Jul 11, 2019
gphotos Merge: Oct 7, 2019
test Merge remote-tracking branch 'origin/feature2' into feature Oct 7, 2019
.gitignore added vim temp files Oct 6, 2019
.travis.yml add docker versioning Sep 11, 2019
AUTHORS tidy up software distribution Feb 21, 2019
CONTRIBUTING.md Create CONTRIBUTING.md Oct 6, 2019
ChangeLog Fix setup.py and publisj to pypi Feb 20, 2019
Dockerfile Build docker from pip Aug 6, 2019
LICENSE First version Oct 3, 2015
MANIFEST.in tidy up software distribution Feb 21, 2019
Pipfile fix windows dependencies Oct 7, 2019
Pipfile.lock fix windows dependencies Oct 7, 2019
README.rst
__init__.py refactor into class files Aug 9, 2017
build-docker.sh
gphotos-sync Fix setup.py and publisj to pypi Feb 20, 2019
setup.py set create date on Windows Platform Sep 15, 2019

README.rst

Build Status Test coverage Codacy Badge pypi

Google Photos Sync

Introduction

For a very good description and detailed instructions see Logix's Article at Linux Uprising

Google Photos Sync downloads your Google Photos to the local file system. It will backup all the photos the user uploaded to Google Photos, but also the album information and additional Google Photos 'Creations' (animations, panoramas, movies, effects and collages).

This project uses the new Google Photos API see https://developers.google.com/photos/.

After doing a full sync you will have 2 directories off of the specified root:

  • photos - contains all photos and videos from your Google Photos Library organized into folders with the structure 'photos/YYYY/MM' where 'YYYY/MM' is the date the photo/video was taken. The filenames within a folder will be as per the original upload except that duplicate names will have a suffix ' (n)' where n is the duplicate number of the file (this matches the approach used in the official Google tool for Windows).
  • albums - contains a folder hierarchy representing the set of albums and shared albums in your library. All the files are symlinks to content in the photos folder. The folder names will be 'albums/YYYY/MM Original Album Name'.

In addition there will be further folders when using the --compare-folder option. The option is used to make a comparison of the contents of your library with a local folder such as a previous backup. The comparison does not require that the files are arranged in the same folders, it uses meta-data in the files such as create date and exif UID to match pairs of items. The additional folders after a comparison will be:

  • comparison a new folder off of the specified root containing the following:
  • missing_files - contains symlinks to the files in the comparison folder that were not found in the Google Photos Library. The folder structure is the same as that in the comparison folder. These are the files that you would upload to Google Photos via the Web interface to restore from backup.
  • extra_files - contains symlinks into to the files in photos folder which appear in the Library but not in the comparison folder. The folder structure is the same as the photos folder.
  • duplicates - contains symlinks to any duplicate files found in the comparison folder. This is a flat structure and the symlink filenames have a numeric prefix to make them unique and group the duplicates together.

NOTES:

  • the comparison code uses an external tool 'ffprobe'. It will run without it but will not be able to extract metadata from video files and revert to relying on Google Photos meta data and file modified date (this is a much less reliable way to match video files, but the results should be OK if the backup folder was originally created using gphotos-sync).
  • If you have shared albums and have clicked 'add to library' on items from others' libraries then you will have two copies of those items and they will show as duplicates too.

Known Issues

A few outstanding limitations of the Google API restrict what can be achieved. All these issues have been reported to Google and this project will be updated once they are resolved.

Install and configure

To install the latest published version from PyPi, simply:

pipenv install gphotos-sync

Or if you don't want to use pipenv, create a virtual environment and:

pip install gphotos-sync

(see https://packaging.python.org/guides/installing-using-pip-and-virtual-environments/ if you are not familiar with virtualenv)

To work from the source code, clone the git repository and use pipenv to create a virtual environment and run the code. (if you don't have pipenv, then I recommend getting it - but you can manually create a virtualenv and use 'python setup.py install' instead)

git clone https://github.com/gilesknap/gphotos-sync.git
cd gphotos-sync
pipenv install .
pipenv run gphotos-sync

In order to work, gphotos-sync first needs a valid client id linked to a project authorized to use the 'Photos Library API'. It is not provided in the distribution. Each client id is given a (large) limited number of free API calls to Google Services. If this distribution shared the client id, all users would share this resource limit. This is a little fiddly but only needs to be done once.

To do this:

Also note that for Windows you will need to enable symbolic links permission for the account that gphoto-sync will run under. See Enabling SymLinks on Windows.

How to use it

Once the script is configured, you are now ready to use it using the simple following command line:

cd <installed directory>
pipenv run gphotos-sync TARGET_DIRECTORY

Or, if you used virtualenv and pip instead of pipenv, activate the virtualenv and:

gphotos-sync TARGET_DIRECTORY

The first time, it will give you a link to an authorization page in order to authorize the client to access your Google Photos.

For a description of additional command line parameters type:

gphotos-sync --help

Running with docker

You can run the tool from the container using prebuilt Docker image. The container has 2 mount points:

  • /storage this is where your photos will be stored. You can mount single directory, or multiple subdirectories in case you want to backup multiple accounts
  • /config the directory that contains client_secret.json file

To run

docker run \
   -ti \
   --name gphotos-sync \
   -v /YOUR_LOCAL/PATH/TO_PHOTOS:/storage \
   -v /YOUR_LOCAL/PATH/TO_CONFIG:/config \
   gilesknap/gphotos-sync
  /storage

To remove the container (for instance if you want to run it on scheduled basis and do a cleanup):

docker rm -f $(docker ps --filter name=gphotos-sync -qa) 2> /dev/null

Appendix

Rescans

I have just experienced an issue with duplication of files when doing a rescan (--rescan or --flush-index). It looks like some items have changed in the library and this can result in the same file downloading twice. I would guess this has something to do with Google removing the Drive link to Photos.

UPDATE: I now know that this was caused by subtle changes in the metadata. It seems Google does not guarantee to deliver exactly the same files each time you scan the library (but to be fair, I think they are tuning things for the better).

The problem did cause some duplicate named files to be downloaded twice overwriting their duplicate peer. Note that no files were lost from the library (since gphotos is read-only) and it was possible to repair things by either:

  • using the local comparison feature of gphotos-sync against a prior backup
  • or downloading the library again from scratch

In summary, most people will not be affected by the issue I had unless they have very old photos with duplicate file names.

My detailed notes on the subject are here: giles notes

Google GPS Info update

UPDATE: the GPS scraping no longer works. I am investigating a couple of other avenues.

Google does not seem to be interested in fxing the issue of stripping location info from the EXIF info of images downloaded via their API (see https://issuetracker.google.com/issues/80379228#comment80). So I am investigating a workaround. See the option --get-locations. It uses Selenium to scrape the GPS info off of the Google Website (your google creds required I'm afraid) and insert them into the DB of synchronized files. It does not yet update the EXIF on the local files but this is a minor addition and I'll implement if there is interest.

Have a try and let me know what you think. Hurry, because Google is removing the ability to log in using automation soon!

You can’t perform that action at this time.