Back up your photo library

Applies to: Photo Date Rescue for Windows, version 3.0.11. Last verified: 17 September 2026. Every statement on this page was checked against the shipping 3.0.11 build. If you are on an older or newer version, the behavior may differ — check What’s new for changes.

This page is the reference we cite from our comparison table. Each capability below has its own permanent link, so a claim about PDR can always be traced to the paragraph that supports it. Where the answer is “no” or “only partly”, this page says so in the same words the comparison uses.

A note on vocabulary. PDR has two separate things it can protect, and they behave differently:

• Your photos — the image and video files themselves.
• Your library — PDR’s database of dates, faces, places, albums, collages and edit history. This is the work you did, as opposed to the pictures you took.

Read every answer below with that distinction in mind. The library is protected automatically. The photos are not.

---

At a glance

---

Work out what storage you need

This is arithmetic on numbers you type in, not a measurement. Photo Date Rescue has not looked at your drives to produce it, and anything you do not tell it about — a second PC, an old phone, a shoebox of discs — is not counted. Treat the answer as a starting figure to sanity-check, not a quote.

How many photos and images do you have?

What are most of them?

Phone or JPEG about 4 MB each A mix, some RAW about 12 MB each Mostly RAW about 25 MB each

Roughly how many hours of video?

How much do you add each year?

Not much about 10% a year A steady amount about 25% a year A lot about 50% a year

Which matters more to you?

Keeping the cost down 30% spare room A balance 60% spare room Belt and braces double, and a second offsite copy

Answer the questions above and your plan appears here. Nothing is estimated before then, because a plan for an average library would not be a plan for yours.

Start again

The figures this uses

Every number the planner relies on is listed here so you can disagree with it. Drive makers count a terabyte as 1,000 gigabytes and so does this planner, which is why Windows will report a smaller number on the same drive.

The formula is: photos × size + video hours × size gives today’s figure; × (1 + growth)³ gives the figure in three years; × spare room gives what each copy needs, and × 1.25 again gives what the offsite copy needs. Every copy holds the same photographs — a backup cannot contain more than the thing it backs up — so the offsite copy is not larger because it holds more, but because it is the one you cannot go and replace the week it fills. We do not recommend particular drives, makes or services, and nothing here is a suggestion to buy from anyone in particular.

Where PDR fits in that plan — and where it does not

PDR does three separate things that get mistaken for backups. None of them is a backup of your photos, and it is worth being exact about which is which.

Put plainly: if your photos only ever existed on the PC that died, restoring the library gives you an accurate index of photographs you no longer have. The library is not a substitute for backing up the images. That is what copies 2 and 3 above are for.

---

Making a second copy of your photos

Yes. Every Fix run in PDR is a copy operation. You point PDR at the folders, drives or export archives that hold your photos, you choose a separate destination, and PDR writes corrected copies there. The files you pointed it at are read and never written to. That is not a setting you can turn off — it is how the Fix pipeline is built.

To do it

1. Open PDR and add your sources: a folder, an external drive, or a Google Takeout export (ZIP archives are unpacked for you).
2. Choose the destination folder. Pick a different drive from the sources if you can; a second copy on the same disk does not survive that disk failing.
3. Review what PDR proposes to do.
4. Run the Fix. PDR writes new files at the destination, organized into year folders, with corrected dates and filenames.

Limitations

• It copies the run, not your collection. What arrives at the destination is the files you added as sources for that run. It is not a backup of everything PDR knows about, and it does not include the library itself — see backing up the library database and your projects.
• This is something you start. It does not repeat on its own — see repeating backups.
• It is a copy, not a sync. Running it again does not work out what has changed since last time; it processes what you give it.
• If duplicate-skipping is switched on, PDR will deliberately not write a file it judges to be a duplicate of one it has already written in that run. Your destination is then intentionally smaller than your source. That is usually what people want from a messy export, but it means the destination is not a byte-for-byte mirror.
• PDR does not read the copies back to confirm they arrived intact. See verification.

