<commit_before>---
title: Backup-Restore API Integration
category: api
authors: adahms, aglitke, dpkshetty, laravot, mlipchuk, scohen, snmishra
wiki_category: Feature
wiki_title: Features/Backup-Restore API Integration
wiki_revision_count: 100
wiki_last_updated: 2014-12-28
---

# Backup-Restore API Integration

## Backup and Restore API for Independent Software Vendors

### Summary

This feature allows oVirt users to backup and restore VMs using Independent Software Vendors. New set of APIs will be introduced in oVirt to facilitate taking full VM backup, as well as full or file level restore of VMs.

### Owner

*   Feature owner: <NAME> <<EMAIL>>
*   Engine Component owner: <NAME> <<EMAIL>>
*   VDSM Component owner: <NAME> <<EMAIL>>

### Current Status

*   Live snapshot : Done. Available in oVirt.
*   Qemu-nbd : To be integrated.
*   Qemu-ga: To be integrated.
*   VDSM support : To be implemented.
*   oVirt Engine support : To be implemented.
*   UI support : To be implemented.
*   API support: To be implemented.

### Detailed Description

The backup machine will protect virtual machines by offloading backup workloads to a centralized server and providing multiple restore capabilities.

### Full VM restore

The entire VM is restored to the state it existed when it was originally backed up.

### Full VM backups

Back up an entire virtual machine to the backup machine storage as a single object (image). This is an entire VM image snapshot, which is a single snapshot that contains all of the VM disks. All data is backed up at the disk block level. The data can then be restored to a disk, or mounted as a virtual volume for an individual file restore. These backups are managed and retained according to storage policies set up by the backup machine administrator.

### File level restore

File level restore can be performed in-guest or off-host. Mount the volumes of the VM backup as a virtual volume. Then, copy the files that you want to restore.

### Overview of Backup Process

1.  Contact the ovirt-engine containing the target virtual machine.
2.  Command that ovirt-engine to produce a snapshot of the target virtual machine.
3.  Use the ovirt-engine to gain access to the virtual disk(s) and files in the snapshot.
4.  Capture the virtual disk data and virtual machine configuration information.
5.  Command the ovirt-engine to remove the backup snapshot.

### Overview of Restore Process

1.  Contact the ovirt-engine.
2.  Command the ovirt-engine to create a new virtual machine and its virtual disks using the configuration information in step 4 of the backup process above.
3.  Transfer the virtual disk data to the newly created virtual disk(s).

### REST API Support

#### Two new API calls will be added –

1.  Prepare backup disk
2.  Teardown backup disk

#### Prepare backup disk

1.  Lock disk
2.  Live snapshot
3.  qemunbd,with temp snap
4.  Map the qemunbd device to the backup server (Optional: Attach disk to VM)<commit_msg>Two new API calls will be added –<commit_after>---
title: Backup-Restore API Integration
category: api
authors: adahms, aglitke, dpkshetty, laravot, mlipchuk, scohen, snmishra
wiki_category: Feature
wiki_title: Features/Backup-Restore API Integration
wiki_revision_count: 100
wiki_last_updated: 2014-12-28
---

# Backup-Restore API Integration

## Backup and Restore API for Independent Software Vendors

### Summary

This feature allows oVirt users to backup and restore VMs using Independent Software Vendors. New set of APIs will be introduced in oVirt to facilitate taking full VM backup, as well as full or file level restore of VMs.

### Owner

*   Feature owner: <NAME> <<EMAIL>>
*   Engine Component owner: <NAME> <<EMAIL>>
*   VDSM Component owner: <NAME> <<EMAIL>>

### Current Status

*   Live snapshot : Done. Available in oVirt.
*   Qemu-nbd : To be integrated.
*   Qemu-ga: To be integrated.
*   VDSM support : To be implemented.
*   oVirt Engine support : To be implemented.
*   UI support : To be implemented.
*   API support: To be implemented.

### Detailed Description

The backup machine will protect virtual machines by offloading backup workloads to a centralized server and providing multiple restore capabilities.

### Full VM restore

The entire VM is restored to the state it existed when it was originally backed up.

### Full VM backups

Back up an entire virtual machine to the backup machine storage as a single object (image). This is an entire VM image snapshot, which is a single snapshot that contains all of the VM disks. All data is backed up at the disk block level. The data can then be restored to a disk, or mounted as a virtual volume for an individual file restore. These backups are managed and retained according to storage policies set up by the backup machine administrator.

### File level restore

File level restore can be performed in-guest or off-host. Mount the volumes of the VM backup as a virtual volume. Then, copy the files that you want to restore.

### Overview of Backup Process

1.  Contact the ovirt-engine containing the target virtual machine.
2.  Command that ovirt-engine to produce a snapshot of the target virtual machine.
3.  Use the ovirt-engine to gain access to the virtual disk(s) and files in the snapshot.
4.  Capture the virtual disk data and virtual machine configuration information.
5.  Command the ovirt-engine to remove the backup snapshot.

### Overview of Restore Process

1.  Contact the ovirt-engine.
2.  Command the ovirt-engine to create a new virtual machine and its virtual disks using the configuration information in step 4 of the backup process above.
3.  Transfer the virtual disk data to the newly created virtual disk(s).

### REST API Support

#### Following API calls will be needed for backup –

1.  create vm snapshot (the api call exists today)
2.  get VM Config (new API)
3.  prepare backup disk (new api, should probably accept: hostid, disk;

      - return: paths to device on host as well as map of changed blocks-
      - this should be called for every disk that needs to be backed up.  Note that VM snapshot takes a snap of *all* disks of the VM.

1.  attach disk to backup vm (the api call exists today. This assumes virt app) - also has to be called per disk to back up
2.  detach disk (symmetric to attach disk)
3.  teardown backup disk (symmetric to prepare backup disk)
4.  delete snap - This can only be called if VM is down today and is not mandatory in any event. Once we have live merge, it should be policy driven ( user should be able to choose whether to keep or delete)

#### Prepare backup disk

1.  Lock disk
2.  Live snapshot
3.  qemunbd,with temp snap
4.  Map the qemunbd device to the backup server (Optional: Attach disk to VM)
{'fraction_non_alphanumeric': 0.057091882247992866, 'fraction_numerical': 0.00847457627118644, 'mean_word_length': 3.9066374908825674, 'pattern_counts': {'":': 0, '<': 21, '<?xml version=': 0, '>': 21, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7653251', 'n_tokens_mistral': 1864, 'n_tokens_neox': 1804, 'n_words': 1026}