PAR2 recovery data lets SyncBackPro repair a damaged backup file in place, without going back to the source. It protects against the failures that quietly ruin an older backup: bit rot, a bad sector, a partial write, a file that decayed on the shelf. Enough of a file can be rebuilt from the recovery data alone that the backup is usable again.
It is not a second copy of your files. If the drive holding the backup fails, or the backup folder is deleted, recovery data cannot bring anything back, because the damaged file it repairs is no longer there to repair. Recovery data complements a second backup; it does not replace one.
Recovery data is written as standard PAR2 files, so other PAR2 tools can read and use it. An Integrity Check verifies every protected file and repairs whatever damage it finds. This setting is off by default, because recovery data costs disk space.
|
Recovery data repairs damage inside a backup file you still have. It is not a backup of your backup. If the backup drive itself fails you will need another copy of your data, ideally kept somewhere else. |
How PAR2 works
PAR2, short for Parity Archive version 2, is an open standard for forward error correction: extra data, worked out in advance, that lets damage be put right later without another copy of the original. It was devised for Usenet, where large files arrived in many pieces and some pieces always went astray, and it has been in general use since 2003. SyncBackPro writes ordinary PAR2 files, so other PAR2 tools can read them.
To protect a file, PAR2 divides it into equal pieces called slices. SyncBackPro chooses the slice size automatically: about 100 slices for a file, with no slice larger than 512 KB, so larger files get more slices, up to 2,000 at about 1 GB. Beyond that the count stays at 2,000 and the slices grow instead, which keeps the time taken in proportion to the size of the file. A checksum is recorded for every slice, and Reed-Solomon arithmetic then works out a number of extra recovery slices. The redundancy percentage decides how many: at 10%, a file of 300 slices gets 30 recovery slices.
A recovery slice is not a copy of any part of the file. Each one is computed from all of the data at once, and that is what makes the scheme flexible: any one recovery slice can rebuild any one lost slice, wherever in the file the damage falls. Thirty recovery slices will mend any thirty damaged slices, in any combination.
Detecting damage and mending it are kept in separate files. The index, data.bin.par2, holds the file name, its size and the checksum of every slice, and no recovery data at all. That is enough to say whether a file is damaged, and exactly which parts of it are damaged, but not enough to mend it. Mending comes from the recovery volumes, the .vol00+01.par2 files, which are written in doubling sizes so that a repair need only read back as much recovery data as the damage actually calls for. Each volume also carries its own copy of the descriptive information, so the set still works if the index file is lost.
What recovery data is good for
•It finds damage rather than assuming it. A backup file that has quietly rotted still has the size and date it always had, so comparing it against the source notices nothing. Verification reads every slice and checks it, so silent corruption is found instead of being carried forward.
•Repair needs nothing but the backup itself. No return to the source, no second copy, no download. That matters most when the source has since changed or gone, or is a cloud service you would have to pay to read back.
•The file is mended where it stands, keeping its name, its dates and its place in the backup.
•Damage is handled one file at a time. A rotten file is repaired on its own; the rest of the backup is not involved and nothing else has to be rewritten.
•Inserted or removed data costs only the slices where it changed. When bytes are inserted into a file or removed from it, rather than overwritten, everything after the change moves. Verification finds the rest of the file where it moved to, so only the slices where the change happened count as damaged. A few deleted lines are as cheap to repair as a bad sector, and adding new data, however much, damages at most the one slice where it lands. The repaired file is checked against the original's checksum and then copied over the damaged one, so it keeps its attributes and permissions.
•It does not care what is in the file. Documents, photos, virtual disks, archives: PAR2 works on bytes and needs no understanding of the format.
•It is an open standard, so getting your data back does not depend on having SyncBackPro to hand. See Repairing with another PAR2 tool below.
•Checking is practical. Verification reads each file once and runs at about the same speed as creating its recovery data, which makes a regular scheduled Integrity Check practical.
What recovery data cannot do
•It cannot bring back a file that has gone. Deleting a file, or losing the drive it was on, loses every slice at once, and rebuilding a whole file from nothing would need 100% redundancy. Even then, a file rebuilt from nothing comes back with today's date and default attributes, because recovery data does not record a file's dates or attributes. Only a file repaired in place keeps them, because the original file is still there to take them from. Recovery data guards against a file going bad, not against a file going away. The same is true of a file overwritten from end to end, by ransomware for instance: nearly every slice changes at once, far beyond what any sensible redundancy will mend.
•The budget is fixed. Ten percent redundancy repairs damage to 10% of a file's slices and not one slice more. Past that point the file is not partly repaired: it is left exactly as it is and reported as unrepairable, so the damaged copy is still there for you to salvage what you can from it.
•Damage anywhere in a slice costs the whole slice. A single flipped bit and a wholly destroyed slice cost the same to repair, so damage scattered thinly through a file is far more expensive to mend than the same number of bad bytes in one place.
•It protects the backup as it was written, not as it ought to be. Recovery data is worked out from the file after it reaches the destination, so if what was copied was already wrong, the recovery data faithfully protects the wrong content. It proves the backup has not changed since it was made; it cannot say the backup was right to begin with.
•The recovery files are ordinary files, and they can rot too. They are not themselves protected by recovery data. Damage to them is detected and the affected parts ignored, so a rotten recovery volume quietly lowers how much damage can be repaired rather than causing a bad repair. It is one more reason to keep a second backup.
•It costs disk space, and time on the run that creates it. See What it costs below.
Insider Access
PAR2 recovery data is an Insider Access feature: it is planned as a standard feature of the next major version, and in this version it is available through Insider Access. You can use it while you have an active Upgrade Assurance subscription and have turned Insider Access on.
Without Insider Access this page is hidden, or shown greyed out in Expert mode with the note Requires Insider Access. A profile that already has recovery data switched on carries on backing up as normal, but no recovery data is created or checked, and every run says so with a warning. An Integrity Check that has nothing but recovery data to check fails, and says why.
The recovery data already created is kept, and is still never synchronized, so nothing is lost. Turn Insider Access back on and the next run makes good anything that changed in the meantime. If you would rather have the space back, the Remove Recovery Data button still works, in Expert mode. When you turn Insider Access off, SyncBackPro lists the profiles that use it and asks you to confirm.
When this page is available
Recovery data is only useful where checking it is cheap and returning to the source is expensive, so it is restricted to backups written to a plain local or network folder. The page is hidden unless the profile qualifies. In Expert mode it is shown greyed out instead, with the note Needs a local, uncompressed destination. The profile does not qualify if:
•it is a group profile
•the destination is not a local drive or network share, so FTP, cloud, SyncBack Touch, MTP devices, location scripts and backup of email are all excluded
•the destination is compressed into a single zip file, or one zip file per file
•Fast Backup is used, as it never scans the destination and so has nothing to maintain the recovery data against
•the profile deletes everything on the destination before it runs
•delta copy versioning is used on the destination
Only the destination is examined, because the destination is the backup and the backup is what recovery data protects. Copying from a cloud service, an FTP server or SyncBack Touch to a local drive is fully supported. During a restore the two sides swap over, so it is the source that is verified and repaired, since that is where the backup is.
Settings
•Create PAR2 recovery data for destination files: Tick this to create and maintain recovery data for the files this profile writes to the destination. It is off by default. A file is protected when it is first copied, and its recovery data is rebuilt whenever the file is copied again. Switching this on for a backup that already exists is fine: the next run protects the files that are already there, without copying them again.
•Redundancy percentage: How much recovery data to create, as a percentage of the size of the file it protects. The default is 10, and the range is 1 to 100. Roughly speaking, 10% redundancy repairs damage affecting up to about 10% of the file. A higher figure repairs more damage and uses proportionally more disk space. Ten percent is a sensible default for bit rot and bad sectors, which damage a small part of a file rather than most of it.
•Minimum file size (KB): Files smaller than this are not protected. The default is 1024 KB, which is one megabyte, and the smallest you can set is 64 KB. Small files are a poor fit for PAR2, because each protected file gets its own set of five recovery files and every one of them repeats the same header packets. For a requested 10%, the recovery data actually costs about 12% of a 1 MB file, 13% at 512 KB, 16% at 256 KB, 21% at 128 KB and 31% at 64 KB, against about 11% for large files. If you want small files protected, a second copy of them is usually the better tool, so raising this value is more often wise than lowering it.
•Also create PAR2 recovery data for version files: Off by default. When ticked, the older versions kept by versioning are protected as well as the current files. Versions are usually the copies you would reach for after discovering damage, so protecting them is worthwhile, but it increases the disk space used in proportion to how many versions you keep.
•Store recovery data in: Leave this empty, which is the default, to keep the recovery data with the backup. Enter or browse to a folder to keep it somewhere else. The folder can use variables, for example %LOCALAPPDATA%\SyncBack Recovery, but not a date or time variable: that would put the recovery data in a different folder on every run. See below for how the folders are laid out.
•Remove Recovery Data: Deletes this profile's entire recovery store. It tells you how many files it protects and how much disk space they use, and asks you to confirm, before deleting anything. Your backup files are not touched; only the recovery data goes, so those files simply stop being repairable. This button stays available even when the setting above is unticked, because turning recovery data off deliberately leaves the existing store alone: this is how you reclaim the disk space afterwards.
•File Types: Opens the filter window, where you choose which file types get recovery data using include and exclude masks. By default the masks are DOS-style wildcards and the profile's own filters are applied as well. Files already excluded from the backup are never protected, since they are not at the destination in the first place. If a file stops qualifying, because you excluded its type or raised the minimum size, its existing recovery data is removed on the next run.
Where the recovery data is stored
Recovery data is never written next to the file it protects. It is kept in a folder named $SBP$ that mirrors the structure of the backup. With the store location left empty, that folder sits at the root of the destination, so a backup at D:\Backup gives:
D:\Backup\sub\data.bin
D:\Backup\$SBP$\sub\data.bin.par2
D:\Backup\$SBP$\sub\data.bin.vol00+01.par2
The first file is the index and the rest are recovery volumes. For most files there are five, one index and four volumes; very large files get a few more, because each volume is roughly twice the size of the one before it.
If you set a store location, the recovery data goes to <store location>\<profile name>\$SBP$ instead, so two profiles pointed at the same store cannot overwrite each other. You might move the store to keep the backup folder itself tidy, or to put the recovery data on cheaper storage. Bear in mind that it does not protect you against losing the backup drive: recovery data repairs a damaged file, and a file that has gone cannot be repaired.
Unticking the setting above does not delete the recovery data that already exists, deliberately: a store you may still want should not vanish because a box was cleared. To reclaim the space, use the Remove Recovery Data button described above.
SyncBackPro never synchronizes the $SBP$ folder, in the same way it leaves the $SBV$ versioning folder alone. This applies whenever the profile is capable of using recovery data, not only when the setting is ticked, so turning the setting off does not destroy a store you may still want. The one consequence is that a folder of your own genuinely named $SBP$ at such a destination will not be copied.
What it costs
Disk space. At the default 10% redundancy, expect about 12% of the size of the protected data for files around 1 MB, falling towards 10% for files of 64 MB and above. Watch the file count as well as the space: there are five recovery files for every protected file, one index and four recovery volumes. In one measured backup of 300 files and 525 MB, the 100 files that qualified produced 500 recovery files totalling 55 MB.
Time, on the run that creates it. In the 64-bit version, recovery data is created at about 110 MB/s for files of a few megabytes, rising to 200 to 240 MB/s for files of 100 MB and above, so protecting 10 GB of changed data adds something like one to two minutes to a run. The 32-bit version is about as fast for files of up to a few hundred megabytes, but much slower for very large ones: files of 1 GB are protected at about 75 MB/s, or roughly two and a half minutes for every 10 GB. The first run after you switch the setting on is therefore much slower than usual, because everything already at the destination is protected then. This is expected, and it happens once.
Time, afterwards. Almost nothing. A run where no file changed pays only for the check that asks whether each file already has recovery data. In the measured backup above, a steady-state run with recovery data switched on took 1.7 seconds, against 2.3 seconds for the original plain copy.
Time, to check it. Verification runs at about 170 to 230 MB/s in both the 32-bit and 64-bit versions, faster for larger files, and repairing a damaged 64 MB file took under two seconds. When damage is found, verification also searches the file for slices that have moved, which adds roughly 0.7 seconds per GB. That search only happens when there is damage, so checking an undamaged backup costs nothing extra. The Integrity Check also scans the destination folders for files that have no recovery data, so it can take a little longer on a large destination. Checking a backup is much cheaper than most people expect, which is why a scheduled Integrity Check is worth having.
Disk space, to repair it. Data moves when bytes are inserted into a file or removed from it, rather than overwritten. Repairing a file whose data has moved writes a temporary full copy of that file in the recovery store, beside its recovery data, for example:
D:\Backup\$SBP$\sub\data.bin.par2rebuild
So the repair needs free space equal to the size of that file, wherever the recovery data is kept: on the backup drive by default, or in the Store recovery data in folder if you have set one. The temporary copy is always deleted afterwards, whether or not the repair worked. If there is not enough room, the repair fails with Recovery data I/O error and the damaged file is left exactly as it was; the next Integrity Check will try again. Damage that only overwrote data, such as bit rot or a bad sector, is repaired in place and needs no extra space.
Checking and repairing a backup
Creating recovery data does not check anything. To check and repair a backup, run an Integrity Check on the profile, from the profile pop-up menu. The profile does not need file integrity recording to be switched on for this: with it off, the Integrity Check checks only the files that have recovery data. Every protected file is read and verified against its recovery data; any file found damaged is repaired in place if there is enough recovery data to do it. A repaired file is listed with the files that passed, marked as damaged and repaired. A file too badly damaged to repair is reported as a failed integrity check and counted as an error. The log gains a PAR2 Recovery Data section giving the number of files protected, the recovery data written, and the number of files verified and repaired.
If you also switch on file integrity recording, the Integrity Check also checks the files that have no recovery data, such as files smaller than the minimum size or excluded by the File Types filter, and the source/left files if you record their integrity as well. Damage to those files is only detected, not repaired, and protected files are then read twice, once for each check.
A repaired file still fails this check. With both switched on, the Integrity Check runs in this order: it checks the destination/right files against their recorded integrity data, then the source/left files if you record their integrity too, and only then verifies the recovery data and repairs what it can. A damaged protected file is therefore found first by the integrity data check, which records it as a failed integrity check, and is then repaired from its recovery data and logged as repaired. The file is not checked again after the repair, so the result of the Integrity Check is still a failure, and the log lists the same file twice: once as a failed integrity check, then as repaired. To read a failed result:
•If every file that failed is also listed as repaired, the damage was found and fixed. Run the Integrity Check again to confirm: it passes, because each repaired file now matches its recorded integrity data.
•Any file that failed and is not listed as repaired is still damaged. That includes a file whose recovery data could not verify or repair it, which also fails the check.
An Integrity Check verifies and repairs, but it never creates recovery data. It does look through the destination for files that should be protected but have no recovery data, using the same rules as a backup run: the profile's own filters and folder selections, the Minimum file size and the File Types filter, and versions only when Also create PAR2 recovery data for version files is ticked. Each such file is named in the log with this warning:
This file has no recovery data, so the integrity check could not check or repair it. It will be protected on the next backup run.
Up to 100 files are listed. If there are more, one further line gives the number of the rest, for example:
250 more files have no recovery data, so the integrity check could not check or repair them. They will be protected on the next backup run.
These are warnings, not failures. Nothing is damaged, so the Integrity Check still succeeds, with warnings. A file usually has no recovery data because recovery data was switched on after the file or version was copied and the profile has not been run since, because its recovery data was deleted, or because it stopped qualifying and later qualified again. Recovery data is created, and missing recovery data is made good, by a normal run of the profile, so run the profile itself to protect anything that has been left unprotected, and the warnings stop.
Earlier versions of SyncBackPro never created recovery data for versions stored in sub-folders. If you protect versions, the first Integrity Check after upgrading may list such versions. The next backup run protects them.
A restore checks the backup before it copies anything back. Every protected file about to be restored is verified first, and repaired if it needs it, so what you get back is the original content rather than damaged bytes. The log says when this happened.
Repairing with another PAR2 tool
The recovery data is standard PAR2 and can be used by other PAR2 tools. This has been tested in both directions against par2cmdline: it verifies and repairs the files SyncBackPro writes, and SyncBackPro verifies and repairs the files it writes.
There is one trap worth knowing. A PAR2 tool expects to find the protected file in the same folder as the .par2 files, and SyncBackPro deliberately keeps them apart. So running this inside the $SBP$ folder:
par2 repair data.bin.par2
reports Repair is not possible. You need 70 more recovery blocks, which is misleading. The tool looked for data.bin next to the recovery files, did not find it, and concluded the file was missing entirely rather than damaged. Tell it where the data actually is instead:
par2 repair -B"D:\Backup\sub" data.bin.par2
Alternatively, copy the .par2 files for that one file next to the data before running the tool. Either way works; the recovery data itself is perfectly ordinary PAR2.
Be aware that another PAR2 tool may not keep the repaired file's dates or attributes. par2cmdline, for example, writes the repaired file with the date of the repair. If that happens, the next run of the profile may see that backup file as changed.
What is not supported
•Delta copy will never be supported. Recovery data describes a complete file, and a file assembled from a chain of deltas is not one until the chain is applied. Use recovery data or delta copy, not both.
•Compressed destinations and destinations that are not a local drive or network share are not supported at present. Verification means reading every byte of every protected file, which is slow and, on a cloud service, expensive.
•Files below the minimum size are not protected, and neither are files excluded by the File Types filter or by the profile's own filters.
All Content: 2BrightSparks Pte Ltd © 2003-2026