Dennis,
No problem asking questions.
There is indeed documentation that hopefully answers these questions too ( https://www.vimalin.com/documentation/wi...ne-backup/ ) but I see no harm in just answering the questions asked instead of sending you off to the doc.
The folder name it creates on restore has a " - backup <date>" suffix in order to prevent overwriting originals. Where <date> is in military format and is the date when the backup was taken. Restoring a backup made today would be restored with suffix " - backup 2019-08-04".
If you don't want that suffix then you can rename the folder name and remove the suffix before you open it in VMware Workstation.
The VM name itself also has this suffix so that it is easy to identify. Note that this name can be changed from within VMware Workstation back to the original name.
A suspended VM will be suspended and a shut down VM comes back as shut down.
Restoring a physical machine in production is a tricky and dangerous exercise. If things go wrong and your backup didn't restore as expected then it is quite traumatic and things might be worse as before the restore.
With VMs however it is pretty harmless and a good exercise that I can only recommend doing so that you have a feel how it all works before disaster strikes.
You might want to practice with a slightly smaller VM though as 300GB takes its time to copy and create/verify md5 sums.
TL;DR it is safe to restore your backup as it will not overwrite your original VM.
You can't overwrite the original VM by accident, at least I cannot think of a scenario on how you would be able to succeed in doing so.
No problem asking questions.
There is indeed documentation that hopefully answers these questions too ( https://www.vimalin.com/documentation/wi...ne-backup/ ) but I see no harm in just answering the questions asked instead of sending you off to the doc.
Quote:If I do need to restore a backup and the guest is still running do I suspend the quest and do the restore or power it down completely?You normally don't overwrite the original. There's no need with VMs. Of course you can back to the original names, but it requires a bit of extra work on your side.
The folder name it creates on restore has a " - backup <date>" suffix in order to prevent overwriting originals. Where <date> is in military format and is the date when the backup was taken. Restoring a backup made today would be restored with suffix " - backup 2019-08-04".
If you don't want that suffix then you can rename the folder name and remove the suffix before you open it in VMware Workstation.
The VM name itself also has this suffix so that it is easy to identify. Note that this name can be changed from within VMware Workstation back to the original name.
Quote:If it was running when the backup was done, after the restore will it still be in running state, suspended or powered down state?If the VM was running while making the backup it will come back to the same running state. This works well when you restore to the same host, if you restore to another host then you can choose to restore in shutdown state as things like CPU registers might not exist on the different hardware and restoring state might not work or be unstable.
A suspended VM will be suspended and a shut down VM comes back as shut down.
Restoring a physical machine in production is a tricky and dangerous exercise. If things go wrong and your backup didn't restore as expected then it is quite traumatic and things might be worse as before the restore.
With VMs however it is pretty harmless and a good exercise that I can only recommend doing so that you have a feel how it all works before disaster strikes.
You might want to practice with a slightly smaller VM though as 300GB takes its time to copy and create/verify md5 sums.
TL;DR it is safe to restore your backup as it will not overwrite your original VM.
You can't overwrite the original VM by accident, at least I cannot think of a scenario on how you would be able to succeed in doing so.