---

Repeating backups to a second drive

Only partly, and only for your library. Once you have set a Library Drive, PDR copies its database to that drive automatically: once at every launch, before it does any housekeeping, and then during the session about every 30 seconds after a change that counts. Your photos have no schedule at all. Nothing in PDR will copy your images on a timer, overnight, or when you plug a drive in.

To set the Library Drive

1. Connect an external drive, or map your NAS to a drive letter.
2. In PDR, open the Library Drive settings and choose Set as new library.
3. Pick the folder. PDR checks what kind of drive it is and will warn you if you have picked a disk inside your PC, because a copy that lives in the same box as the original does not survive the box being lost or stolen.
4. PDR creates its library folder there and copies the current database up immediately.

From 3.0.9 a Library Drive is stamped with the profile it belongs to, and PDR reads that stamp before it attaches anything. A drive with no PDR library on it is simply set up and becomes this profile’s. A drive that already belongs to another profile on this computer is refused, by name — “this drive belongs to Sarah, not Dad; switch to Sarah to use it” — and there is no button to do it anyway, because the whole point of separate profiles is that one cannot reach another’s library. Three cases in between ask you rather than decide: a drive from a different computer, a drive whose owning profile has since been deleted, and a drive set up by a PDR old enough not to have stamped it. In each of those you are offered the same two choices — add it to the profile you are in, or give it a profile of its own — and your photos are not moved or changed either way. See profiles.

Limitations

• Photos are never copied on a schedule. It is the library database that is mirrored, along with your collage projects. Backing up the images themselves is a Fix run you start, or a job for a dedicated backup tool.
• Only the two most recent automatic snapshots reach the drive. Corrected 11 September 2026. From 30 July this page said no snapshots reached the drive at all. That was true at the time — the step that copied them looked for file names PDR never writes, so the folder stayed empty however many copies existed on your PC. That fault is fixed. The newest event snapshot and the newest launch snapshot are copied across; everything older, and anything you saved by hand, stays on this computer only.
• Not every change inside the app triggers a copy. Indexing a run and creating or editing albums do. Some edits made in the app — renaming a person, applying a date change, saving a tree — do not trigger one on their own, and are carried over at the next launch instead.
• Between launches the mirror only runs while PDR is open. Close the app and nothing is copied until you open it again — at which point the launch copy runs.
• The mirror only runs on the device that currently holds the write lock on that library. On a second device opened read-only, changes are not mirrored up.
• If the drive is disconnected the mirror is skipped, and PDR keeps the pending change flagged so it can catch up when the drive returns — but that flag is held in memory, so closing PDR before the drive comes back loses it. The launch copy covers you the next time you open the app with the drive attached. There is no alert telling you the copy is out of date.
• Two things are queued for a drive that went away, and photos are not among them. Screen captures and screen recordings taken while the Library Drive is disconnected are held on this computer and moved into the library the next time the drive is available, and collage projects saved offline are carried across the same way. An imported or fixed photo is only ever written to a destination that is connected at the time of the run.
• There is no interval you can configure, no time of day you can set, and no history of past runs to inspect.

---

Backing up the library database and your projects

Yes. This is what the Library Drive mirror is for. It is not limited to a file index. Four things are written to the Library Drive:

• The library database — corrected dates, people and face names, places, albums, collages and the rest of your organizational work.
• Recent database snapshots — two of them: the newest snapshot taken before a risky operation, and the newest taken at launch. That way you land on a drive with something to roll back to rather than a single copy. PDR has no daily or weekly snapshots, and never has.
• Space for the date-corrections log. The mirror expects one, but PDR 3.0.11 never writes it — see a record of what was changed, and when.
• A small provenance record noting which device wrote the library and which folder it lived in, which is what makes a later restore able to repair paths after a drive letter changes.

To do it

