Recover your
saved work.

Keep a saved session on a second compatible host so losing the first host does not also lose that copy. Choose the recovery point around the progress your workload can afford to repeat.

Plan for interrupted workSee what comes back
Original hostRecovery hostSave the sessionRetain work on the original hostOriginal hostRecovery hostCopy the saved stateKeep a copy on a compatible hostOriginal hostRecovery hostResume from that copyWork after the copy is not recovered

A saved session on the same host lets work resume after a waiting period.

Cross-host copies require guest networking to be disabled.

Preserve more than
the finished file.

Snapshot sleep saves the scripts, intermediate results, and guest state behind an output. It then releases CPU and memory while the work waits.

What a saved session needs to resume

Restore needs compatible runtime, kernel, and CPU characteristics, plus available capacity. Ordinary pause creates no recovery copy. Local snapshots survive a restart only while their storage remains intact.

Keep the copy
beyond the original host.

Copy an eligible sleeping session to another compatible host. If the original host is lost, that surviving copy can become the session's starting point again.

Copying is explicit. Refresh the copy after later saves. Work after the last successful copy is not recovered.

Connectivity changes the recovery choice.

Cross-host snapshot copies require guest networking to be disabled. Connected workloads need an application-level recovery approach that accounts for this restriction.

Different interruptions.
Different ways back.

The management service restarts.

VMYard can reconnect to sessions whose VM processes are still alive on the host.

The application checks the task's status before continuing.

A command's response is lost.

VMYard returns a recorded result if one exists, or reports that the outcome is unknown.

Check what happened in connected systems before issuing replacement work.

The machine is lost.

A successfully replicated snapshot on a surviving host provides a recovery point.

Recover that copy, then resume when capacity is available. Sessions without a surviving copy cannot be recovered this way.

Other cases your operating plan should cover

A saved copy cannot be restored.

VMYard refuses corrupt or incompatible snapshots. Investigate the compatibility or use another valid copy.

The fleet controller restarts.

It reloads saved session and host records. Your operating team checks connectivity and resolves any uncertain operations.

Avoid running the same
action twice.

A command may have sent a message or changed a record before its response was lost. VMYard reports an unknown result instead of blindly repeating the command.

Your application reconciles that outcome with the connected system. Restoring a session does not undo a payment, message, or database change outside the VM.

Decide how much progress
you can afford to repeat.

Use that decision to set your save-and-copy policy and recovery capacity. Exercise the complete path with a representative task.

Session copies and controller records serve different purposes

A standby stores fleet records, separate from guest state. Those records can diverge or miss changes if controllers lose contact, requiring operator reconciliation. A standby does not replace session copies.

Plan for the progress
you need to recover.

Choose a task's recovery point and the host where its copy should live.

Build your evaluation brief
Place saved work on your hosts

Plan capacity and storage around the workload.

Control access to the session

Connect workspace boundaries with business permissions.