Forum Discussion

spitman's avatar
spitman
Level 5
10 years ago
Solved

VMware "Restore to original location"

Hello,

We performed a restore yesterday on a VM. The customer wanted the VM replaced to an earlier date in time; so I did a "Restore to Original Location" from the restore menus. He said that afterwards, there were still newer files on the server (after the restore date we had picked).

I guess I was under the impression that if you did a full vmdk restore, that "restore to original location" would put down a  whole new vmdk and replace anything that was in it--to include having files that were there previously wiped out.

I know some will say that this is not best practice--that you should always restore a copy and then blow away the original VM when you are sure you no longer need it--but this was a test box, so that wasn't something they needed.

Any thoughts/experience would be helpful... thanks in advance...

  • What OS was the restored VM? Did the customer specify which files were newer? If its a Linux one could use touch to modify timestamp but I doubt thats the case here.

    I've always opted to restore "on the side", not on top of the current one.

  • I would have expected your restore to have caused the old VM to have been destroyed/deleted/removed/overwritten/replaced in its entirety - IF - you a did a VM restore.  If you did a file level restore, then yes, the newer files would remain.  A full VM restore should restore a VM to a known point in time, that of the backup.  Apologies, but I can't help from being sceptical about your results.  Are you able to recreate the issue?  Is it repeatbale?  I find it odd that no-one has ever reported experiencing this kind of apparent behaviour before for a full VM restore at the VMDK level.

    Are you sure that your VM restore was a full VM restore (at the VMDK level) and not a file level restore (within the guest OS)?

3 Replies

  • What OS was the restored VM? Did the customer specify which files were newer? If its a Linux one could use touch to modify timestamp but I doubt thats the case here.

    I've always opted to restore "on the side", not on top of the current one.

  • I would have expected your restore to have caused the old VM to have been destroyed/deleted/removed/overwritten/replaced in its entirety - IF - you a did a VM restore.  If you did a file level restore, then yes, the newer files would remain.  A full VM restore should restore a VM to a known point in time, that of the backup.  Apologies, but I can't help from being sceptical about your results.  Are you able to recreate the issue?  Is it repeatbale?  I find it odd that no-one has ever reported experiencing this kind of apparent behaviour before for a full VM restore at the VMDK level.

    Are you sure that your VM restore was a full VM restore (at the VMDK level) and not a file level restore (within the guest OS)?

  • It was a full VMDK restore. 

    No one has reported this issue before, because it may have been the first time we did an in-place restore like this.

    We will have to get to a point where things slow down enough to do a test of this.

    Thanks all.