Nothing beyond setting a Library Drive, as described under repeating backups. From that point the mirror is automatic. To force one immediately, make any change in PDR and leave the app open for half a minute.

Limitations

• Only one Library Drive is active at a time, in the profile you have open. Switching to a new one removes PDR’s library folder from the old location, deliberately, so that two libraries cannot silently disagree about which is current. If you want a second copy retained, copy that folder elsewhere yourself before switching.
• Older snapshots, and any you saved by hand, are never mirrored.
• The mirrored database is the library, not the photographs. Restoring it onto a machine that has no photos gives you an index that points at files which are not there.

---

Sending a copy off this machine

Only partly. Network destinations yes, cloud no. A Library Drive can be a mapped network drive or a UNC path such as \\server\share, so a NAS on your own network works and is treated by PDR as a safe choice. There is no cloud destination of any kind — no Google Drive, Dropbox, OneDrive, S3 or PDR-hosted storage. PDR has no photo upload feature.

From 3.0.9 a folder inside a cloud-synced folder cannot be set up as a Library Drive at all. PDR writes to its library the whole time it is running, and a sync client copying those files mid-write — or restoring one of its own “conflicted copy” versions over them — can corrupt the file that records where every photograph is. Choosing one now tells you so instead of setting it up. Cloud storage remains a good place for a separate backup of your library; it is the live library itself that has to sit on an ordinary drive.

PDR checks this two ways. It knows the folder names the sync apps use — OneDrive including a work or school one, Dropbox, Google Drive, iCloud Drive, Box, MEGA, pCloud, Proton Drive, Tresorit, Nextcloud, ownCloud, Yandex.Disk, SugarSync, Koofr, Jottacloud, Seafile and more — and it also asks Windows itself whether the folder is one your computer downloads on demand, which catches a sync folder you have moved somewhere unusual and a provider nobody has listed.

One honest limit comes with that. If you already have a library inside a sync folder, PDR still opens it rather than shutting you out of your own photographs — move it to an ordinary drive when you get the chance.

To use a NAS

1. Map the share to a drive letter in Windows, or note its UNC path.
2. Set it as your Library Drive, as above. PDR recognizes both mapped network drives and UNC paths as network locations and accepts them.
3. For the photos themselves, choose the network path as the destination of a Fix run.

Limitations

• A NAS in your house is off your PC, but it is not off your premises. It does not protect you from fire, flood or theft of the building. If that matters to you, pair PDR with a cloud backup tool pointed at your destination folder.
• No cloud provider is supported directly, and there is no plug-in interface to add one.
• PDR does not encrypt what it writes. Files on the network share are readable by anyone who can read that share.
• A cloud-sync folder on your PC (for example a synced OneDrive folder) will of course be picked up by that provider’s own client, but that is the provider doing the work, not PDR.

---

Restoring onto a replacement PC

Yes. This is the case the Library Drive was designed around: the PC is gone, and the drive is what you have left. Install PDR on the new machine, point it at the library, and your dates, faces, albums and undo history come back without re-importing or re-analyzing anything.

To do it

1. Install PDR on the replacement PC and enter the same license key.
2. Connect the drive, or reconnect the NAS share.
3. Open the Library Drive settings and choose to restore from the existing library rather than create a new one.
4. Confirm when PDR warns you it is about to replace the local database. It saves a copy of whatever was there first, labeled as a pre-restore snapshot, so a restore started by mistake can be undone.
5. PDR copies the database down, pulls the audit log and recent snapshots back, and takes over as the writing device.

On 3.0.11 the new PC recognizes the drive as a stranger’s and asks first. The library carries the name of the profile it belonged to, so PDR tells you it holds the “Dad” library from another computer and offers two ways to take it: put it in the profile you are already in, or create a profile called “Dad” for it. Either is correct — the second is worth taking if the old PC had more than one profile and you will be restoring the others too, because it keeps them apart on the new machine the way they were on the old one. Your photos are not moved or changed either way.

