zfs discuss - Mar 2010 - Using zfs-auto-snapshot for automatic backups

The recent discussion of backing up ZFS got me thinking about using
the auto snapshot service to do backups.

My current method of doing backups is to send / recv the data pool to
external USB devices, but I haven''t been doing backups of the rpool. I
think that doing a send to the data pool, which will then get backed
up to USB is probably fine.

I''m a bit new to smf, so chances are that I did this wrong. I did:

# svccfg export zfs/auto-snapshot > snap-manifest.xml

I edited the file and added a new instance called rpool-backup with
the following save command:
<propval name=''backup-save-cmd''
type=''astring'' value=''/usr/sbin/zfs
recv -du -F tank/rpool''/>

I imported it via svccfg and verified that it was listed in svcs:
# svccfg import -V snap-manifest.xml
# svcs auto-snapshot:rpool-backup
disabled        4:13:15 svc:/system/filesystem/zfs/auto-snapshot:rpool-backup
# zfs create tank/rpool
# zfs set compress=on tank/rpool
# zfs allow -u zfssnap receive,mount,create tank/rpool
# svcadm enable auto-snapshot:rpool-backup

I enabled the new instance and checked the log file, which contained:
Last snapshot for
svc:/system/filesystem/zfs/auto-snapshot:rpool-backup taken on [ no
snapshot taken yet ]
which was greater than the 1 days schedule. Taking snapshot now.
svccfg: Permission denied.
svcadm: svc:/system/filesystem/zfs/auto-snapshot:rpool-backup:
Permission denied.
Previous snap not found of rpool, taking full backup.

My questions are:
 - There must be an easier way to add or modify an instance in smf,
right? If so, how?
 - What is causing the various permission denied errors from svccfg and svcadm?
 - zfs-auto-snap isn''t sending any of the existing snapshots to the
target, so it''s not really a full backup. Did I miss something when I
created the smf instance?

-B

-- 
Brandon High : bhigh at freaks.com

I hit the wrong button when moderating the post to zfs-auto-snapshot@
mailing list. I''m forwarding the original mail from Brandon below.

Summarising Brandon''s questions:

 * how to best create SMF instances on an existing service
 * why are there permission errors when running a new instance created
   via svccfg export
 * how to get existing snapshots to the receiving pool 

I usually add SMF instances using ''svccfg -s <service> add
myinstance''

Looking at the errors, it looks like SMF isn''t exporting the values for
action_authorization or value_authorization in the SMF manifest it
produces, resulting the service not being allowed to set values in
svccfg when it runs as ''zfssnap''.

Have a look at /var/svc/manifest/system/filesystem/auto-snapshot.xml and
read smf_security(5) for more on those properties.

Finally, the service will only send/recv snapshots that it has created
itself, rather than any existing snapshots - the auto-snapshots will
reference all current data, but won''t have the history contained in
those other snapshots.

You could seed the backup pool with existing snapshots using a manual
zfs send -R, and then continue with incremental snapshots using
zfs-auto-snapshot.

	cheers,
			tim

-------- Forwarded Message --------
From: Brandon High <bhigh at freaks.com>
To: ZFS discuss <zfs-discuss at opensolaris.org>, zfs-auto-snapshot
<zfs-auto-snapshot at opensolaris.org>
Subject: Using zfs-auto-snapshot for automatic backups
Date: Mon, 08 Mar 2010 13:16:02 +0000

The recent discussion of backing up ZFS got me thinking about using
the auto snapshot service to do backups.

My current method of doing backups is to send / recv the data pool to
external USB devices, but I haven''t been doing backups of the rpool. I
think that doing a send to the data pool, which will then get backed
up to USB is probably fine.

I''m a bit new to smf, so chances are that I did this wrong. I did:

# svccfg export zfs/auto-snapshot > snap-manifest.xml

I edited the file and added a new instance called rpool-backup with
the following save command:
<propval name=''backup-save-cmd''
type=''astring'' value=''/usr/sbin/zfs
recv -du -F tank/rpool''/>

I imported it via svccfg and verified that it was listed in svcs:
# svccfg import -V snap-manifest.xml
# svcs auto-snapshot:rpool-backup
disabled        4:13:15 svc:/system/filesystem/zfs/auto-snapshot:rpool-backup
# zfs create tank/rpool
# zfs set compress=on tank/rpool
# zfs allow -u zfssnap receive,mount,create tank/rpool
# svcadm enable auto-snapshot:rpool-backup

I enabled the new instance and checked the log file, which contained:
Last snapshot for
svc:/system/filesystem/zfs/auto-snapshot:rpool-backup taken on [ no
snapshot taken yet ]
which was greater than the 1 days schedule. Taking snapshot now.
svccfg: Permission denied.
svcadm: svc:/system/filesystem/zfs/auto-snapshot:rpool-backup:
Permission denied.
Previous snap not found of rpool, taking full backup.

My questions are:
 - There must be an easier way to add or modify an instance in smf,
right? If so, how?
 - What is causing the various permission denied errors from svccfg and svcadm?
 - zfs-auto-snap isn''t sending any of the existing snapshots to the
