zumastor

Section: Maintenance Commands (8)
Index Return to Main Contents
 

NAME

zumastor - block device snapshot and replication management

 

SYNOPSIS

zumastor define volume volume snapdev orgdev [options]
zumastor define master volume [options]
zumastor define source volume host [options]
zumastor define target volume host[:port] [options]
zumastor forget volume volume
zumastor forget target volume host
zumastor snapshot volume [options]

zumastor replicate volume host [options]
zumastor resize volume [options]
zumastor status [volume [snap]] [options]

 

DESCRIPTION

Zumastor controls snapshotting and remote replication of Linux block devices (volumes), and works with most common filesystems.

A snapshot is a view of the volume as it existed at a point in time. The administrator can trigger a snapshot manually, or ask Zumastor to take scheduled snapshots periodically (e.g. daily or hourly). Up to 64 snapshots are supported per volume. All snapshots for a particular volume are stored in a second block device, called the snapshot store, and can be accessed via virtual devices provided by ddsnap(8). Zumastor mounts the snapshots for volume 'foo' at /var/run/zumastor/volumes/foo-snapshots, and optionally also in the special directory .snapshot inside the root of the volume. Zumastor can also export the snapshots via NFS and/or Samba without manual edits of NFS or Samba configuration files.

Replication means sending snapshots from a local (or upstream) machine to a remote (or downstream) machine. When a volume is first replicated, its entire contents are sent. When it is replicated a second time, only the changed blocks are sent. The snapshot data can also be compressed during transmission to save bandwidth. Not all snapshots on a volume are replicated; you can do hourly snapshots, but only replicate once per day. On downstream machines, the downstream volume is always identical to the latest received snapshot. When a new snapshot arrives from upstream, the main volume is flipped transparantly to the new snapshot. If the main volume was being exported via NFS, clients who access that volume via NFS see the new snapshot contents as expected.

 

COMMANDS

define volume
volume snapdev orgdev [-i|--initialize] [-m|--metadev metadev] [-b|--blocksize blocksize] [-c|--chunksize chunksize] [-k|--cachesize cachesize] [-o|--mountopts mount options] [-p|--mountpoint mountpoint] [-s|--snappath snapshout path]

Define a new zumastor volume named volume based on the underlying volumes orgdev and snapdev. If specified, the metadev will be used for snapshot metadata storage (especially useful for NVRAM acceleration). If the initialize option is used, the newly created volume data will be overwritten with zeros, overwriting all data on the origin device.

The snapshot block and chunk sizes can be specified with the blocksize and chunksize options, respectively. They may only differ if separate metadata and snapshot devices are specified. Note that these values must be specified as powers of two and must be larger than 512 bytes.

The amount of RAM dedicated to the snapshot store cache defaults to min(128MB, system RAM/4), and can be tuned manually with the cachesize option. For instance, to increase the cache size to 512MB, use --cachesize 512M.

A mountpoint may be defined for the volume with the mountpoint option. It must be a directory with no other file system mounted there. Mount options that apply to that mount point may be defined with the mountopts option. The snapshot mountpoint under which the volume snapshots are mounted can be defined with the snappath option.

define master
volume [-h|--hourly snapshots] [-d|--daily snapshots] [-w|--weekly snapshots] [-m|--monthly snapshots] [-c|--custom snapshots] [-e|--export] [-p|--samba] [-s|--dotsnapshot] [-n|--no-snapmount]

Used after define volume to specify the snapshot rotation for the volume. Each of snapshots is the maximum number of snapshots that will be held for the respective snapshot rotation interval. If this volume was previously a replication target, removes the source definition, since it is now a master. If volume is already defined, just updates the rotation limits.

By default, each newly created snapshot is mounted under the snapshot mountpoint specified by define volume, with each snapshot named for its creation time. But if the no-snapmount option is specified, the newly created snapshot will NOT be mounted. If the export option is used, each mounted snapshot will be exported via NFS. If the samba option is used, each mounted snapshot will be bind mounted to a directory following Samba's '@GMT-creation-time' naming convention under the volume mount point, and will be accessible via Samba's previous version interface. If the dotsnapshot option is used, the snapshot mountpoint will be bind mounted to the .snapshot directory under the volume mount point. If the no-snapmount option is specified, the export, samba, and dotsnapshot options will be ignored.

define source
volume host[:port]] [-p|--period interval] [-y|--yes] [-n|--name remote_volume]

Used after define volume to specify the upstream host that is expected to replicate snapshots to this volume. If the volume was previously a master volume, removes the master definition, since it is now a replication target. If the optional interval (in seconds) is specified, the upstream server will be asked for updates at this interval and when the volume is started. It should be smaller than the automatic replication interval configured for this target on the upstream host. The name option allows you to specify a different remote_volume name on the upstream host. The yes option answers yes to all prompts.

define target
volume host[:port] [-p|--period interval] [-n|--name remote_volume] [-t|--test feature]

