Jump to: navigation, search


Revision as of 10:00, 27 June 2016 by Memo Garcia (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Getting Started with Freezer

Freezer is a Backup and Restore as a Service tool that helps you automate the backup and restore process for your data.

Freezer executes backups and restores as jobs, and executes these jobs independently and/or as managed sessions (multiple jobs in multiple machines sharing a state).

Freezer features:

  • Multiplatform: Linux, Windows, *BSD, OSX.
  • Snapshots in Linux using LVM and on Windows using VSS.
  • Encryption using AES-256-CFB.
  • Low storage consumption: backups and restores are treated as streams.
  • Flexible backup policy (both incremental and differential).
  • Multiple compression algorithm support (zlib, bzip2, xz).
  • Remove old backup automatically according the provided rules.
  • Multiple storage media support (Swift, local file system, SSH).
  • Remove old backup automatically according the provided parameters.
  • Manage multiple jobs (multiple backups on the same node).
  • Flush kernel buffered memory to disk.
  • Manage multiple jobs (i.e. multiple backups on the same node).
  • Synchronize backups and restore on multiple nodes.
  • Web user interface integrated with OpenStack Horizon.
  • Can execute scripts/commands before or after a job execution

Freezer is designed to reduce to the minimum I/O, CPU and Memory Usage. This is achieved by generating a data stream from tar (for archiving) and gzip (for compressing). Freezer segments the stream in a configurable chunk size (with the option –max-seg-size). The default segment size is 64MB, so it can be safely stored in memory, encrypted if the key is provided, and uploaded to Swift as a segment.

Multiple segments are sequentially uploaded using the Swift Manifest. All the segments are uploaded first, and then the Manifest file is uploaded too, so the data segments cannot be accessed directly. This ensures data consistency.

By keeping the segments small, in-memory, I/O usage is reduced. Also as there’s no need to store locally the final compressed archive (tar-gziped), no additional or dedicated storage is required for the backup execution. The only additional storage needed is the LVM snapshot size (set by default at 5GB). The lvm snapshot size can be set with the option –lvm-snapsize. It is important to not specify a too small snapshot size, because in case a quantity of data is being written to the source volume and consequently the lvm snapshot is filled up, then the data will be corrupted.

If more memory is available for the backup process, the maximum segment size can be increased. This will speed up the process. Please note that the segments must be smaller then 5GB, since that is the maximum object size in the Swift server.

On the other hand, if a server has small memory availability, the –max-seg-size option can be set to lower values. The unit of this option is in bytes.

Freezer, as with all OpenStack projects, is written with the following design guidelines in mind:

  • Component based architecture: Quickly add new behaviors
  • Highly available: Scale to very serious workloads
  • Fault tolerant: Isolated processes avoid cascading failures
  • Recoverable: Failures should be easy to diagnose, debug, and rectify
  • Open standards: Be a reference implementation for a community-driven api

This documentation is generated by the Sphinx toolkit and lives in the source tree. Additional documentation on Glance and other components of OpenStack can be found on the OpenStack wiki.