Yes — that’s exactly what Photos Backup Anywhere is designed to do.
The app creates file-system-level backups of each individual photo and video from your Photos library. Every asset is exported as a real file on disk (HEIC, JPEG, MOV, etc.), not a database blob or package, so you can browse, copy, verify, and back them up with standard tools.
In addition, the app keeps a small SQLite database alongside the files to track metadata (including edits, albums, and relationships like Live Photos), which allows accurate restores and verification while still giving you transparent, plain-files access to your media.
Yes — that’s exactly what it’s designed for. You can back up photos from one Photos library and later restore them into a different Photos library. The restore process recreates the items in the target library using the data stored in the backup.
Yes — Photos Backup Anywhere supports Apple Family Sharing
If the app is shared via Family Sharing, each family member can install and use it on their own Mac with their own iCloud Photos library. The app works with whichever Photos library is signed into macOS on that machine, so you can absolutely use it to back up your partner’s images as well.
You’re right about that error message. What’s happening is that when the SMB share gets unmounted, the app can no longer access its SQLite database (pba.sqlite), and the resulting error isn’t very user-friendly. I agree it would be much clearer to explicitly detect a missing or unmounted network share and provide guidance.
I’ve added this to my list of things to improve. Thanks again for taking the time to report it — feedback like this is super helpful.
Yes — in Apple Photos the manually edited date/time is not written back into the image or video file. It’s stored separately in the Photos library database, which is why tools like Immich usually fall back to the original capture date in EXIF / QuickTime metadata.
Photos Backup Anywhere does handle this case: it reads the adjusted date from the Photos library and stores that modified timestamp in its own SQLite database, linked to the backed-up file, so the edited date isn’t lost even though the file itself isn’t rewritten.
That’s a good question. To be completely honest, I don’t know much about Advanced Data Protection myself, and I didn’t do anything specific in the app to detect or interact with it.
I’m actually curious: how did you discover that it doesn’t work when Advanced Data Protection is enabled? Was it through an error message, incomplete backups, or something else you noticed?
Metadata is stored in an SQLite database alongside the backed up files. The format is not documented, but should be self explanatory if you examine the schema.
Backing up “mercurial” Photos data is only half the problem. The tricky part is restoring it in a way Photos actually recognizes as equivalent to the original library state. Photos Backup Anywhere restore works by re-importing items while explicitly reapplying Photos-level attributes: paired assets for Live Photos, burst membership and picks, slo-mo metadata, edits, locations, adjusted capture dates, and then reconstructing albums after the items exist again in the library.
In other words, the filesystem copy isn’t treated as the source of truth. The restore verifies items against what was backed up and only then rebuilds higher-level structure like albums. That’s the piece I didn’t see addressed elsewhere, and what originally motivated me to build it.
HN disclosure: I’m the author of Photos Backup Anywhere, but this thread mirrors the exact issues that pushed me to write it.
One thing that surprised me when digging into Apple Photos is how much state isn’t represented by just files-on-disk. Albums, Live Photos (paired assets), bursts, slo-mo, edits, and even “simple” things like adjusted capture dates are all tracked separately, and most export/backup tools end up flattening or partially reconstructing that on restore.
The approach I took was to treat Photos as the source of truth and verify restored items against it, rather than assuming filesystem metadata is enough. As far as I know, this is the only tool that restores albums and correctly round-trips all Photos item types while preserving location data, creation dates, and modification dates when restoring back into Photos.
Very cool! I've transitioned from using Google Translate and DeepL to ChatGPT for translations. In general I think the ChatGPT translations are better, but the default UI for is a little tedious. Looks like your tool solves this problem.
I tried translating some Japanese, but the result is not correct.
兄や弟さえも憎むようになりました.
I have come to hate even my brothers and sisters.
It should be "I have come to hate even my older brother and younger brother."
Are you using ChatGPT 3.5? I've found that you need to use version 4 to get quality translations as 3.5 makes a lot of mistakes.
While that might be Apple's "official" solution, there's a major caveat: the Photos app doesn't support storing the Photos library on a networked disk. This forces you to either fit your entire library on your Mac's internal storage or use a directly connected external disk with no network involved.
To overcome this limitation, I developed a MacOS app that creates a full backup of your Photos library. You can safely store this backup on any external storage like a NAS, network drive, internal disk, or external disk. Check it out here: https://ibeni.net
Compared to the "iCloud Photos Downloader," which scrapes data from iCloud, my app uses the official Apple Photokit APIs to back up your photos. This method is more reliable and efficient.
The library works at the database-level and stores databases modifications as binary change sets in a separate table that models a graph similar to a git repository. Capturing modifications is as simple as wrapping the transaction with a handler provided by the library. The graph of database modifications is stored locally on each device, but can easily by synced with an online repository.
The library detects conflicts, and provides a handler to the application for conflict resolution.
Thanks for your comment. Let me know if you end up implementing this on Android. I think this concept could be adaptable to other platforms or languages. I just happened to be working in Swift and so I started there.
It took about a week to prove the idea was viable and then another week or two to get the code into a state where I felt it would be useful to share.
Their latest problem is a flaky internet connection that sometimes drops and I’m not sure if it’s the router or their ISP and it’s very difficult to debug.
There are local mom and pop shops that will do computer service, but minimum charge is around $100 so not worth it for anything minor.
The problem with trying to solve anything over the phone is they lack the vocabulary to describe what they are seeing or to follow any kind of directions. I assume you have some kind of screen sharing to solve this?
Nice to hear from someone else with a huge iCloud Photo Library--we've got about 1.2 TB! After a lot of experimentation with Google Photos, Synology's photo APP, etc. we finally settled on going all in on the Apple ecosystem (we're an all-Apple family). The game-changer for us was when Apple finally supported shared photo libraries between users.
The ability to search the photo library has been steadily improving (in my experience, Google still has an edge over Apple in this area) and with the advent of new AI technology I only expect it to get better. Except for special occasions I don't even attempt to "organize" or "tag" my photos. It reminds me of how Google Search surpassed early 'library catalog' style indexes like Yahoo.
The biggest downside of iCloud is the lack of an API to access the data programmatically for backups etc. I've experimented with `icloudpd` and it worked OK, but I'm not sure about the long-term stability as it's basically just "screen scraping" iCloud.com to download the photos from the web which is not officially supported by Apple and is sensitive to any changes to the website as well as the (remote?) possibility of getting your account banned. The performance is also bad as it has to download all photos even the ones that are already stored locally.
There’s also `osxphotos` (https://github.com/RhetTbull/osxphotos) which works by reverse engineering the undocumented sqlite database in the photos library that Apple uses for storing the photos metadata. This avoids the performance problems of accessing the library through iCloud.com like `icloudp` does and enables many more features like searching by faces, places, etc. and they have an export function with a ton of options to backup your library.
Finally, I have a side-project working on a simple set-it-and-forget Mac app for backing up your entire photo library (including iCloud Photos) to a local disk, network share, NAS, etc. Unlike the above options, it uses the official Apple PhotoKit library to access the photos and doesn’t require setting up a Python environment, running command-line tools, etc. If you’re interested check it out here: https://www.ibeni.net
Thanks for the feedback! The app started as a personal project exactly to solve the problem you mention of the iCloud library exceeding the available disk space. (My personal library is more than 1 TB in size.)
The app doesn't require an account or login and the backups are stored only on your device or chosen drives and not on any external servers.
I need to add a privacy policy to the web page to make the policy clear and I believe Apple also requires a privacy policy before the app can be officially released.
The app creates file-system-level backups of each individual photo and video from your Photos library. Every asset is exported as a real file on disk (HEIC, JPEG, MOV, etc.), not a database blob or package, so you can browse, copy, verify, and back them up with standard tools.
In addition, the app keeps a small SQLite database alongside the files to track metadata (including edits, albums, and relationships like Live Photos), which allows accurate restores and verification while still giving you transparent, plain-files access to your media.