On the appliance or vault, when a Live Mode recovery is started, the selected snapshot is marked as Persistent (to elevate it above test mode.)

Persistent snapshots are immune to deletion via manual or automatic snapshot cleanup processes. This is to ensure that data from the recovery is not inadvertently deleted.

When running a virtual machine on an appliance, vault, or Virtual Office, the persistent snapshot clone is effectively the “live” system and the location where all changed data is written. Typically, when you are done with virtual recovery, you shut down the virtual machine then recover back to the customer environment using the persistent snapshot (which has all of the data, up to the moment the machine was shut down.)

When you fail over a protected system to a virtual machine, you must ensure that backups continue.

Even though both the “live” machine and the backup are now located on the same physical host (the backup server,) you must continue to generate new backup recovery points if further data incidents occur. (Users may inadvertently delete files, crypto malware may infect your system, etc.)

• For appliance protected systems virtualized on the local appliance: Backups will automatically continue, since the virtual machine is on the same LAN as the original and the backup server should be reachable on the LAN.
   
• For Direct-to-Cloud (D2C) cloud protected systems on Axcient-hosted vaults running in Virtual Office: Backups will continue automatically, as Virtual Office is configured to allow routing to the public FQDN address of the vault the agent is already configured for.
   
• For Direct-to-Cloud (D2C) cloud protected systems on self-hosted private vaults:  It is up to you to (a) configure the proper loopback NAT and firewall rules allowing vault access via public FQDN from inside the datacenter LAN and/or (b) ensure that the proper DNS entries exist to allow correct identification of the IP address of the vault.
   
• For appliance protected systems running in Virtual Office: You must manually convert the agent to Direct-to-Cloud mode for backups to continue while virtualized in the cloud.  (Presumably, the appliance has been lost, forcing you to virtualize in the cloud.)

Local cache relies on a hash file which exists on the selected recovery snapshot (containing an index of the local cache block data to designate the virtual disk data to be recovered.)

Live mode contains a hash file which is frozen in the original data state.  In Live Mode recovery, the data in the snapshot is read/write and all changes are written into the Live Mode persistent snapshot clone.  There is no mechanism for updating the hash file within the persistent snapshot with new data changes. 

It is imperative that backups (while virtualized) continue to be performed while running as a virtual machine in the cloud.

Each backup will update the hash file (in the new backup) to allow correct indexing into the local cache.

Even though the local cache itself cannot be updated while virtualized in the cloud, the updates to the hash file in the backup will ensure that the recovery data is properly reconstructed.

Note:  If you are virtualizing a Direct-to-Cloud system with local cache in Virtual Office (or using a self-hosted vault), the local cache will become stale as changes are made to the system that cannot be sent to the cache. However, during recovery, the local cache may remain relevant because

• Data that has not changed while running in the cloud will still be present in the cache and available to accelerate recovery. 
• Data that has changed in the cloud while virtualized and was not written to the cache will simply be fetched over the internet from the vault during recovery.