Back up your photo library

Applies to: Photo Date Rescue for Windows, version 3.0.4. Last verified: 28 July 2026. Every statement on this page was checked against the shipping 3.0.4 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.

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.
• Rollback snapshots do not reach the drive. Corrected 30 July 2026: this page used to list them as mirrored. The step that copies them looks for file names PDR never writes, so the snapshots folder on the library drive stays empty however many copies exist on your PC. Your snapshots live on the system drive; treat them as being there and nowhere else.
• 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 — the newest event snapshot plus the last three daily ones, so you land on a drive with a usable rollback window rather than a single copy.
• Space for the date-corrections log. The mirror expects one, but PDR 3.0.4 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. 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 beyond the recent set are not mirrored by default.
• 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.

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.

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 takes more than two minutes for a single file is abandoned and reported rather than hanging.

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.
• 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. PDR keeps the last five launches, then one copy per day for the past week, then one per week for the past four. Anything older than that is deleted to stop the folder growing without limit. Copies you take by hand are kept separately and are not pruned.
• 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 naming. 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. What it does not do is tell you which file failed. The run report lists the files that were processed, the duplicates that were skipped, and the totals; there is no error list and no count of failures in it. The only way to notice a shortfall is to compare the report’s total against what you put in.

To be exact about it: no report PDR 3.0.4 writes contains a failure field of any kind. There is no count of errored files and no expandable list of which files failed and why. Our comparison table records the same answer.

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 report at the end and check the total against what you put in. A gap is the only signal you get that something was skipped.
3. 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.
4. 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

• No failed file is ever named. Not in the finish screen, not in the report, not in the exported CSV or TXT. The finish screen counts confirmed, recovered and marked files and the duplicates it skipped — there is no failure tile.
• 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.4

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. External drives and network shares only.
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, but nothing names the file it gave up on. 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.