I corrected the IAM file to indicate that this case is a fast-track
and will timeout on 04/21/2010.
Thanks,
Brian
On 04/13/10 05:53 PM, Brian Cameron wrote:
Template Version: @(#)sac_nextcase 1.70 03/30/10 SMI
This information is Copyright (c) 2010, Oracle and/or its affiliates. All
rights reserved.
1. Introduction
1.1. Project/Component Working Name:
Time Slider Phase 2 (external backup)
1.2. Name of Document Author/Supplier:
Author: Brian Cameron
1.3 Date of This Document:
13 April, 2010
4. Technical Description
1. Introduction
1.1. Project/Component Working Name:
Time Slider Phase 2 (external backup)
1.2. Name of Document Author/Supplier:
Author: Erwann Chenede, Niall Power
1.3 Date of This Document:
Apr 8, 2010
4. Technical Description
Time slider's primary purpose is to enable automatic ZFS snapshots to be
taken for the user.
This project's goal is to provide an external backup solution on top of
Time Slider's local ZFS snapshot feature.
Within the time slider setup dialog the user will only need to specify a
path to an external filesystem where ZFS filesystem snapshots will be
replicated using rsync and the filesystems the user wishes to replicate.
This project makes the following high level changes :
- auto-snapshot:
Functional components responsible for scheduling, creation, deletion
and backup of snapshots are to be replaced by a more modular
scheduler provided by time slider. All interfaces are backward
compatible or replaced. These interfaces are currently uncommitted.
What remains of auto-snapshot are its SMF service instances which
define automatic snapshot schedules.
- time-slider:
Replacement of the functional components removed from auto-snapshot
via a snapshot daemon managed by the time-slider SMF service and
introduction of a plugin mechanism to allow various types of
time based backup strategies to be implemented.
4.1 Details:
4.1.1 Auto Snapshot :
auto-snapshot as previously described in (LSARC 2008/571),
consists of several SMF service instances (one per schedule: hourly,
daily, weekly, monthly& frequent by default).
A SMF service method reads the configuration properties for a given
schedule and creates a cron job that matches the schedule parameters
for each instance.
The cron job command is the auto-snapshot service method script
invoked with arguments that cause it to execute in a snapshot
creation operational mode. Additionally, the auto-snapshot SMF
service provides a project private hook to allow execution of an
administrator specified command immediately after creation of a
scheduled snapshot set, which allows for a basic backup or
replication mechanism.
As an example for illustrative purposes only, an administrator could
set the value of this property to:
"ssh host zfs receive -d poolB/received"
When a snapshot set is created the auto-snapshot service invokes
"/usr/sbin/zfs send [-i<previous>]<snapshot>"
for each snapshot in the set and pipes the output to the
administrator defined backup command which will receive the
snapshot stream through standard input redirection.
If it is the only existing snapshot matching the specified
dataset and schedule, a full snapshot stream is created.
Otherwise, if previous snapshots matching the dataset and schedule
exist, an incremental difference stream between the previous and
new snapshot is generated using the "-i" argument.
In the above example, snapshot streams will be received and
replicated on "host" under the target filesystem:
"poolB/received"
This feature is rather limited and has a number of drawbacks that
make it unsuitable for further enhancement. The major issues with
it are:
- It can only send data in ZFS snapshot stream format and the
mechanism to determine whether to send incremental or full
snapshot streams is poor. It would incorrectly send a full
stream instead of an incremental stream if all previous
snapshots matching a given schedule and dataset were
destroyed for example. Or worse, if the backup command
feature was enabled some time after the containing
auto-snapshot service was enabled and at least one snapshot
event occurred, then it would incorrectly send an
incremental stream instead of a full stream. In short, it
has no way of knowing about relevant, previous events.
- It can't operate asynchronously, it blocks when called and
the auto-snapshot service waits until the backup command
exits
- If a backup can't be performed at the moment of the creation
of a snapshot set for whatever reason, it can't be deferred
until a more appropriate time in the future.
Time slider phase 2 will replace this feature with a more modular
and flexible plugin framework.
For phase 2 of time slider, auto-snapshot will be greatly
simplified and the SMF method script used to start and stop it's
service instances will no longer include this snapshot taking
functionality nor will it create cron jobs in the role user
zfssnap's cron tab to go with it.
What will remain is the SMF instance along with it's private,
properties, and a simpler SMF start/stop method script that will
be limited to performing validation and sanity checking of the
configuration of each auto-snapshot instance. The Time Slider
service will process the configuration of each auto-snapshot SMF
instance and schedule snapshotting actions accordingly.
4.1.2 Time Slider :
Time slider will enhance the existing time slider smf service:
"svc:/application/time-slider:default" by managing a new
project private daemon (/usr/lib/time-sliderd). The daemon
replaces a number of existing features and provides new
additional features.
Replacement features of the time slider service daemon include:
- creation and management of automatic snapshots (both default
and custom defined) as defined by all enabled SMF instances of
the auto-snapshot service. This is a direct replacement for the
snapshot creation/destruction and cron scheduling features of
the existing auto-snapshot mechanism.
- Integrates the functionality of /usr/lib/time-slider-cleanup:
The auto-snapshot service performs no monitoring of available
space on the ZFS Zpools upon which it creates automatic
snapshots. auto-snapshot has retention rules that govern how
many snapshots are kept according to each schedule (eg. 12
monthly snapshots, 24 hourly snapshots) but a ZFS Zpool fills
up due to these snapshots grabbing too much space on the Zpool
before they reach their "sell by date" and get removed by the
auto-snapshot service then it will go unnoticed and
auto-snapshot will not take any remedial action.
The existing solution to this is provided by:
svc:/application/time-slider:default, which scheduled cron jobs
alongside those created by the auto-snapshot SMF instances.
The additional cron job invoked /usr/lib/time-slider-cleanup
at regular intervals to monitor Zpool capacity and take remedial
action if necessary to remove sufficient snapshots to maintain
a Zpool capacity. /usr/lib/time-slider-cleanup is a project
private interface, and all of the functionality of
/usr/lib/time-slider-cleanup is integrated into the new time
slider daemon
- Adds a D-Bus based messaging system.
Previously, when /usr/lib/time-slider-cleanup had to
perform remedial action to recover space on a ZPool,
it notified desktop users by executing the project private
interface /usr/lib/time-slider-notify
Doing so involved some nasty hacks including identifying
users logged into the system on a desktop session, su'ing
to their user id and scanning their desktop environment in
order to launch /usr/lib/time-slider-notify on their desktop
with appropriate arguments and environment variables to pop up
the relevant notification on their desktop.
The new time-slider service daemon makes use of D-Bus
(LSARC/2006/368) to provide a centralized system message
passing service. The message passing service provides
information on the severity of the situation and the actions
take by time-slider to remedy the situation. The notification
applet /usr/lib/time-slider-notify is no longer executed by
/usr/lib/time-slider-cleanup (nor it's functional replacement
within the new daemon: /usr/lib/time-sliderd). Instead it is
launched automatically as part of the desktop user's session
and upon startup, registers with the message service provided
by time slider on the system D-Bus.
It receives asynchronous notification when remedial actions
occur. The communication between the time-slider service and
applets listening on the system D-Bus is one way only from
service to applet. There are no interfaces defined to allow
applets or other D-Bus clients to execute commands on the
time-slider service.
New, additional features of the time slider service:
- Supports ZFS snapshot holds and deferred deletion:
Time slider now uses deferred deletion as introduced by PSARC/2009/297
which will add compatibility with snapshots that have user holds
placed on them.
- A flexible plugin mechanism that facilitates various backup or
replication mechanisms.
A new time slider plugin service is provided via SMF:
svc:/application/time-slider/plugin
The plugin service defines no "default" plugin instance.
Plugins are represented as instances of the plugin SMF
service. For example, the rsync plugin instance is specified by
the following project private SMF FMRI:
svc:/application/time-slider/plugin:rsync
Additional plugins can in future be added by creating new
instances of the pluginSMF service eg. a new plugin called
"my-custom-backup: would have the following SMF FMRI:
svc:/application/time-slider/plugin:my-custom-backup
The plugin mechanism and it's SMF interfaces are project
private.
As per the standard property inheritance model of SMF, all
plugin instances inherit SMF configuration property values from
svc:/application/time-slider/plugin. Property values can
optionally be overrided, and new configuration property values
unique to a specific plugin instance can be defined. This forms
the basis for time slider's plugin framework. All plugin SMF
instances and properties defined within are project private.
svc:/application/time-slider/plugin defines the following
properties. The following format is used to describe the
properties:
<property-group/property-name> type=defaultvalue
<plugin/trigger_command> string=Not Set
A fully expanded command path including all required arguments
for execution of a trigger command. The purpose of the
trigger command is to receive notification from time slider
when a scheduled snapshot event occurs. The trigger command
can opt to take immediate action or defer further action until
some later time. To assist the trigger command to identify
exactly what snapshots were taken and what auto-snapshot
schedule they belong to time-slider provides additional
project private environmental variables to the trigger
command:
AUTOSNAP_LABEL: the snapshot name component after the "@"
corresponding to the snapshot set just
created.
eg. "rp...@zfs-auto-snap:daily-abcdef
rpool/r...@zfs-auto-snap:daily-abcdef
rpool/ot...@zfs-auto-snap:daily-abcdef
In this case AUTOSNAP_LABEL would be:
"zfs-auto-snap:daily-abcdef"
AUTOSNAP_FMRI: the FMRI of the autosnapshot schedule instance
corresponding to the just created snapshot
set. For the above AUTOSNAP_LABEL example,
the AUTOSNAP_FMRI value would be:
svc:/system/filesystem/zfs/auto-snapshot:daily
PLUGIN_FMRI: the FMRI of the plugin instance that time-slider
is invoking the trigger command on behalf of eg.
svc:/application/time-slider/plugin:rsync
<plugin/verbose> boolean=false
Produce extra verbose output. Useful for debugging purposes.
<plugin/trigger_on> string= hourly,daily,weekly,monthly
Plugins may not be interested in certain snapshot schedules
eg. a frequent snapshot that takes place several times an
hour and with a very short lifespan on the system might not
be of interest to a nightly backup.
This project private property allows customization of what
snapshot schedules a plugin should get notified about. A
wildcard value of "All" is supported which matches all
schedules. Otherwise a comma separated list of auto-snapshot
schedule instance names is excepted. Only the instance name
of the FMRI and not the full FMRI is required eg. "daily"
instead of "svc:/system/filesystem/zfs/auto-snapshot:daily"
With the above information, plugins can identify the
snapshots involved and the schedules that match them and further
details if necessary. Depending on the specific implementation,
the plugin can decide whether to take immediate action, no
action, or defer action until a more appropriate time later.
Options available to plugins include tagging snapshots to
identify them for later operations, or if necessary, placing
a hold using ZFS holds to ensure the snapshot does not get
destroyed before the plugin has had an opportunity to take
action against it such as archival or replication. The
time-slider service will co-operate with any holds placed on
snapshots by using deferred deletion to destroy them, but it
becomes the responsibility of the plugin to later release the
previous hold once it no further need of the snapshot.
Once time slider has invoked a plugin instance's trigger
command, it will not block on the plugin's trigger command, so
that snapshot scheduling and other operations are not
disrupted while waiting for the plugin trigger command to
exit. Time slider will not however, invoke a given plugin
instances' trigger command again while a previous invocation
of the same command is still running.
Enabling and disabling of plugins is achieved by using
svcadm (1M) to enable or disable a specified plugin instance
eg.(/usr/sbin/svcadm enable svc:/application/time-slider/plugin:rsync
/usr/sbin/svcadm disable svc:/application/time-slider/plugin:rsync)
Time slider keeps track of the enabled status of plugins and
ignores plugins that are disabled or in SMF maintenance mode.
Enabling and disabling of plugins is project private and is managed
by the setup GUI (/usr/bin/time-slider-setup) and occurs when an
authorized user changes configuration to either enable or disable the
rsync plugin.
Time Slider will provide 2 project private plugins:
- An rsync plugin that will archive snapshots of tagged
filesystems to the specified backup target (a locally visible
filesystem path).
- a zfs-send plugin that provides feature equivalence and
compatibility for the project private feature present in
existing auto-snapshot SMF service instances. The plugin
will supply ZFS snapshot streams in the same format as the
existing auto-snapshot feature does for compatibility with
the auto-snapshot project private feature.
Further project private plugins can be added by creation of
additional instances of the SMF service:
svc:/application/time-slider/plugin
4.1.3 Rsync Plugin Details:
The rsync plugin consists of two components:
- A trigger command invoked by time-sliderd :
When a scheduled snapshot event occurs that the rsync
plugin is interested in, this script identifies the set of
ZFS filesystem snapshots that were just previously created.
The rsync plugin looks for a project private ZFS user
property:
"org.opensolaris:time-slider-rsync" amongst the ZFS filesystems
to identify those whose snapshots should be archived.
This allows fine-grained control over what what filesystems get
backed up.
From this, the trigger command determines the subset of the
snapshot set that should be backed up by rsync. It tags the
selected snapshots using a project private ZFS user property:
"org.opensolaris:time-slider-plugin:rsync"
It sets a value of "pending" to indicate that the snapshot
should be backed up as soon as possible by rsync.
- A backup command that performs the actual rsync backup:
This command is executed as a cron job run every 30 minutes.
The command is project private. The cron job is setup in
root's crontab when the rsync plugin instance is enabled and
online, and removed when disabled or offline.
The rsync-backup script also supports a project private direct
form of invocation. This enables the rsync backup to be operated
in both scheduled and adhoc manners. To ensure only one instance
of the rsync backup command is executing at any given moment,
the first running instance creates and obtains an exclusive,
non-blocking lock file under "/tmp/.time-slide/rsync-backup.lock"
The lock file is a project private interface. Subsequent parallel
invocations of the rsync-backup script will immediately exit when
they cannot exclusively lock the lock file. The lock on the file
is automatically released when the process owning it exits either
normally or abnormally.
If the configured rsync backup target is not accessible the
command simply exits. Otherwise it performs cleanup operations
on the backup target then proceeds to work through the queue of
snapshots that were previously tagged earlier with the project
private ZFS dataset user property:
"org.opensolaris:time-slider-plugin:rsync"
To provide user notification, it registers with the system D-Bus
service and sends D-Bus messages corresponding to it's status
and current activities. The D-Bus interfaces it provides for
consumption by the notification applet are project private.
The communication path via the system D-Bus is one way only and
there are no interfaces available to clients to run queries or
execute commands on the backup service. It's purpose is for
notification to the desktop applet only.
4.1.4 GUI Changes:
The configuration GUI (time-slider-setup) has been extended to
support configuration of the rsync plugin as an option, including
individual filesystem selection for rsync backup.
Because the rsync plugin backs up snapshots of ZFS filesystems
rather than the live filesystem, a strict subset policy is
enforced in the selection ie. It is not possible to select a
filesystem for rsync archival without it first being selected
for automatic snapshotting.
Desktop Notification Applet
The notification applet as previously ARC'ed under LSARC 2008/571
is now automatically launched as part of a user's desktop session.
On startup it registers with the system D-Bus service, and listens to
project private D-Bus system events that inform it when the
rsync plugin is active and the activities that it is performing.
It uses these notifications to provide appropriate visual notification
on the user's desktop.
4.1.5 Security:
As SMF services, configuration of auto-snapshot, time-slider and
time slider plugin services instances is restricted to authorized
users and is enforced by the SMF administration commands such
as svcadm(1M) and svccfg(1M). Unauthorized and non-privileged
users can not modify, enable or disable these services.
The setup GUI requires the Primary Administrator profile to
launch to ensure the user is authorized to perform configuration
of all features of time slider.
Configuration relating to the datasets time-slider operates on
both in terms of snapshotting and archival using the
rsync plugin is based on ZFS dataset user properties. The
services will only snapshot datasets and backup snapshots on
appropriately tagged datasets. Tagging any type of ZFS dataset
is a restricted operation performed using the zfs(1M) command
which restrict these operations to authorized users only.
To reduce the risk of potentially sensitive data being backed up
to untrusted locations, the rsync plugin only permits backups to
locally attached storage such as external storage devices or
trusted network filesystems with local mount points (eg. NFS)
Backup to remote devices using network protocols is not
supported. Furthermore, the administrator has full control over
what ZFS filesystems get backed up using rsync via the time slider
setup GUI (/usr/bin/time-slider-setup), which allows individual
ZFS filesystem selection/deselection.
Please refer to :
http://jdswiki.ireland.sun.com/twiki/bin/view/JDS/ZFSBackupToRM
4.2 Bug/RFE Number(s):
6942008
4.5 Interfaces:
New Imported Interfaces:
--------------------
ZFS snapshot holds (PSARC/2009/297)
D-Bus Message Bus System (LSARC/2006/368)
Add rsync command to Solaris WOS (PSARC/2006/642)
New Exported Interfaces:
--------------------
svc:/application/time-slider/plugin:rsync Project Private
svc:/application/time-slider/plugin:zfs-send Project Private
/usr/lib/time-sliderd Project Private
/usr/lib/time-slider/plugins/rsync/rsync-trigger Project Private
/usr/lib/time-slider/plugins/rsync/rsync-backup Project Private
/usr/lib/time-slider/plugins/zfssend/zfssend Project Private
/etc/dbus-1/system.d/time-slider.conf Project Private
Removed Interfaces:
--------------------
/usr/lib/time-slider-cleanup Uncommitted
5. Documentation
snapshot manager :
http://jdswiki.ireland.sun.com/twiki/bin/view/JDS/ZFSBackupToRM
auto snapshot service :
http://blogs.sun.com/timf/
6. Resources and Schedule
6.1. Projected Availability
Solaris Next
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
Desktop C-Team
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
Desktop
6.5. ARC review type: OnePager
6.6. ARC Exposure: open
_______________________________________________
opensolaris-arc mailing list
[email protected]
_______________________________________________
opensolaris-arc mailing list
[email protected]
