Replaced a disk with a larger disk and now get XML Validation Error. Knowledge base says full backup...


Replaced a disk with a larger disk and now get XML Validation Error....
Author
Message
stevep
stevep
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)
Group: Forum Members
Posts: 11, Visits: 34
I changed one of my disks from a 4TB disk to a 8TB disk. I copied over all of the data from the old disk to the new one and then updated the new disk to reflect the name and disk letter to match the old disk. The error I get is:  Error - '<disk>' '3' '<partition>' 3' is not valid

The knowledge base describes how to fix this by editing the definition file to select the partition. The problem is that the final note says:  "Note: In this case, as the partition layout has changed, you cannot create an Incremental or Differential image of an existing backup set. A new Full image will be created by default." Creating a new full backup would wipe out my current backup and its incremental files. I use the Synthetic Full Backup to keep the full backup current with the last deleted incremental backup. Why must a full backup be required when I don't use sector-by-sector backup and I use the default compression? It seems like it would be of no concern to Reflect that the disk has changed since the drive is labeled the same and the same files are being backed up.

Any work around available so I don't have to do a full backup and wipe out my current backup data?

I am running Windows 10 Pro and backup three disks:  512GB SSD plus 4TB and 8TB hard drives.

Thanks,
Steve

BTW, Reflect has saved me several times--thank you!  I have had to restore my system from a backup because of a new program update or a new program caused instability. It seems like the quality of software is going down. Programs are being rushed to market without enough testing.


Edited 10 January 2021 9:31 AM by stevep
dbminter
dbminter
Macrium Hero
Macrium Hero (2.7K reputation)Macrium Hero (2.7K reputation)Macrium Hero (2.7K reputation)Macrium Hero (2.7K reputation)Macrium Hero (2.7K reputation)Macrium Hero (2.7K reputation)Macrium Hero (2.7K reputation)Macrium Hero (2.7K reputation)Macrium Hero (2.7K reputation)Macrium Hero (2.7K reputation)
Group: Forum Members
Posts: 2K, Visits: 19K
The way I think it is working in this case, Reflect goes by some kind of disk ID for the partitions it backups.  If you add a new disk, it's got new "properties."  Thus, the partitions are effectively "new" to Reflect and the XML's must be updated to reflect (Ha!) that.  Plus, depending on certain factors, the start and end sectors for the partitions could be different on the new disk since it is larger.  Depends on if there's any pre-existing partitions on the new disk or if the partitions were restored in a different order than they were backed up in.


I don't know of a way to avoid doing a new Full backup in a case like this, sorry.


If you wanted to hold on to the old backup sets until you're comfortable with the number of new backup Full and Incremental\Differential sets you have, I would recommend creating a subfolder in the location where your current Target is for backing up and move the current sets into there.  That way, you have an archive to fall back on, just in case.  Then, you can delete those archives later.

stevep
stevep
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)
Group: Forum Members
Posts: 11, Visits: 34
dbminter - 10 January 2021 3:51 PM
The way I think it is working in this case, Reflect goes by some kind of disk ID for the partitions it backups.  If you add a new disk, it's got new "properties."  Thus, the partitions are effectively "new" to Reflect and the XML's must be updated to reflect (Ha!) that.  Plus, depending on certain factors, the start and end sectors for the partitions could be different on the new disk since it is larger.  Depends on if there's any pre-existing partitions on the new disk or if the partitions were restored in a different order than they were backed up in.


I don't know of a way to avoid doing a new Full backup in a case like this, sorry.


If you wanted to hold on to the old backup sets until you're comfortable with the number of new backup Full and Incremental\Differential sets you have, I would recommend creating a subfolder in the location where your current Target is for backing up and move the current sets into there.  That way, you have an archive to fall back on, just in case.  Then, you can delete those archives later.

Thanks for the reply. Yes you're right. Reflect uses a disk ID as mentioned in the Knowledge Base. I wish there was an alternate approach because my current main backup uses over half of my 8TB backup drive so I can't put the past backup in a new folder and start a new backup which needs over 4TB. I am using my smaller alternate backup drive to do the new backup. The system has been creating a new backup with verification for about 18 hours and it's still not finished! Another reason I don't like to do full backups. I really like the Synthetic Full backup because it minimizes the time to keep a full backup ready.

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Dbminter’s note as to why the new Full is necessary is correct. You also have to do this even if the disk has NOT changed if any partitions have been added or removed from the selection or any partitions have had adjustments to their sizes and/or “offset” (position on disk). I presume at least one partition is a different size now if you moved to a larger disk. Be aware that Windows 10 feature updates can sometimes alter the parition layout of the disk that contains the Windows installation, so you can get an unexpected Full for that reason.

But if you can’t create a new Full without wiping your existing set, I would argue that you already have a high-risk setup. Only having a single backup set means that all of your backups depend on a single Full, which means that if that Full ever became corrupted or even part of it became unreadable, partially due to an issue with the underlying disk it sits on, then all of your backups are useless. I only ever recommend Synthetic Fulls to users who are either backing up to a rotation of disks and therefore have multiple backup sets in aggregate or who are at least replicating their backups to some additional location. But if you were doing either of those things, then presumably creating a new Full wouldn’t have been an issue since you’d have another copy of the existing set or some other backups elsewhere. So if you’re not using a rotation or replication, then I really wouldn’t use that strategy, even though I fully understand its appeal in terms of storage efficiency. For a single destination, no-replication scenario, the closest I would come to Incrementals Forever with Synthetic Fulls would be monthly Fulls with daily Incrementals, and then use Incremental Merge rather than Synthetic Fulls. That way even if your latest Full is corrupt or unreadable, you’ll still have another Full. It may be almost 2 months old depending on the timing, but it will surely be better than nothing.

