When verifying an image I received an error message asking me to provide a location for the missing file "P7-J-02-02".  Below is a list of the filenames in the image collection. My naming scheme is Computer name (P7)-Drive name (J)
---------------------------------
P7-J -00-00.mrimg  - full backup of drive J:
P7-J -01-01.mrimg  - subsequent incremental backups
P7-J -02-03.mrimg
P7-J -03-04.mrimg
P7-J -04-05.mrimg
P7-J -05-06.mrimg
P7-J -06-07.mrimg
P7-J -07-08.mrimg
P7-J -08-09.mrimg
P7-J -09-10.mrimg
P7-J -10-11.mrimg
P7-J -11-12.mrimg
P7-J -12-13.mrimg
---------------------------------------
Big question is why Reflect numbered a file 02-03 instead of 02-02.   Tried renaming a copy of 02-03 to 02-02, but no joy.
I have six other drives that are being backed up individually, four are numbered in the expected sequence and verify correctly.  The remaining two are numbered oddly, but only one fails to verify:
      00-00, 01-01 ==> 02-03, 03-04, 04-05  which verifies as missing file 02-02
                   and
      00-00  ==> 00-01,  01-02, 02-03 which verifies as OK

In all three cases the numbering "jump" occurred during the same one week period so I am suspicious that I might have been messing with the Reflect settings in the Backup Definition Files.

So now I am left to wonder what backup sets I can trust.
Long time PC user, back to the 80's, but a new Reflect user so still climbing the learning curve - grin..
Thanks in advance.

The naming/numbering convention used by Reflect for maintaining backup sets is fully explained in this KB article.  The file number should not differ from the increment number unless files have been split as can happen when files larger than 4GB are saved to a FAT32 file system.  (Reflect's container for file and folder backups is a 'virtual' FAT32 file system.)  What changes did you make to the backup task definition and did they involve the inclusion/exclusion of any files larger than 4GB?


Regards, Richard V. ("Arvy")

Thanks for the link, it was good to refresh myself.   Does not seem to explain how the numbering of incremental files occurred.      I had experimented with switching between a specified maximum file size and Automatic, the idea of a single 800+ gig file is a bit unsettling, but do not believe I did that after the initial full backup was created.

In the file numbering, the first 2 digit code is the backup number, the second is the file number.  If you do not have any split files then these numbers will be the same for any given backup set (00-00, 01-01, 02-02, etc.). However if multiple files are created for a backup, the numbering will reflect this (00-00, 01-01,01-02, 02-03, etc.) note that the second backup (backup 01) had TWO files (01-01 and 01-02). 

Looking at your file numbering, there seems to be a missing file: either 01-02 or 02-02. So one of your incrementals had an additional file that is missing (or maybe did not get written out, or ???).  That is why that set will not verify.  Since you say that this happened on other systems during the same week, it is likely that something went wrong on your system during that time.  (duh).

At this point, the backup sets with the missing files are useless (other than the full backup and maybe the first incremental).  Since any incremental after the gap in numbering is not going to be useable by Reflect.

@ALM4 -- Based on the "please locate" message, there seems to be something more involved than just a skipped number.  It obviously thinks that another file (P7-J-02-02.mrimg) should, in fact, be available in the backup set but that the file itself is actually missing.  If a backup image file split has occurred it would also account for the numbering issue fully in accordance with Reflect's numbering convention.  However, my comment and question about a source file >4GB was incorrect for backup images.  I was only considering this topic being posted under the File and Folder Backup section and failed to notice the .mrimg filename extension.  A backup image file would only be split due to one of the two reasons stated in that KB article.  Other than accidental relocation or deletion, however, I can't offer any suggestion about why it would be missing.


Regards, Richard V. ("Arvy")

Drac144, Arvy
Thanks for your responses.  Guess I will put it down to a Blue Moon event, but watch my future backups closely for a re-occurrence.   I had searched the forum for similar reports without any luck so I am assuming this is an unusual event.
Thanks also for confirming that any incremental files beyond the gap are useless.
Al