Can an archive be moved?

A couple of years ago, I created a full C: partition archive using PDB 2011 on my laptop. I (probably erroneously) saved the archive to the C: drive. Now I want to restore this archive, but I'm assuming that you can't restore a partition archive to the same partition where it is stored. Correct?

So is there any way to move an archive to a different drive, like an external USB drive, so that I can restore my C: partition? Physically copying the archive files is possible, but it appears that the full path of the archive's files is stored in the archive itself, so I'm figuring if I try to restore a moved archive, it will still end up looking for the files back in the C: partition.

Is there a way around this catch 22?

 

I've never done what you are asking about but here is my "guess":

I believe you are correct in that the archive cannot be on the same partition you are restoring because the partition gets deleted before it is restored so your files would be gone.

I don't think the drive letter is an issue because the rescue environment does not necessarily use the same drive letters as your original Windows installation. The drive letters on the restored system get sorted out on bootup.

Also, the program has no idea what the drive letter of a USB drive will be when it is being used. Just because you make an archive with the external USB drive being drive J:, it doesn't mean it will always be assigned J: when you use it. This would be another indication that it isn't an issue.

It your archive contains slices (files making up the whole archive with extensions like .001, .002) rather than one large archive file such as if you split a 25GB archive into 4GB slices when creating it, then there is an embedded path at the end of the slices to the next slice.

I had this problem while verifying such an archive in Windows. It would verify the first slice no matter where I had moved it but then it would jump to the original location as specified by the path at the end of the slice to verify the remainder. This would validate your concern. However, if the archive was copied to a different machine where there was no chance of it finding the other slices by the embedded path, it continued to do the verify of all slices in the new location. Since your copied archive situation is close to that, it will probably do the restore.

I would do the restore directly from the CD and I strongly suggest you make another archive of your drive on the external before you try this just in case it fails and you are left with nothing.

 

Thanks, SeekForever. That all makes sense. I'll do a new full-image backup to the external drive, then try to restore the moved archive after booting from a PDB boot CD.

 

Success!

I booted from the recovery CD, located the archive on the external USB drive and started a restore. Initially, it refused, stating that there were files on the target partition that were open and in use - telling me to manually close them before restoring. Not sure how I would do that from within the boot CD interface. Since I had no way to determine what was open or to close the files, I used the CD's interface to make the target partition inactive (figured that would close any open files). After the partition was inactive, I started the restore again. This time it worked.

At first I was worried I'd get the same error about open files because immediately after selecting the archive to restore, the target partition's status flipped back to "Active." This must have been done at the start of the restore process, because I received no error or warning. The restore took about 20 minutes and the laptop booted fine afterwards.

Thanks for the help.

 

Did you try to look at the files it had a problem with? This sounds similar to a problem I had a few years ago and when I went to view the problem files nothing showed up. Since I had several archives, one of the older ones worked. The funny part was that the same exact archive was used to restore earlier and worked. Paragon claimed to have seen this themselves and blamed it on WinPE and happens from time to time.