That said, there’s a lot to be said for replication or rotation. Having backups stored in multiple locations/devices has benefits for ALL backup strategies.
stevep
stevep
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)
Group: Forum Members
Posts: 11, Visits: 34
Thank you for the information. I have been using one internal backup disk for automatic daily incrementals and an external backup disk that I do occasional manual incremental backups to. Since I installed the new data disk drive, I have used my external manual backup disk to do a new full backup to. I removed the main backup that had automatic backups scheduled and will keep it offline for a few days to see if I need anything off of it and I establish a new backup strategy.

Will Reflect do a new full backup if I change the drive letter and title of a backup drive?  I've done a full backup to the external drive and am considering switching its identity from drive X to drive Y and letting it be the new daily backup disk for automatic backups.

Thanks very much for the feedback,
Steve

jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Reflect doesn't care if the path to your backup files changes, so long as you point it at the new path of course.  Basically, when you tell it to create an Incremental or Differential backup to a specific destination, it will look at the files at that destination at that particular moment in time and determine whether that's possible based on the contents of those existing backups and what you're trying to back up now.  If an Inc/Diff is possible, Reflect will make one.  It doesn't care if those files USED to be at some other path.  By the same token, if you had a disk rotation, you could have each disk in your rotation be drive letter X whenever it's connected, and therefore your Reflect backups will always to go to some path on X.  Reflect will have absolutely no problem dealing with the fact that the particular backups at that path on X might be completely different from one day to the next.  Again, it just works with whatever happens to be there at the specified destination when the backup is executed.

Edited 12 January 2021 2:14 AM by jphughan
stevep
stevep
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)
Group: Forum Members
Posts: 11, Visits: 34
jphughan - 12 January 2021 2:12 AM
Reflect doesn't care if the path to your backup files changes, so long as you point it at the new path of course.  Basically, when you tell it to create an Incremental or Differential backup to a specific destination, it will look at the files at that destination at that particular moment in time and determine whether that's possible based on the contents of those existing backups and what you're trying to back up now.  If an Inc/Diff is possible, Reflect will make one.  It doesn't care if those files USED to be at some other path.  By the same token, if you had a disk rotation, you could have each disk in your rotation be drive letter X whenever it's connected, and therefore your Reflect backups will always to go to some path on X.  Reflect will have absolutely no problem dealing with the fact that the particular backups at that path on X might be completely different from one day to the next.  Again, it just works with whatever happens to be there at the specified destination when the backup is executed.

Wow, talk about a fast response! Good information. I didn't know that each backup disk of a rotation set could use the same drive letter and Reflect will determine what needs to be backed up on that disk based on what's already there.

I really appreciate the help,
Steve
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
Happy to help!  Reflect doesn't have a way of guaranteeing that each disk in the rotation will be assigned the same drive letter by Windows -- though there are applications that can achieve that -- but Reflect DOES have a mode whereby you can have it find destinations by unique volume identifier rather than drive letter.  In that mode, the drive letter assigned at any given time doesn't matter.  Instead, when you specify a destination, it says, "Ok, the drive to look for is the one with ID [long random identifier]", and then when each backup runs, Reflect will look for that volume that way.

But yes, I really like Reflect's design because it does make disk rotations very easy.  The fact that it only ever works with the backups that are available at the time of the backup job means that in a multi-destination scenario, all backups on each disk are "self-contained", meaning that you'd never have a situation where an Incremental on Disk #2 depends on the Full that exists on Disk #1.  And as a result, it becomes very easy to have a solution where the failure of one backup destination disk isn't a major issue because you've got backups on at least one other disk, and those backups don't have any dependency on the failed disk. Smile

stevep
stevep
New Member
New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)New Member (14 reputation)
Group: Forum Members
Posts: 11, Visits: 34
Follow up questions:  Migrating a data disk (non-operating system disk) to a new disk using Windows Explorer to copy everything over was not a good approach. Would using Reflect to restore data to the new drive have updated the disk ID in the registry and prevented the XML error? Would this have prevented the need to do a full restore on my backup disks which erases my previous backups?

Thanks,
Steve

Edited 13 January 2021 5:54 AM by stevep
jphughan
jphughan
Macrium Evangelist
Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)Macrium Evangelist (12K reputation)
Group: Forum Members
Posts: 8.4K, Visits: 57K
If the original source disk was NOT online when you perform the restore AND the restored partition uses exactly the same offset and size as the original partition, then I think you can sidestep the requirement for a new Full when imaging that new disk going forward -- but I'm not 100% sure about that.  I guess it would be a pretty quick scenario to test with virtual disks and a small amount of data, though.  But I know that you definitely WOULD need to create a new Full if you alter the offset or size during or after the restore or you perform a clone because the source disk is online at the time.  The reason the latter is an issue is that Windows doesn't allow two disks with the same ID to be online at the same time, so if you clone a disk, Reflect has to change the ID of the new disk -- and that will definitely mean you'll need to start a new set.  Macrium has an article about disk IDs here.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Reading This Topic

Login

Explore
Messages
Mentions
Search