Used after define volume to specify a downstream host to which the volume will be replicated to. If the optional interval (in seconds) is specified, the target (downstream) server will be replicated to at the given interval. The name option allows you to specify a different remote_volume name on the downstream host. The test option is used for testing purpose.

forget volume
volume

Stop automatic snapshotting and/or replication for volume and remove it from the zumastor database.

forget target
volume host

Stop automatic replication for a volume target and remove the target from the zumastor database.

snapshot
volume [hourly|daily|weekly|monthly|custom]

Explicitly initiate a volume snapshot within the specified snapshot rotation. If no rotation type is specified, a manual snapshot is taken. A manual snapshot exists outside of the normal replication cycle is taken and a device mapper device is created. You must check the log file /var/log/zumastor/volume/master.log to determine the snapshot number. A device will be created on /dev/mapper/volume(snapshot_number). For manual snapshots, the usecount will drop to zero and the device will not be created after a zumastor is restarted.

replicate
volume host [-s|--snapnum snap] [-d|--delay seconds]

Explicitly initiate a volume replication cycle to the specified host. If snap is specified then the snapshot with id snap will be replicated, unless a more recent snapshot has already been replicated. If snap is omitted then the most recent volume snapshot will be replicated. If seconds is specified, the script will sleep for the specified number of seconds before triggering a replication cycle. This is used internally to support periodic replication. The default is 0, meaning immediately.

resize
volume [-o|--origin newsize] [-s|--snapshot newsize] [-m|--metadata newsize]

Resize the origin/snapshot/metadata device of a zumastor volume to newsize.

status
[volume [snap]] [-u|--usage]

Display the status of all the volumes if given no arguments. If a volume is given, only information for that volume is shown. If a snapshot id, snap, is given in additional, only the status of that single snapshot is displayed. The --usage argument displays additional snapshot usage information.

 

EXAMPLES

# Initializing snapshot storage device, creating an origin volume named test located in /dev/mapper/test, and zeroing out that device
zumastor define volume test /dev/sysvg/vol /dev/sysvg/snap

# Creating a snapshot schedule that will keep the last 5 hours as snapshots

zumastor define master test -h 24 -d 7

 

TERMINOLOGY

snapshot - a virtually instant copy of a defined collection of data created at a particular instant in time.
origin volume - One of two block devices underlying a virtual snapshot device. This volume is mapped one-to-one to a snapshot origin virtual device. The virtual device could be removed and the underlying origin volume accessed directly, at the risk of losing the integrity of any snapshots sharing data with the origin.
snapshot store - The other block device underlying a virtual snapshot device. This volume contains data chunks that were copied from the origin in order to preserve the integrity of snapshot data, or were written directly to the snapshot store via a snapshot virtual device. It also contains all metadata required to keep track of which snapshot store chunks belong to which snapshots.
chunk - a user-definable binary multiple of 4K block size.
exception - a chunk of data in the snapshot store, belonging to one or more snapshots.
 

SEE ALSO

ddsnap(8), ddraid(8), dmsetup(8)

zumastor project page: http://code.google.com/p/zumastor/  

FUTURE ADDITIONS

In the future, we will go further in the direction of hiding the device names, by coming up with a proper library API for creating the virtual devices so we don't need the clumsy dmsetup command any more or the even more clumsy libdevmapper interface, or worse yet, the devmapper ioctl interface. Our library interface might even offer the option of creating a virtual device with no name, it just gives the program a FD for a device that we set (somehow) to be a virtual origin or snapshot. No device name ever appears on the filesystem. I have some misgivings about this idea because we then invite the situation where we can have multiple virtual devices on the same host, referring to the same snapshot. This ought to work for fine for our ddsnap and ddraid devices because they are designed as cluster devices, but I dunno. I'm still mulliing over the right thing to do there. This is just to let everybody know that the deficiencies of the current scheme are known, they are being thought about, and for now the result is some visible warts.  

BUGS

Please report bugs at http://code.google.com/p/zumastor or mail them to zumastor@googlegroups.com.  

VERSION

This man page is current for version 0.5 of hotcakes.  

AUTHORS

Man page written by Jane Chiu and Jyoti Sood.
 

CREDITS

ddsnap is distributed under the GNU public license, version 2. See the file COPYING for details.
This program uses zlib compression library and popt library. Many people sent patches, lent machines, gave advice and were generally helpful.
 

THANKS

Thanks to Google, Red Hat and Sistina Software for supporting this work. Special thanks to: Mike Todd, Joseph Dries, Douglas Merril and Matthew O'Keefe.
The home page of zumastor is http://code.google.com/p/zumastor. This site may cover questions unanswered by this manual page. Mailing lists for support and development are available at zumastor@googlegroups.com


 

Index

NAME
SYNOPSIS
DESCRIPTION
COMMANDS
EXAMPLES
TERMINOLOGY
SEE ALSO
FUTURE ADDITIONS
BUGS
VERSION
AUTHORS
CREDITS
THANKS

This document was created by man2html, using the manual pages.
Time: 18:45:01 GMT, January 29, 2008