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.
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.