How Smaug (Karbor) Provides Unified Data Protection for OpenStack

Project Overview

Smaug (later renamed Karbor) is an OpenStack project that delivers Data Protection as a Service (DPaaS). It enables vendors’ data‑protection software to integrate with OpenStack through a standard interface, providing backup, replication, and migration for virtual machines and other resources. The project was initiated to solve the lack of a unified backup interface in OpenStack and quickly gained attention within the OpenStack ecosystem.

Protectable Resources

Smaug classifies cloud applications into three layers—Web, Basic, and Database—but the resources that need protection in OpenStack extend beyond these layers to include VMs, networks, volumes, projects, services, and their dependencies. To protect the three‑tier application model, Smaug must protect all of the following resources:

Volume: the read‑write storage device attached to a VM.

Virtual Machine: a deployable unit consisting of metadata, configuration, description, and related dependencies.

Virtual Network: the communication network for VMs.

Project (called “Engine” in the article): a collection of VMs, volumes, images, networks, etc.

Image: a virtual boot image or software package.

An example project (engine) may contain multiple application VMs (Web and DB), each with its own image, network (including router), and data volume.

Plugin Architecture

Smaug defines a set of standard interfaces and workflows that allow different vendors to implement Plugins and Providers, abstracting away vendor‑specific details. A Provider consists of a group of protection Plugins and a Bank that stores protection metadata. Administrators configure which Providers are visible to tenants and assign a Bank account to each tenant.

Third‑party vendors must implement Plugins that conform to Smaug’s standard APIs so that the core framework can invoke them uniformly.

Standard APIs

Smaug exposes a comprehensive set of RESTful APIs for each stage of the data‑protection lifecycle:

Resource (Protectable) API : Lists protectable resource types and instances.

Protection Plan API : Allows users to create or modify protection plans using selected Providers.

Provider API : Returns available Providers and their configuration details, including the Plugins they expose.

Checkpoints API : Manages checkpoint objects (similar to snapshots) and creates a Vault in the tenant’s Bank for each checkpoint.

Schedule Operation API : Defines triggers and schedules for protection tasks.

Restore API : Retrieves data from selected checkpoints to restore resources to a specific point in time.

System Architecture

Smaug follows a modular design, allowing each component to run as an independent service. Key services include:

Smaug API Service : A collection of API modules that expose the protection functionality to users and other OpenStack services.

Operation Schedule Service : Coordinates the execution of protection plans, maintains operation logs, and separates scheduling from the core protection service.

Trigger Engine : Generates triggers based on timers or events and maps them to scheduled operations.

Protection Service : Executes protection, recovery, verification, and deletion tasks; manages protection Plugins and Bank interactions.

WorkFlow Engine : Registers protection plans, writes metadata and transaction information to the Bank.

Bank and Bank Plugin : Implements a global banking model that stores protection metadata, transaction history, and can be accessed across clouds.

Through this architecture, Smaug can protect both native OpenStack resources (VMs, volumes, images) and external resources (hardware devices, external databases) by loading the appropriate Plugins and routing operations via the standardized APIs.