What PDR checks before it restores

• That a PDR library actually exists at that location.
• That it was not written by a newer version of PDR than the one you are running. If it was, the restore is refused with a message telling you to update first, rather than risking a database this build does not understand.
• That your license key matches the one that set the library up. Somebody who finds your drive cannot attach your library to their own copy of PDR. This is an ownership check, not encryption — the photos on that drive are ordinary files and anyone holding it can still open them. See where your files are stored, and who can reach them.

Reconnecting to the photos

If the drive comes back on a different letter — D: last time, E: now — PDR rewrites the stored file paths to match, using the provenance record it wrote alongside the database. That is what “without re-importing” means in practice.

Limitations

• Path repair depends on that provenance record. If it is missing, PDR skips the repair and leaves the original absolute paths, which may or may not still resolve. Rescanning the folder fixes it.
• If your photos were only ever on the PC that died, and were never copied to the Library Drive or anywhere else, restoring the library gives you an accurate index of photographs you no longer have. The library is not a substitute for backing up the images.
• The restore expects nothing else to be running. Finish or cancel any Fix before you start it.

---

Verifying a copy afterwards

No. PDR does not do this, and we would rather say so than let you assume it. After PDR writes a file to your destination, it does not read that file back to confirm the bytes match the source. There is no post-copy verification pass, no checksum comparison against the original, and no report of files that were written incorrectly.

PDR does calculate SHA-256 hashes during some copies, and it is fair to ask why that is not verification. The answer is that the hash is used to spot duplicates — to notice that a file you are copying is identical to one already written in the same run — and it is calculated from the bytes on the way past, not from the file after it landed. It is also only calculated when duplicate-skipping is switched on and the file is small enough to warrant the slower copy path. It tells you nothing about whether the write succeeded.

What PDR does catch

• A copy that fails outright — a full disk, a permission error, a disconnected drive, a path too long for Windows — is caught and reported at the end of the run.
• A copy that has stopped moving is abandoned and reported rather than hanging. PDR watches the bytes rather than the clock: as long as the destination is accepting something, the copy is left alone however long it takes, and it is only given up when nothing at all has been written for two minutes. A very large file over a slow connection is therefore never cut off for being slow. Corrected 17 September 2026: this said any single file taking over two minutes was abandoned, which would have been wrong about every big video on a network drive.

What PDR would miss

A copy that reported success but silently wrote wrong bytes — the classic symptom of a failing drive or a flaky USB enclosure. PDR would not notice, and would tell you the run succeeded.

What to do instead

If your photographs are irreplaceable, verify the destination with a tool built for it. A file-comparison or checksum utility run against source and destination will tell you what PDR currently cannot. We would rather you did that than trust a check we do not perform.

---

Where your files are stored, and who can reach them

Your photographs stay on your own hardware. PDR is a desktop application. It reads photos from your disks and writes them to the destination you chose. It has no feature that uploads a photograph anywhere, no account you log into to see your library online, and no server that holds your images. There is nothing to switch off, because there is no photo upload to switch off.

PDR is not, however, an offline application, and it would be dishonest to imply it is. These are the times it uses the network, and what it sends:

There is no analytics package in PDR. No usage tracker, no crash reporter phoning home, no advertising identifier, no third-party telemetry SDK. Diagnostic logs are written to your own disk and stay there unless you choose to send one to support.

Who can reach the files

• Anyone with access to the drive or share can read your photos. PDR does not encrypt them, and the operating system’s permissions are what protect them.
• The library on a Library Drive is protected by a license check inside PDR, which stops another person’s copy of PDR from opening it. This is not encryption and it is not a security boundary — the database file is still a file on a disk.
• On your own PC, the profile stamp is what keeps one household member out of another one’s library: a Library Drive that belongs to another profile is refused when you try to attach it, with no override. That too is a rule inside PDR, not a lock on the file. Anybody who can reach the drive in Windows Explorer can still copy it.
• Reverse geocoding, which turns coordinates into place names, uses a place-name database shipped inside PDR. Your locations are not sent to a lookup service.

