Restore data

Caryvane writes backups to storage you own, as ordinary files under ordinary names. That is the first thing to know about restoring: in an emergency, anything that can read the bucket can read the backup. The four paths below are the ones the console gives you.

You want	Use
Files or folders back onto a machine — the original or any other	A Restore job
A mailbox item, a OneDrive/Drive file, a SharePoint document, a Gmail message	Browse backup on the connector job
Last Tuesday's copy of a file that lives on a cloud drive	Version history in Explorer
A Hyper-V VM, a SQL database or Active Directory	Application captures

A Restore job (files) #

A Restore job is a Files job in reverse: it reads from a storage target and writes to a machine through its agent. It can target the machine that made the backup or any other machine with an agent — which is how you rebuild a laptop, or hand a leaver's files to their replacement.

Jobs → New Job → Restore. Restore is offered for Files only; choose it on the Basics step.
Restore From. The storage target holding the backup, the container or bucket, and the path within it. Backups are stored under the job's destination directory, then the source path namespaced by drive: backups/laptop-01/C/Users/jo/Documents/. The browse button walks the target so you can point at exactly the folder you want. Original agent is optional — it labels the restore and narrows the browse to that machine's backups.
Restore To. The agent to write onto and an absolute destination path on it. Restoring over the original location is a choice, not the default: the wizard warns if the path is not absolute and never assumes.
Run it. Manual is the natural schedule for a restore. Run History shows files written and any that failed, with the reason.

Restoring one file

Set Source Path to the file itself. For a whole machine, the drive folder (…/C/). Restores never delete anything at the destination; what is there stays there, with the restored files written alongside or over it.

Restoring elsewhere and permissions

Files come back with the content and timestamps they had; NTFS permissions are not part of the backup. A folder restored onto a different machine inherits that machine's permissions.

Microsoft 365 and Google Workspace items #

Connector backups keep a catalogue of every item they have copied, so you can find one without knowing where it landed in the bucket. On the connector job's row: ⋮ → Browse backup.

Download any item to your own machine — an .eml message, a file from OneDrive or Drive, a SharePoint document — to hand to the person asking.
Restore to original puts it back where it came from: a message back into the mailbox, a file back into the drive or site, at its original path. The restore runs as a small task on the same agent or Cloud Agent that made the backup; it appears in Run History and its result is shown against the item.

Teams channel messages are download-only — Microsoft's API does not allow a message to be written back as though the original author had posted it. Whole-mailbox and whole-drive restores are a series of item restores; for a leaver whose account has been deleted, use the archive taken before deletion instead.

Version history on a cloud drive #

On Windows, a file on a cloud drive whose storage keeps versions (a job or drive with Keep previous versions on) has Version history… on its Explorer context menu. It lists every kept version with its date and size; pick one and Restore this version to put it back in place, or open it beside the current file. Nothing is deleted — restoring an old version makes the current one the newest previous version.

The same versions exist in the bucket for any job with version history on, in the destination's native versioning where it has one and otherwise in a .versions sidecar beside each file; a Restore job pointed at a version's path brings that copy back.

Application captures: Hyper-V, SQL Server, Active Directory #

An App-consistent job stores what the VSS writer describes: for Hyper-V the VM's .vhdx disks and its configuration files (.vmcx, .vmgs, .VMRS); for SQL Server the database's .mdf/.ldf files; for Active Directory the ntds.dit, its logs and the SYSVOL contents. They sit under <destination>/vss/<component>/<drive>/<original path>, exactly named, so a Restore job brings them back as files and the application's own tools do the rest.

Hyper-V #

Restore the VM's files to a folder on the host with a Restore job (or download them straight from the bucket).
Attach the disk to a new VM — Hyper-V Manager → New → Virtual Machine → Use an existing virtual hard disk — or, to bring back the original VM with its identity, Import Virtual Machine from the restored configuration files.
Incremental chains. A VM backed up incrementally has, per disk, a folder hyperv/<VM>/<disk>/full-<date>/ containing the base .vhdx, a numbered diff-NNN.avhdx per night, and chain.json saying what is there. Download the whole folder to one directory; then either attach the highest-numbered diff (Hyper-V follows the parents by name) or merge them down:
```
Merge-VHD -Path .\diff-003.avhdx -DestinationPath .\diff-002.avhdx
Merge-VHD -Path .\diff-002.avhdx -DestinationPath .\diff-001.avhdx
Merge-VHD -Path .\diff-001.avhdx -DestinationPath .\diff-000.avhdx
Merge-VHD -Path .\diff-000.avhdx -DestinationPath .\<disk>.vhdx
```
which leaves <disk>.vhdx as the disk at that night.

SQL Server #

Restore the .mdf and .ldf to a folder the SQL service account can read, then attach: CREATE DATABASE [name] ON (FILENAME = '…\name.mdf'), (FILENAME = '…\name_log.ldf') FOR ATTACH. The capture was copy-only, so the customer's differential and log backup chain is intact and can be applied on top for point-in-time recovery.

Active Directory #

The capture is the domain controller's NTDS database and SYSVOL as of the snapshot. Restoring it is a Directory Services Restore Mode operation (boot the DC into DSRM, restore the files, mark objects authoritative with ntdsutil where needed); Microsoft's procedure applies and is beyond what this page can safely compress. Take the files back with a Restore job and follow it.

If the console is not available #

Everything above reads from a bucket, share or folder that belongs to the customer. With the storage credentials and any S3 browser, rclone, or Explorer for an SMB share, the files are there under the names above. Connector items are stored as the originals (.eml, the file itself); the catalogue only makes them easier to find.