Jump to: navigation, search

Difference between revisions of "Trove/volume-data-snapshot-design"

(Description)
(Description)
Line 2: Line 2:
  
 
=== Description ===
 
=== Description ===
This feature is being proposed as the addition backup strategy
+
:This feature is being proposed as the addition backup/restore strategy
  
 
==== Volumes Snapshots ====
 
==== Volumes Snapshots ====

Revision as of 19:52, 16 April 2014

Data volume snapshot

Description

This feature is being proposed as the addition backup/restore strategy

Volumes Snapshots

This introduction provides a high level overview of the two basic resources offered by the OpenStack Block Storage service. The first is Volumes and the second is Snapshots which are derived from Volumes.

Volumes

Volumes are allocated block storage resources that can be attached to instances as secondary storage or they can be used as the root store to boot instances. Volumes are persistent R/W Block Storage devices most commonly attached to the Compute node via iSCSI.

Snapshots

A Snapshot in OpenStack Block Storage is a read-only point in time copy of a Volume. The Snapshot can be created from a Volume that is currently in use (via the use of '--force True') or in an available state. The Snapshot can then be used to create a new volume via create from snapshot.

Backup workflow

The actual flow will be:
  1. ask if instance if it has the volume
  2. prepare database for storage snapshot
  3. snapshot
  4. return database in to the normal state

Restore workflow

  1. create a new volume from the given snapshot
  2. swap the volume
  3. update backend record
  4. delete initial volume

Recovery process

So, lets say, cinder failed to create the snapshot, for the Trove it's like - no problem, lets mark it as FAILED and thats all.

Justification/Benefits

Justification

Data could be backued in two ways:
  1. Standart backup strategies (innobackupex, nodetoolsnapshot) + Swift container (already implemented).
  2. Snapshot of the attached block storage (not implemented).
Basically, its the another way of backupin' data through standard OpenStack capabilities.

Benefits

Generic way to backup the data. This feature is not the datastore-type/version specific.

Impacts

Changes the behavior to the backups made by Trove, it impacts at already implemented backuping process through native database tools (mysqldump, nodetool, etc.) and the Swift as storage container service. Changes are backward compatible.


Configuration

Configuration parameters are guest specific.
Name Type Default Available variants
backup_agent String trove.guestagent.backup.backupagent.SwiftAgent trove.guestagent.backup.backupagent.CinderAgent
storage_strategy String Swift Cinder

Database

No changes


Public API

No changes

Internal API


From trove-api to trove-taskamanger

No changes


From trove-taskamanger to trove-guestagent

No changes

Guest Agent


Changes are backward compatible. Changes will be available for all datastores. This method of the backuping is generic for the all datastores types/versions.