Our full privacy policy governs anything not covered here.

---

Coming back on a different drive letter

Yes. A library kept on a portable drive remembers where it was. Windows hands out drive letters in the order things are plugged in, so the drive that was D: last week can come back as E: today. PDR notices when it reopens the library and updates every stored location to match the letter the drive actually has. You are not asked to re-pick a folder, nothing shows up as missing, and your albums, names and corrected dates all still point at real files. It is the same repair that makes restoring onto a replacement PC work without re-importing.

To do it

1. Reconnect the drive before you start PDR, so the library is there when it opens.
2. Open PDR normally. The repair happens as the library is opened; there is nothing to run and nothing to confirm.
3. Browse a folder you know is on that drive. If the pictures are there, the repair worked.

Limitations

• It happens silently. There is no message saying a repair took place, which also means there is no message when one does not. If it ever failed, the way you would find out is by opening a photo and finding it missing — not by being told.
• It relies on the small record written alongside the library. If that record is absent, the repair is skipped and the stored locations are left as they were. Rescanning the folder puts things right. See restoring onto a replacement PC.
• It is built around ordinary drive letters. Moving a library to a network path is a different kind of move and is not what this is designed to handle; treat it as setting the library up in its new home rather than as a reconnection.
• Starting PDR while the drive is detached is a separate problem, and a worse one. See when files change outside PDR.

---

Whether the copy is always a complete, openable library

Yes. A copy of the library is written under a temporary name first and only renamed into place once it is complete, so an interruption partway through — a power cut, a drive pulled out, PDR closed at the wrong moment — leaves the previous good copy exactly as it was rather than a half-written file sitting where your safety net should be. The automatic copy is taken as PDR launches, while the library is quiet and nothing is being edited, rather than in the middle of your work. The result is that a copy is either the one from before or the one from after, and never something in between.

To do it

1. Nothing. Both behaviors are always on, and there is no setting to switch off.
2. After a long session of corrections, close PDR and open it again. That next launch is what takes the session’s work into a copy.
3. Open Settings › Backup to see the copies that exist, with their dates and sizes.

Limitations

• The automatic copy captures the state you started from, not the state you finished in. It is taken at launch, so everything you do afterwards is covered by the next launch’s copy, not by this one.
• Close PDR and never reopen it, and that session sits outside the automatic set. This is the one habit worth forming: reopen the app after important work rather than leaving it shut.
• The automatic schedule is not yours to set. There is no interval to configure and no time of day to choose; it happens at launch or not at all.
• How far back they go is fixed too, and it is not far. PDR keeps two automatic copies of each kind — two taken at launch, and two taken before a risky operation. Older ones are deleted to stop the folder growing without limit. Two reaches back further than it sounds, because a copy is only taken when the library has actually changed, so those two are the last two times your library changed rather than the last two times you opened PDR. Copies you take by hand are kept separately and are never deleted to make room — but you can hold two of those as well, and PDR refuses a third rather than throwing one of yours away. When that happens it says so and waits: you decide which of the two to let go, because you chose the moment and typed the name, and picking one for you would destroy the exact thing you were protecting. Corrected 17 September 2026: this said five launches, then a daily and weekly ladder. That was replaced in 3.0.8 — sixteen copies of an unchanged library was several gigabytes of the same thing.
• Complete and openable is not the same as verified correct. PDR does not read a written file back to confirm its contents — see verifying a copy afterwards.
• What these copies contain is the library and the work you built in it, not the photographs themselves. See backing up the library database and your projects.

---

When one file or one transfer fails