target, so it''s not really a full backup. Did I miss something when I
created the smf instance?

-B

(Subscribing to the zfs-auto-snapshot list to avoid moderation hold.)

On Mon, Mar 8, 2010 at 1:47 PM, Tim Foster <Tim.Foster at sun.com>
wrote:
> I usually add SMF instances using ''svccfg -s <service> add
myinstance''
I tried that, but there that doesn''t create/copy the property groups.
Do I have to manually duplicate the settings from another instance?
Apologies for the somewhat off-topic line of questioning, but I can''t
find the correct way do do what I want, namely create a new instance
using an existing one as a template. My import/export exercise was an
attempt to do that.
> Looking at the errors, it looks like SMF isn''t exporting the
values for
> action_authorization or value_authorization in the SMF manifest it
> produces, resulting the service not being allowed to set values in
> svccfg when it runs as ''zfssnap''.
I don''t think that''s the problem, the values are the same as
the
''daily'' instance.

$ svccfg -s zfs/auto-snapshot:rpool-backup listprop|grep ^general
general                            framework
general/action_authorization       astring
general/value_authorization        astring
general/enabled                    boolean  true
> Have a look at /var/svc/manifest/system/filesystem/auto-snapshot.xml and
> read smf_security(5) for more on those properties.
> You could seed the backup pool with existing snapshots using a manual
> zfs send -R, and then continue with incremental snapshots using
> zfs-auto-snapshot.
That''s what I''ve wound up doing, using the rpool-backup
snapshot that
was created during the initial run. It would be nice if there was a
way to make the initial full option do a recursive full send
initially, but it wasn''t that hard to do manually.

-B

-- 
Brandon High : bhigh at freaks.com

On Mon, Mar 8, 2010 at 1:47 PM, Tim Foster <Tim.Foster at sun.com>
wrote:
> Looking at the errors, it looks like SMF isn''t exporting the
values for
> action_authorization or value_authorization in the SMF manifest it
> produces, resulting the service not being allowed to set values in
> svccfg when it runs as ''zfssnap''.
After playing around a bit, I found the right way to verify this:

$ svcprop -p general zfs/auto-snapshot:rpool-backup
general/action_authorization astring solaris.smf.manage.zfs-auto-snapshot
general/value_authorization astring solaris.smf.manage.zfs-auto-snapshot
general/enabled boolean true
general/entity_stability astring Unstable

This is exactly the output that I''m getting for zfs/auto-snapshot:daily

I''m still seeing errors from svccfg before and after the zfs send.
This isn''t affecting any of the default instances, since they
don''t
use backup-save-cmd.

$ svcprop -p start/user zfs/auto-snapshot:rpool-backup
zfssnap
$ svcprop -p stop/user zfs/auto-snapshot:rpool-backup
zfssnap

/etc/user_attr contains:
zfssnap::::type=role;auths=solaris.smf.manage.zfs-auto-snapshot;profiles=ZFS
File System Management

The instance runs as zfssnap and the user *should* be able to change
values in smf, right?

-B

-- 
Brandon High : bhigh at freaks.com

On Tue, 2010-03-09 at 18:02 +0000, Brandon High wrote:
> The instance runs as zfssnap and the user *should* be able to change
> values in smf, right?
Yes - I think that''s a bug - it looks like the SMF zfs/ propgroup
should
have value_authorization set as well.

You can workaround this by doing:

# svccfg -s auto-snapshot setprop zfs/value_authorization = astring:
solaris.smf.manage.zfs-auto-snapshot

Sorry about that!

	cheers,
			tim

On Tue, Mar 9, 2010 at 6:43 PM, Tim Foster <Tim.Foster at sun.com>
wrote:
> You can workaround this by doing:
>
> # svccfg -s auto-snapshot setprop zfs/value_authorization = astring:
solaris.smf.manage.zfs-auto-snapshot
This seems to have worked, I''m seeing the snapshots in tank/rpool now.

There are a few changes that I''d like to suggest for auto-snapshot,
but perhaps you can suggest another way of doing what I''m trying.

I had initially set zfs/keep to 1, but this prevented the backup from
working. Because the destroy_older_snapshots is called before
take_backup is called, there''s no common snapshot to send from. If the
order was reversed, then keep could be set to 1 successfully.

The second change is the way that recursive backups work. Because I''m
trying to back up rpool, I initially had fs-name set to "rpool", but
this included rpool/dump and rpool/swap, which I didn''t really care
about. It would be nice if com.sun:auto-snapshot:instance could still
be used to disable snapshots when specifying a path to start at.

A third change is the way that sends are done. I''d like to get all the
snapshots from the source filesystem. Perhaps a third type of backup
("inclusive"?) which uses "zfs send -I" to send all
snapshots from the
source filesystem?

Yes another nice change would be to have all snapshots which don;t
exist on the source removed from the backup target, but that may be
out of scope since the backup-save-cmd isn''t necessarily doing a
receive on the same host.

I''d be willing to take a stab at adding these features, but given that
auto-snapshot is about to die I''m not sure that there would be much
point to it other than for my own purposes.

-B

-- 
Brandon High : bhigh at freaks.com