Only partly, and the half that is missing is the full list. A single file that cannot be read — locked by another program, damaged, sitting behind a permission you do not have — does not bring the run down with it. PDR carries on and processes everything else. At the end you are told how many could not be saved and how many did land, and the first of them is named with the reason it failed — for example “3 of 412 photos could not be saved. The other 409 are on your Library Drive, and nothing was removed from your sources. The first of them was IMG_0841.JPG: EBUSY: resource busy or locked.” What you do not get is the other two. There is no list you can open of every file that failed.

To be exact about it: the finish screen names one failed file; the saved run report names none. The report holds the files that were processed, the duplicates that were skipped and the totals. It has no failure field, no count of errored files and no expandable list of which files failed and why, and neither does the CSV or TXT you export from it. So the detail you see at the end is not kept — if you want it, read it before you close the window.

Correction, 17 September 2026. This page previously said no failed file was ever named anywhere, including on the finish screen. That stopped being true when the ending screens were rewritten for 3.0.8: a run that saves some files and not others now names the first failure and its reason on screen. The report is unchanged, and the missing full list is still a real gap.

To do it

1. Start the Fix and let it finish. Do not stop it because you saw a file fail — the rest of the run is still being processed.
2. Read the sentence on the finish screen before you close the window. It gives you the number that failed, the number that landed, and the name and reason of the first failure. That reason is usually the reason for all of them.
3. Read the report as well and check the total against what you put in. Beyond the first file, a gap in the totals is the only signal you get that something was skipped.
4. If there is a gap, find the missing files yourself — the report names the ones that succeeded, so anything absent from it did not make it through.
5. Deal with the likely cause — unlock the file, reconnect the drive, copy it off a failing disk — and put those files through another run.

Limitations

• Only the first failed file is ever named, and only on screen. If thirty files failed you are told thirty failed and shown one of them. The other twenty-nine are not named anywhere — not in the report, not in the exported CSV or TXT. Nothing is written down, so closing the window loses the one name you had.
• The reporting applies to a Fix run. It is the run that keeps going. Do not read it as a general promise that every part of PDR reports its failures this way.
• The automatic library copies are silent when they go wrong. If one fails you are not told, and you would only notice by looking at the dates in Settings › Backup and finding the newest older than you expected. They are also not strictly all-or-nothing, which we previously implied: the database itself must copy for the attempt to count, but the edit history and snapshot steps can fail on their own and are skipped without stopping the rest.
• Each report covers one run and nothing else. There is no running total of problems across runs and no place that collects repeat offenders, so a file that fails every single time looks like a fresh one-off each time.
• Nothing chases you. The report is there if you open it. Close the window without reading it and the failures are not raised again.
• A file that reports success but was written incorrectly is not in the error list at all, because that is not something PDR checks. See verifying a copy afterwards.

---

Known gaps in 3.0.11

Collected in one place, because they are the things a reader comparing backup tools most needs to know, and because the same ones appear against PDR on our comparison page:

1. No scheduled backup of your photos. The library mirrors itself; the images only move when you run a Fix.
2. No cloud or off-premises destination for your photos. Your Library Drive has to be a local drive or a network share. Your library DB is the exception: DB Backup writes it wherever you point it, and that can be a cloud folder that syncs from this PC. So the record of everything PDR worked out can go off-premises; the photographs themselves cannot.
3. No verification after copying. PDR does not read a copy back to confirm it is correct.
4. No list of files a run failed to process. The run keeps going when a file cannot be read, and the finish screen names the first one it gave up on, but there is no list of the rest and the saved run report records no failure at all. See when one file or one transfer fails.

All four are known gaps and we are working on them. This page and the comparison table change together on the day any of them ships, and the “last verified” date at the top of this page moves with them.

---

How to check this page is still true

Every claim here describes behavior you can observe in the shipping build. If something on this page does not match what PDR does on your machine, that is a defect in one of the two, and we want to know: contact support. Tell us the anchor — for example /help/back-up#verify — and we will either correct the software or correct the page.