From tomg at mcclatchyinteractive.com  Tue Nov  3 06:05:26 2009
From: tomg at mcclatchyinteractive.com (Tom Georgoulias)
Date: Tue, 03 Nov 2009 09:05:26 -0500
Subject: [zfs-auto-snapshot] can't get backup-save-cmd to send snapshots
 to	remote server
In-Reply-To: <4AD86BF8.7080307@mcclatchyinteractive.com>
References: <4AD5D002.2090801@mcclatchyinteractive.com>	<4AD6B52A.1040501@fss.aprec.ru>	<4AD76B95.6040508@mcclatchyinteractive.com>	<4AD7A220.8090202@sun.com>
	<4AD86BF8.7080307@mcclatchyinteractive.com>
Message-ID: <4AF038A6.1020809@mcclatchyinteractive.com>

For the sake of those who are experiencing the same problem as I was and 
find this thread looking for answers, here's the fix I used.

1.  Modified the zfssnap role on the sender server to include a home 
directory where I could store ssh keys.

rolemod -d /path/to/home zfssnap

2.  Created ssh keys for zfssnap on the sender server in the new home 
directory.

su - zfssnap

ssh-keygen

3. Created a new user account on the receiving server that would be 
responsible for receiving the snapshots.

4. Added the zfssnap ssh key to the new user's authorized_keys file to 
enable ssh from zfssnap at sender to newuser at receiver without a password 
prompt.

5.  Used "zfs allow" command to give newuser at receiver sufficient 
permissions to receive the snapshot and apply them to the filesystem

zfs allow newuser, create,destroy,mount,snapshot,receive,rollback 
zfs_filesystem_name

6.  Removed the pfexec from backup-save-cmd:

zfs/backup-save-cmd = "/usr/bin/ssh newuser at receiver /usr/sbin/zfs recv 
-d -F zfs_filesystem_name

Snapshot sends/receives are working properly on my servers now.

Tom

From Niall.Power at Sun.COM  Sun Nov 15 23:26:28 2009
From: Niall.Power at Sun.COM (Niall Power)
Date: Mon, 16 Nov 2009 18:26:28 +1100
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion in
	snv 128
Message-ID: <4B00FEA4.7050700@sun.com>

This is a heads up for user of Tim's zfs-auto-snapshot auto snapshot 
service currently delivered
in Solaris Nevada and OpenSolaris. As of build 128 the zfs-auto-snapshot 
scripts are being replaced
by a rewritten daemon (time-sliderd).
Time-sliderd will continue to support the existing SMF 
auto-snapshot:<schedule> service instances
as it's configuration mechanism so for most users there should be no 
significant differences noticeable.
Some of the options will no longer be supported however since they are 
either obsolete or too
specifically tied to the zfs-auto-snapshot implementation to make them 
portable.

Stuff that will work:
- Default out of the box schedules (frequent, hourly, daily, weekly, 
monthly)
- Custom schedules

SMF properties that will be supported:
- interval
- period
- keep

SMF properties that won't be supported
- "offset" The time-slider daemon schedules snapshots based on relative
   times rather that absolute times which makes it more suitable for systems
   that do not have constant 24/7 uptime so this feature isn't so relevant
   anymore (it only got implemented recently in zfs-auto-snapshot also)

- "label" Dropping it allows naming shemes to be simplified and
   enforces uniqueness when SMF tries to import an auto-snapshot instance

- backup/backup-save-cmd/backup-lock
  We plan to implement an rsync based backup mechanism that allows backups
  to be browsed like a proper filesystem instead of having binary 
snapshot blobs
  that are explicitly classified as unstable/volatile by zfs(1)

For those who want to use time-slider without going through the GUI, simply
enable/configure (or create) the auto-snapshot instances you need then 
enable
the time-slider SMF service. time-slider will pick up the enabled 
auto-snapshot
instances and schedule snapshots for them.

For folks who prefer to continue using zfs-auto-snapshot, you will need to
remove SUNWgnome-time-slider and install the existing zfs-auto-snapshot
packages instead.

Comments/questions welcome ;)

Cheers,
Niall.


From tomg at mcclatchyinteractive.com  Mon Nov 16 05:38:25 2009
From: tomg at mcclatchyinteractive.com (Tom Georgoulias)
Date: Mon, 16 Nov 2009 08:38:25 -0500
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
 in	snv 128
In-Reply-To: <4B00FEA4.7050700@sun.com>
References: <4B00FEA4.7050700@sun.com>
Message-ID: <4B0155D1.1010401@mcclatchyinteractive.com>

On 11/16/2009 02:26 AM, Niall Power wrote:
> This is a heads up for user of Tim's zfs-auto-snapshot auto snapshot
> service currently delivered
> in Solaris Nevada and OpenSolaris. As of build 128 the zfs-auto-snapshot
> scripts are being replaced
> by a rewritten daemon (time-sliderd).

Thank you for the warning.  :)

> - backup/backup-save-cmd/backup-lock
> We plan to implement an rsync based backup mechanism that allows backups
> to be browsed like a proper filesystem instead of having binary snapshot
> blobs
> that are explicitly classified as unstable/volatile by zfs(1)

I'd like to know more about this mechanism and have a lot of questions 
about it, since this functionality is very important to me. 
(Personally, I think it is one of the most under-appreciated parts of 
Opensolaris.)

Since you opened the floor for questions, I do have a few:

1. Is there a conceptual overview on the project page where I can get a 
better understanding of how it will work?

2.  Will this rsync mechanism be available and functional in build 128 
(or whenever time-sliderd is released), or is it still in the 
planning/devel stage?

3.  Will the new mechanism help manage snapshots on the receiving side, 
so that both sender/receiver have the same set of snapshots?

4.  Will we still to have the ability to make the most recently sent 
snapshot mounted and available on the receiving side, similar to using 
the "zfs recv -d -F" command?

Thanks,
Tom

From Tim.Foster at Sun.COM  Mon Nov 16 05:52:31 2009
From: Tim.Foster at Sun.COM (Tim Foster)
Date: Mon, 16 Nov 2009 13:52:31 +0000
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
 in snv 128
In-Reply-To: <4B0155D1.1010401@mcclatchyinteractive.com>
References: <4B00FEA4.7050700@sun.com>
	<4B0155D1.1010401@mcclatchyinteractive.com>
Message-ID: <1258379552.2158.8.camel@igyo>

On Mon, 2009-11-16 at 08:38 -0500, Tom Georgoulias wrote:
> On 11/16/2009 02:26 AM, Niall Power wrote:
> > This is a heads up for user of Tim's zfs-auto-snapshot auto snapshot
> > service currently delivered
> > in Solaris Nevada and OpenSolaris. As of build 128 the zfs-auto-snapshot
> > scripts are being replaced
> > by a rewritten daemon (time-sliderd).

Yep, I for one welcome our new time-sliderd masters.

I had a peek at the implementation Niall sent to me way back, and it
looked ok.  SUNWzfs-auto-snapshot was creaking at the seams, and as soon
as we started needing to mess about with $IFS, it was probably time to
start looking at a better solution.

A few things I'd note (echoing Tom's comments)

 * Removing zfs/backup seems like an ill-considered move

   - by all means, add an additional rsync-based backup
   system, but taking away this feature seems wrong
   (the send-stream format itself isn't stable, but zfs recving
   it on a zfs dataset on the remote means you're never storing
   that format in binary blobs anywhere)  We had a few interesting
   solutions enabled by the zfs/backup code, it'd be a shame not
   to port the functionality.

   rsync just seems so "90's" in comparison with zfs send/recv,
   but does get over the problem that zfs isn't available everywhere
   yet.  I'd like to see both solutions available.

 * Hopefully it's going to be as good, if not better in terms
   of the number of processes spawned: has it been tested on large
   systems?

 * Will it be possible to install without any dependencies on X?

	cheers,
			tim


> Thank you for the warning.  :)
> 
> > - backup/backup-save-cmd/backup-lock
> > We plan to implement an rsync based backup mechanism that allows backups
> > to be browsed like a proper filesystem instead of having binary snapshot
> > blobs
> > that are explicitly classified as unstable/volatile by zfs(1)
> 
> I'd like to know more about this mechanism and have a lot of questions 
> about it, since this functionality is very important to me. 
> (Personally, I think it is one of the most under-appreciated parts of 
> Opensolaris.)
> 
> Since you opened the floor for questions, I do have a few:
> 
> 1. Is there a conceptual overview on the project page where I can get a 
> better understanding of how it will work?
> 
> 2.  Will this rsync mechanism be available and functional in build 128 
> (or whenever time-sliderd is released), or is it still in the 
> planning/devel stage?
> 
> 3.  Will the new mechanism help manage snapshots on the receiving side, 
> so that both sender/receiver have the same set of snapshots?
> 
> 4.  Will we still to have the ability to make the most recently sent 
> snapshot mounted and available on the receiving side, similar to using 
> the "zfs recv -d -F" command?
> 
> Thanks,
> Tom
> _______________________________________________
> zfs-auto-snapshot mailing list
> zfs-auto-snapshot at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-auto-snapshot



From Niall.Power at Sun.COM  Tue Nov 17 01:08:54 2009
From: Niall.Power at Sun.COM (Niall Power)
Date: Tue, 17 Nov 2009 20:08:54 +1100
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
	in	snv 128
In-Reply-To: <4B0155D1.1010401@mcclatchyinteractive.com>
References: <4B00FEA4.7050700@sun.com>
	<4B0155D1.1010401@mcclatchyinteractive.com>
Message-ID: <4B026826.5040101@sun.com>

Hi Tom,


Tom Georgoulias wrote:
> On 11/16/2009 02:26 AM, Niall Power wrote:
>> This is a heads up for user of Tim's zfs-auto-snapshot auto snapshot
>> service currently delivered
>> in Solaris Nevada and OpenSolaris. As of build 128 the zfs-auto-snapshot
>> scripts are being replaced
>> by a rewritten daemon (time-sliderd).
>
> Thank you for the warning.  :)

My pleasure :)
>
>> - backup/backup-save-cmd/backup-lock
>> We plan to implement an rsync based backup mechanism that allows backups
>> to be browsed like a proper filesystem instead of having binary snapshot
>> blobs
>> that are explicitly classified as unstable/volatile by zfs(1)
>
> I'd like to know more about this mechanism and have a lot of questions 
> about it, since this functionality is very important to me. 
> (Personally, I think it is one of the most under-appreciated parts of 
> Opensolaris.)
Yep, it seems that zfs-auto-snapshot has a seemingly small but loyal 
following.
>
> Since you opened the floor for questions, I do have a few:
>
> 1. Is there a conceptual overview on the project page where I can get 
> a better understanding of how it will work?
There isn't really right now. It's something that has kind of evolved 
over time: We kept building and enhancing time-slider,
with an eye towards future code reusablility, and got to the point where 
we had enough code written to make implementation
of a snapshot manager pretty simple. It's been a one man operation so I 
didn't get around to writing up the overview (adding
to my TODO list) but I will try to capture it here for you:

Time-sliderd is a persistent daemon that currently does 3 major activities:
- Takes snapshot according to the defined auto-snapshot SMF instances
- Cleans up snapshots based on retention rules (the keep value) and 
optionally (enabled by default) removes snapshots that
  are determined to be permanently zero sized.
- Performs emergency remedial cleanup actions if a storage pool runs too 
low on available space by deleting snapshots before
  their normal expiration rules apply. When this happens, users are 
notified via the desktop and syslog events are generated.

Operation of the time-sliderd service
- The daemon is managed by SMF and is managed using the standard 
svcadm(1) command to stop, start and refresh the service.
- On startup the daemon scans for enabled auto-snapshot:<schedule> 
instance, both default and custom.
  Initialisation/Rescan:
- For each schedule the daemon determines when the last snapshot was 
taken for a given schedule and when the next one is due
  (immediately due if no snapshot for a defined schedule exists). This 
happens a separate immortal thread to allow the main thread
  to receive signals, be woken up, send notifications etc.
- Armed with a list of snapshots that are due for the various schedules, 
it goes to sleep until the soonest snapshot becomes due.
- When woken it checks that pool capacity is not dangerously high. If it 
is it performs an emergency cleanup until pool capacity
  gets back down to an acceptable level. Users are notified via the 
system D-BUS message bus which a listening applet receives.
- It then takes the scheduled snapshot
- For the schedule corresponding to the snapshot it has just taken, it 
cleans out old snapshots that have expired (or are determined
  to be permanently zero sized)
- It then figures out when the next snapshot is due and goes to sleep 
again until the next snapshot becomes due.

Some other important points/differences from zfs-auto-snapshot:

The default schedules (frequent, hourly, daily, weekly and monthly) are 
given special treatment in that there is an order of
precedence/dominance. Monthly>Weekly>Daily>Hourly>Frequent. For  example 
if a daily snapshot is due in 5 minutes and
an hourly snapshot is due in 35 minutes then the daily snapshot will get 
taken, and subordinate schedules will get realigned
with the dominant schedule, resulting in the hourly snapshot being taken 
65 minutes later instead of 35, making it align 1
hour after the daily scheduele. This attempts to address one of the 
issues identified with zfs-auto-snapshot where several
snapshot schedules activated at the same time (eg. frequent  hourly and 
daily all happening at midnight).
The result is somewhat like a tape measure where you don't see mm or cm 
increments on the same spot as a whole metre
increment. This improves visualisation in nautilus time-slider view 
because it eliminates multiple snapshots being crowded
together.
The above does not apply to any custom defined auto-snapshot schedules.

Another issue from a desktop usage model perspective with 
zfs-auto-snapshot was that it's dependence on cron made for
a less than ideal solution. Cron's model assumes 24x7 uptime because you 
have to ensure the system is booted and running
for the scheduled action to occur, otherwise it will be missed and cron 
won't know about it. This made taking monthly or
weekly schedules particularly difficult and we had to enchance 
zfs-auto-snapshot to check for these missed snapshots and
take them if neccesary. But if for example your weekly snapshot was 6 
days overdue, it would result in only 1 day's gap between
2 weekly snapshots. Time-sliderd overcomes this by being persistent and 
using relative time instead of absolutes to manage
snapshot schedules. For example, instead of always taking the weekly 
snapshot on Sunday at 12:00am, it it will take it 7 days
after the last weekly snapshot, whenever that happens to be, or as soon 
as possible if the weekly snapshot was missed.

Monthly snapshot handling is improved because it determines the exact 
number of days in each month and adjusts accordingly
(zfs-auto-snapshot assumes 30 days in every month meaning monthly 
snapshots don't occur on the same day number of
each month)


>
> 2.  Will this rsync mechanism be available and functional in build 128 
> (or whenever time-sliderd is released), or is it still in the 
> planning/devel stage?
It's in the planning stage right now and we hope to begin implementation 
in the coming weeks.
>
> 3.  Will the new mechanism help manage snapshots on the receiving 
> side, so that both sender/receiver have the same set of snapshots?
It will, but will do so rather independently of the local storage pools 
set of snapshots. They will not be treated as mirrors, and the receiving
end will be adjusted to make best use of the available storage space. If 
it's really big, we can store loads of snapshots, if it's small, we store
less. Note also that these are not zfs snapshots, but will be rsync 
backups that resemble snapshots which has pros and cons which we
can cover seperately (the list is a bit long :)

>
> 4.  Will we still to have the ability to make the most recently sent 
> snapshot mounted and available on the receiving side, similar to using 
> the "zfs recv -d -F" command?

Not as things stand since we will not be sending actual zfs snapshot 
binary streams to the receiving end. It will however be accessible
via normal filesystem navigation since it is necessary to have the 
external/remote storage target mounted and available to rsync with.
The nautilus time-slider view will also be enhanced to enable browsing 
of the rsync backups either seamlessly with local snapshots,
or seperately.

I hope this answers most of your questions. Feel free to shoot more at me.
And thanks for not flaming :)

Thanks,
Niall.
>
> Thanks,
> Tom


From Niall.Power at Sun.COM  Tue Nov 17 01:23:51 2009
From: Niall.Power at Sun.COM (Niall Power)
Date: Tue, 17 Nov 2009 20:23:51 +1100
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
 in snv 128
In-Reply-To: <1258379552.2158.8.camel@igyo>
References: <4B00FEA4.7050700@sun.com>
	<4B0155D1.1010401@mcclatchyinteractive.com>
	<1258379552.2158.8.camel@igyo>
Message-ID: <4B026BA7.4050105@sun.com>

Tim Foster wrote:
> On Mon, 2009-11-16 at 08:38 -0500, Tom Georgoulias wrote:
>   
>> On 11/16/2009 02:26 AM, Niall Power wrote:
>>     
>>> This is a heads up for user of Tim's zfs-auto-snapshot auto snapshot
>>> service currently delivered
>>> in Solaris Nevada and OpenSolaris. As of build 128 the zfs-auto-snapshot
>>> scripts are being replaced
>>> by a rewritten daemon (time-sliderd).
>>>       
>
> Yep, I for one welcome our new time-sliderd masters.
>   
Cheers, I shall let you live so :-)
> I had a peek at the implementation Niall sent to me way back, and it
> looked ok.  SUNWzfs-auto-snapshot was creaking at the seams, and as soon
> as we started needing to mess about with $IFS, it was probably time to
> start looking at a better solution.
>
> A few things I'd note (echoing Tom's comments)
>
>  * Removing zfs/backup seems like an ill-considered move
>
>    - by all means, add an additional rsync-based backup
>    system, but taking away this feature seems wrong
>    (the send-stream format itself isn't stable, but zfs recving
>    it on a zfs dataset on the remote means you're never storing
>    that format in binary blobs anywhere)  We had a few interesting
>    solutions enabled by the zfs/backup code, it'd be a shame not
>    to port the functionality.
>   

I think at the least it needs to be redesigned to some extent to
fit in with the time-sliderd daemon. I no longer see the use of the
backup-lock property for example, which seems to me like an
implementation artifact and not a true feature interface. I think
we could implement perhaps implement this more cleanly within
the time-sliderd design than the existing solution.

>    rsync just seems so "90's" in comparison with zfs send/recv,
>    but does get over the problem that zfs isn't available everywhere
>    yet.  I'd like to see both solutions available.
>
>  * Hopefully it's going to be as good, if not better in terms
>    of the number of processes spawned: has it been tested on large
>    systems?
>   
I haven't tested out on large systems but I am confident it will be an 
improvement
since it doesn't have the startup costs associated with each invocation 
of zfs-auto-snapshot's
method, and lists of snaphots, pools etc. are cached by the daemon so it 
doesn't need to
rescan all that stuff. Additionally it only deals with one schedule at a 
time so it doesn't
experience spikes when several schedules overlap. Snapshots are taken 
recursively as is the
case for zfs-auto-snapshot currently. Certainly, the overall performance 
from running on
my laptop and workstation seems improved as the spikes have been 
flattened out somewhat.
>  * Will it be possible to install without any dependencies on X?
>   
I looked into this and it's not currently possible because the 
notification mechanism that
it depends on (D-BUS notification provided by SUNWpython26-notify) 
depends on gnome-panel
and therefore the gnome stack and therefore X.
On the flip side though, since Nevada is essentially going away soon and 
the liveCD or autoinstaller
image being the default all dependencies will be supplied by the default 
install image.

Cheers,
Niall.
> 	cheers,
> 			tim
>
>
>   
>> Thank you for the warning.  :)
>>
>>     
>>> - backup/backup-save-cmd/backup-lock
>>> We plan to implement an rsync based backup mechanism that allows backups
>>> to be browsed like a proper filesystem instead of having binary snapshot
>>> blobs
>>> that are explicitly classified as unstable/volatile by zfs(1)
>>>       
>> I'd like to know more about this mechanism and have a lot of questions 
>> about it, since this functionality is very important to me. 
>> (Personally, I think it is one of the most under-appreciated parts of 
>> Opensolaris.)
>>
>> Since you opened the floor for questions, I do have a few:
>>
>> 1. Is there a conceptual overview on the project page where I can get a 
>> better understanding of how it will work?
>>
>> 2.  Will this rsync mechanism be available and functional in build 128 
>> (or whenever time-sliderd is released), or is it still in the 
>> planning/devel stage?
>>
>> 3.  Will the new mechanism help manage snapshots on the receiving side, 
>> so that both sender/receiver have the same set of snapshots?
>>
>> 4.  Will we still to have the ability to make the most recently sent 
>> snapshot mounted and available on the receiving side, similar to using 
>> the "zfs recv -d -F" command?
>>
>> Thanks,
>> Tom
>> _______________________________________________
>> zfs-auto-snapshot mailing list
>> zfs-auto-snapshot at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-auto-snapshot
>>     
>
>
> _______________________________________________
> zfs-auto-snapshot mailing list
> zfs-auto-snapshot at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-auto-snapshot
>   


From Tim.Foster at Sun.COM  Tue Nov 17 02:04:07 2009
From: Tim.Foster at Sun.COM (Tim Foster)
Date: Tue, 17 Nov 2009 10:04:07 +0000
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
 in snv 128
In-Reply-To: <4B026BA7.4050105@sun.com>
References: <4B00FEA4.7050700@sun.com>
	<4B0155D1.1010401@mcclatchyinteractive.com>
	<1258379552.2158.8.camel@igyo> <4B026BA7.4050105@sun.com>
Message-ID: <1258452247.2502.15.camel@igyo>

On Tue, 2009-11-17 at 20:23 +1100, Niall Power wrote:
> >  * Removing zfs/backup seems like an ill-considered move

> I think at the least it needs to be redesigned to some extent to
> fit in with the time-sliderd daemon.

Yep, totally agree - I don't care at all about the old implementation,
but would just like there to be a feature that does the same thing:

Optional zfs incremental or entire sends of the snapshot stream for a
given SMF instance, and an ability for the user to specify what the
system should do with that stream (be it ssh to a remote machine & zfs
receive, stream to a tape device, cat to /dev/null, whatever)

>  I no longer see the use of the
> backup-lock property for example, which seems to me like an
> implementation artifact and not a true feature interface.

Yep.

>  I think
> we could implement perhaps implement this more cleanly within
> the time-sliderd design than the existing solution.

Great: I have no problems torching the existing solution - it did a
reasonable job in it's time, but I'm more than happy to retire it.

> >  * Hopefully it's going to be as good, if not better in terms
> >    of the number of processes spawned: has it been tested on large
> >    systems?

> I haven't tested out on large systems but I am confident it will be an 
> improvement
> since it doesn't have the startup costs associated with each invocation 
> of zfs-auto-snapshot's
> method, and lists of snaphots, pools etc. are cached by the daemon so it 
> doesn't need to
> rescan all that stuff. Additionally it only deals with one schedule at a 
> time so it doesn't
> experience spikes when several schedules overlap. Snapshots are taken 
> recursively as is the
> case for zfs-auto-snapshot currently. Certainly, the overall performance 
> from running on
> my laptop and workstation seems improved as the spikes have been 
> flattened out somewhat.

Sounds good, thanks for the detail.


> >  * Will it be possible to install without any dependencies on X?
> >   
> I looked into this and it's not currently possible because the 
> notification mechanism that
> it depends on (D-BUS notification provided by SUNWpython26-notify) 
> depends on gnome-panel
> and therefore the gnome stack and therefore X.

Can it just check for those imports and disable notification if that
code isn't available?

try:
    import pynotify
except ImportError:
    CAN_HAZ_NOTIFICATION = False

> On the flip side though, since Nevada is essentially going away soon and 
> the liveCD or autoinstaller
> image being the default all dependencies will be supplied by the default 
> install image.


Yeah, until someone decides they don't want X :-)

	cheers,
			tim


From Darren.Moffat at Sun.COM  Tue Nov 17 04:09:44 2009
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Tue, 17 Nov 2009 12:09:44 +0000
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
	in snv_128
Message-ID: <4B029288.4020707@Sun.COM>

You can't just remove the 'zfs send' based backup it is documented as 
part of the architecture of the feature in LSARC/2008/571:

"The service can perform a backup command at each invocation of the cron 
job - the admin specifies what command to run at the end of a pipe that 
starts with "zfs send <filesystem>@<snapshot>", with the option of 
sending an incremental stream from the previous periodic snapshot."

I have uses for both a 'zfs send' and an rsync based backup.  So instead 
of removing the 'zfs send' based one add rsync as an additional option.

It would also be useful to be able to specify options for the 'zfs 
send', such as -D for dedup or other recent additions to 'zfs send'.

-- 
Darren J Moffat

From Niall.Power at Sun.COM  Tue Nov 17 05:17:31 2009
From: Niall.Power at Sun.COM (Niall Power)
Date: Wed, 18 Nov 2009 00:17:31 +1100
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
	in snv_128
In-Reply-To: <4B029288.4020707@Sun.COM>
References: <4B029288.4020707@Sun.COM>
Message-ID: <4B02A26B.3060701@sun.com>

Darren J Moffat wrote:
> You can't just remove the 'zfs send' based backup it is documented as 
> part of the architecture of the feature in LSARC/2008/571:

The exported interface associated with it documented as uncommitted:

Exported Interfaces:
--------------------
auto-snapshot :
  svc:/system/filesystem/zfs/auto-snapshot:daily	Uncommitted
  svc:/system/filesystem/zfs/auto-snapshot:default	Uncommitted
  svc:/system/filesystem/zfs/auto-snapshot:frequent	Uncommitted
  svc:/system/filesystem/zfs/auto-snapshot:hourly	Uncommitted
  svc:/system/filesystem/zfs/auto-snapshot:monthly	Uncommitted
  svc:/system/filesystem/zfs/auto-snapshot:weekly	Uncommitted

I was under the impression that uncommitted meant that the associated interfaces were
subject to change or removal

Thanks,

Niall.
>
> "The service can perform a backup command at each invocation of the 
> cron job - the admin specifies what command to run at the end of a 
> pipe that starts with "zfs send <filesystem>@<snapshot>", with the 
> option of sending an incremental stream from the previous periodic 
> snapshot."
>
> I have uses for both a 'zfs send' and an rsync based backup.  So 
> instead of removing the 'zfs send' based one add rsync as an 
> additional option.
>
> It would also be useful to be able to specify options for the 'zfs 
> send', such as -D for dedup or other recent additions to 'zfs send'.



From Darren.Moffat at Sun.COM  Tue Nov 17 05:23:22 2009
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Tue, 17 Nov 2009 13:23:22 +0000
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
	in snv_128
In-Reply-To: <4B02A26B.3060701@sun.com>
References: <4B029288.4020707@Sun.COM> <4B02A26B.3060701@sun.com>
Message-ID: <4B02A3CA.1060206@Sun.COM>

Niall Power wrote:
> Darren J Moffat wrote:
>> You can't just remove the 'zfs send' based backup it is documented as 
>> part of the architecture of the feature in LSARC/2008/571:
> 
> The exported interface associated with it documented as uncommitted:
> 
> Exported Interfaces:
> --------------------
> auto-snapshot :
>  svc:/system/filesystem/zfs/auto-snapshot:daily    Uncommitted
>  svc:/system/filesystem/zfs/auto-snapshot:default    Uncommitted
>  svc:/system/filesystem/zfs/auto-snapshot:frequent    Uncommitted
>  svc:/system/filesystem/zfs/auto-snapshot:hourly    Uncommitted
>  svc:/system/filesystem/zfs/auto-snapshot:monthly    Uncommitted
>  svc:/system/filesystem/zfs/auto-snapshot:weekly    Uncommitted
> 
> I was under the impression that uncommitted meant that the associated 
> interfaces were
> subject to change or removal

Depends on the type of release and some notification is generally needs 
to be given as well as getting ARC approval.

Please don't remove the feature is is actually very useful.  If you want 
to add rsync as well then I'm all for that as I have use cases where 
both could be used on some snapshots.

-- 
Darren J Moffat

From Niall.Power at Sun.COM  Tue Nov 17 05:37:50 2009
From: Niall.Power at Sun.COM (Niall Power)
Date: Wed, 18 Nov 2009 00:37:50 +1100
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
	in snv_128
In-Reply-To: <4B02A3CA.1060206@Sun.COM>
References: <4B029288.4020707@Sun.COM> <4B02A26B.3060701@sun.com>
	<4B02A3CA.1060206@Sun.COM>
Message-ID: <4B02A72E.5010402@sun.com>

Darren J Moffat wrote:
> Niall Power wrote:
>> Darren J Moffat wrote:
>>> You can't just remove the 'zfs send' based backup it is documented 
>>> as part of the architecture of the feature in LSARC/2008/571:
>>
>> The exported interface associated with it documented as uncommitted:
>>
>> Exported Interfaces:
>> --------------------
>> auto-snapshot :
>>  svc:/system/filesystem/zfs/auto-snapshot:daily    Uncommitted
>>  svc:/system/filesystem/zfs/auto-snapshot:default    Uncommitted
>>  svc:/system/filesystem/zfs/auto-snapshot:frequent    Uncommitted
>>  svc:/system/filesystem/zfs/auto-snapshot:hourly    Uncommitted
>>  svc:/system/filesystem/zfs/auto-snapshot:monthly    Uncommitted
>>  svc:/system/filesystem/zfs/auto-snapshot:weekly    Uncommitted
>>
>> I was under the impression that uncommitted meant that the associated 
>> interfaces were
>> subject to change or removal
>
> Depends on the type of release and some notification is generally 
> needs to be given as well as getting ARC approval.
I consulted John Fischer and my understanding based on that was that we 
were OK to proceed as planned with the
removal of SUNWzfs-auto-snapshot (also an uncommitted interface)
>
> Please don't remove the feature is is actually very useful.  If you 
> want to add rsync as well then I'm all for that as I have use cases 
> where both could be used on some snapshots.
>
Please bear in mind that what has been done is a reimplementation for 
the auto-snapshot service from the ground up, written in python now as 
opposed to ksh, and with a design
that hopefully makes it more robust and extensible. Every feature needs 
to be re implemented and it is not simply being removed intentionally. 
I've tried to make the transition as
seamless and smooth as possible but the fact is that there are 
interfaces in the auto-snapshot instances that really shouldn't be there 
at all and some clean up is in order. And in
the case of the "backup-save-cmd" feature, there is scope for improvement.

Also please remember that the desktop team's intention has always been 
to provide a desktop oriented snapshot solution and zfs-auto-snapshot 
provided the backend solution.
The interfaces for the user from our perspective are the the GUIs we 
provide, which remain unchanged.

Thanks,
Niall

From tomg at mcclatchyinteractive.com  Tue Nov 17 08:09:59 2009
From: tomg at mcclatchyinteractive.com (Tom Georgoulias)
Date: Tue, 17 Nov 2009 11:09:59 -0500
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
 in snv_128
In-Reply-To: <4B02A72E.5010402@sun.com>
References: <4B029288.4020707@Sun.COM>
	<4B02A26B.3060701@sun.com>	<4B02A3CA.1060206@Sun.COM>
	<4B02A72E.5010402@sun.com>
Message-ID: <4B02CAD7.6090601@mcclatchyinteractive.com>

>> Darren J Moffat wrote:
>> Please don't remove the feature is is actually very useful. If you
>> want to add rsync as well then I'm all for that as I have use cases
>> where both could be used on some snapshots.
>>

On 11/17/2009 08:37 AM, Niall Power wrote:
And in
> the case of the "backup-save-cmd" feature, there is scope for improvement.
>
> Also please remember that the desktop team's intention has always been
> to provide a desktop oriented snapshot solution and zfs-auto-snapshot
> provided the backend solution.

Reading your description (thanks for providing that) and the resulting 
discussion, it sounds like the tool is going to be very desktop oriented 
in the future, at the expense of server use.  I guess I understand why 
that is happening, given the developer resource constraints and the fact 
that you are assigned to the desktop team.

Perhaps it is time to break the two apart and have a server oriented 
daemon that does replication and snapshot management that is independent 
of the desktop and X dependencies.  Going from a zfs snapshot type 
backup to rsync blobs isn't an option for our environment, it would be a 
major step backwards in functionality and a huge blow to our disaster 
recovery efforts.  As I said before, I think that the zfs-auto-snapshot 
service is one of the most under appreciated pieces of Opensolaris.  The 
ability to have snapshot replication between two storage servers without 
having to pay for expensive netapp filers and snapmirror is awesome. 
Why throw that benefit away?  Wouldn't it be wise to preserve that 
functionality as a dedicated service or daemon and make it part of the 
openstorage initiative?

Tom

From Darren.Moffat at Sun.COM  Tue Nov 17 08:22:15 2009
From: Darren.Moffat at Sun.COM (Darren J Moffat)
Date: Tue, 17 Nov 2009 16:22:15 +0000
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
	in snv_128
In-Reply-To: <4B02A72E.5010402@sun.com>
References: <4B029288.4020707@Sun.COM> <4B02A26B.3060701@sun.com>
	<4B02A3CA.1060206@Sun.COM> <4B02A72E.5010402@sun.com>
Message-ID: <4B02CDB7.7060707@Sun.COM>

Niall Power wrote:
>> Please don't remove the feature is is actually very useful.  If you 
>> want to add rsync as well then I'm all for that as I have use cases 
>> where both could be used on some snapshots.
>>
> Please bear in mind that what has been done is a reimplementation for 
> the auto-snapshot service from the ground up, written in python now as 
> opposed to ksh, and with a design
> that hopefully makes it more robust and extensible. Every feature needs 
> to be re implemented and it is not simply being removed intentionally. 

Users don't care that you reimplemented it.  Users care about the 
functionality and you are attempting to remove something that you have 
been told users want and already use.

> Also please remember that the desktop team's intention has always been 
> to provide a desktop oriented snapshot solution and zfs-auto-snapshot 
> provided the backend solution.
> The interfaces for the user from our perspective are the the GUIs we 
> provide, which remain unchanged.

Again users don't care about the politics or organisation of the 
development teams they care about the features.

The feature exists and is delivered today I'm asking you to continue 
delivering it.   If you can't do that then you aren't ready to integrate 
the rewrite, unless you get ARC approval to remove the feature.

-- 
Darren J Moffat

From brett at librum.org  Tue Nov 17 09:45:32 2009
From: brett at librum.org (Brett Eisenberg)
Date: Tue, 17 Nov 2009 09:45:32 -0800
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
	in snv_128
In-Reply-To: <4B02CDB7.7060707@Sun.COM>
References: <4B029288.4020707@Sun.COM> <4B02A26B.3060701@sun.com>
	<4B02A3CA.1060206@Sun.COM> <4B02A72E.5010402@sun.com>
	<4B02CDB7.7060707@Sun.COM>
Message-ID: <F12FC589-F5DC-4D50-9945-F68A4FFB64A6@librum.org>

Just to echo earlier sentiments, as a Sun customer who has utilized Tim's excellent zfs-auto-snapshot in a production environment for more than 2 years, there are two critical issues I have with the current proposed solution:

1) Dependency on X is intolerable. We use this on production systems. Production systems do not have X. EOF.

2) Adding rsync as an option is great; removing zfs send results in a loss in functionality to existing users and is incongruent with a future that includes zfs crypto.

Darren is 100% correct.

best,
Brett

On Nov 17, 2009, at 8:22 AM, Darren J Moffat wrote:

> Niall Power wrote:
>>> Please don't remove the feature is is actually very useful.  If you want to add rsync as well then I'm all for that as I have use cases where both could be used on some snapshots.
>>> 
>> Please bear in mind that what has been done is a reimplementation for the auto-snapshot service from the ground up, written in python now as opposed to ksh, and with a design
>> that hopefully makes it more robust and extensible. Every feature needs to be re implemented and it is not simply being removed intentionally. 
> 
> Users don't care that you reimplemented it.  Users care about the functionality and you are attempting to remove something that you have been told users want and already use.
> 
>> Also please remember that the desktop team's intention has always been to provide a desktop oriented snapshot solution and zfs-auto-snapshot provided the backend solution.
>> The interfaces for the user from our perspective are the the GUIs we provide, which remain unchanged.
> 
> Again users don't care about the politics or organisation of the development teams they care about the features.
> 
> The feature exists and is delivered today I'm asking you to continue delivering it.   If you can't do that then you aren't ready to integrate the rewrite, unless you get ARC approval to remove the feature.
> 
> -- 
> Darren J Moffat
> _______________________________________________
> zfs-auto-snapshot mailing list
> zfs-auto-snapshot at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-auto-snapshot
> 
> !DSPAM:1000,4b02cded194251714510420!
> 


From Niall.Power at Sun.COM  Thu Nov 19 21:32:52 2009
From: Niall.Power at Sun.COM (Niall Power)
Date: Fri, 20 Nov 2009 16:32:52 +1100
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
	in snv_128
In-Reply-To: <4B02CDB7.7060707@Sun.COM>
References: <4B029288.4020707@Sun.COM> <4B02A26B.3060701@sun.com>
	<4B02A3CA.1060206@Sun.COM> <4B02A72E.5010402@sun.com>
	<4B02CDB7.7060707@Sun.COM>
Message-ID: <4B062A04.3060607@sun.com>

OK, So given the protests about these changes we will back out the 
changes. It is to late for build 128 unfortunately
so it will have to happen in build 129. I'm studying the current backup 
feature in more detail and will try to come up
with a proposal that hopefully addresses the issue of the users of this 
feature satisfactorily.

I've made some additional comments below.

Darren J Moffat wrote:
> Niall Power wrote:
>>> Please don't remove the feature is is actually very useful.  If you 
>>> want to add rsync as well then I'm all for that as I have use cases 
>>> where both could be used on some snapshots.
>>>
>> Please bear in mind that what has been done is a reimplementation for 
>> the auto-snapshot service from the ground up, written in python now 
>> as opposed to ksh, and with a design
>> that hopefully makes it more robust and extensible. Every feature 
>> needs to be re implemented and it is not simply being removed 
>> intentionally. 
>
> Users don't care that you reimplemented it.  Users care about the 
> functionality and you are attempting to remove something that you have 
> been told users want and already use.
>
You are making some broad sweeping, presumptions, blanket statements 
about the user base here.
This is a mailing list *specific* to zfs-auto-snapshot (not 
time-slider), which existed way before it was ever integrated into 
Solaris Nevada/OpenSolaris, and as such it's user base is specifically 
interested in the features offered by zfs-auto-snapshot and not 
interested in time-slider. Therefore the opinions posted on this mailing 
list represent a subset of the overall user base. Plenty of people enjoy
time-slider, and wish to see it improve as a desktop oriented solution. 
This not politics as you describe it, this is reality.

Cheers,
Niall


>> Also please remember that the desktop team's intention has always 
>> been to provide a desktop oriented snapshot solution and 
>> zfs-auto-snapshot provided the backend solution.
>> The interfaces for the user from our perspective are the the GUIs we 
>> provide, which remain unchanged.
>
> Again users don't care about the politics or organisation of the 
> development teams they care about the features.
>
> The feature exists and is delivered today I'm asking you to continue 
> delivering it.   If you can't do that then you aren't ready to 
> integrate the rewrite, unless you get ARC approval to remove the feature.
>


From Niall.Power at Sun.COM  Thu Nov 19 21:43:42 2009
From: Niall.Power at Sun.COM (Niall Power)
Date: Fri, 20 Nov 2009 16:43:42 +1100
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
 in snv_128
In-Reply-To: <F12FC589-F5DC-4D50-9945-F68A4FFB64A6@librum.org>
References: <4B029288.4020707@Sun.COM> <4B02A26B.3060701@sun.com>
	<4B02A3CA.1060206@Sun.COM> <4B02A72E.5010402@sun.com>
	<4B02CDB7.7060707@Sun.COM>
	<F12FC589-F5DC-4D50-9945-F68A4FFB64A6@librum.org>
Message-ID: <4B062C8E.3070709@sun.com>

Hi Brett,

Brett Eisenberg wrote:
> Just to echo earlier sentiments, as a Sun customer who has utilized Tim's excellent zfs-auto-snapshot in a production environment for more than 2 years, there are two critical issues I have with the current proposed solution:
>   
Fair comment, but I feel it is also only fair to point out that you have 
been using this feature for at least one year
before it integrated into any Solaris/OpenSolaris based product, before 
it was supported by Sun. The first time this integrated
into a Sun supported product was OpenSolaris 2008.11. To run it on 
Solaris 10, you need to roll your own package from the
sources.
> 1) Dependency on X is intolerable. We use this on production systems. Production systems do not have X. EOF.
>   
It's a packaging dependency and not a runtime one. Is this an issue for 
you? It should be pointed out also
that the OpenSolaris install includes X by default as part of the 
"entire"  incorporation.

> 2) Adding rsync as an option is great; removing zfs send results in a loss in functionality to existing users and is incongruent with a future that includes zfs crypto.
>   

Duly noted. Can you tell me a bit more about about what kind of target 
you send these snapshot streams to? Are they imported on the
receving end or stored as binary files for example?

Cheers,
Niall.
> Darren is 100% correct.
>
> best,
> Brett
>
> On Nov 17, 2009, at 8:22 AM, Darren J Moffat wrote:
>
>   
>> Niall Power wrote:
>>     
>>>> Please don't remove the feature is is actually very useful.  If you want to add rsync as well then I'm all for that as I have use cases where both could be used on some snapshots.
>>>>
>>>>         
>>> Please bear in mind that what has been done is a reimplementation for the auto-snapshot service from the ground up, written in python now as opposed to ksh, and with a design
>>> that hopefully makes it more robust and extensible. Every feature needs to be re implemented and it is not simply being removed intentionally. 
>>>       
>> Users don't care that you reimplemented it.  Users care about the functionality and you are attempting to remove something that you have been told users want and already use.
>>
>>     
>>> Also please remember that the desktop team's intention has always been to provide a desktop oriented snapshot solution and zfs-auto-snapshot provided the backend solution.
>>> The interfaces for the user from our perspective are the the GUIs we provide, which remain unchanged.
>>>       
>> Again users don't care about the politics or organisation of the development teams they care about the features.
>>
>> The feature exists and is delivered today I'm asking you to continue delivering it.   If you can't do that then you aren't ready to integrate the rewrite, unless you get ARC approval to remove the feature.
>>
>> -- 
>> Darren J Moffat
>> _______________________________________________
>> zfs-auto-snapshot mailing list
>> zfs-auto-snapshot at opensolaris.org
>> http://mail.opensolaris.org/mailman/listinfo/zfs-auto-snapshot
>>
>> !DSPAM:1000,4b02cded194251714510420!
>>
>>     
>
> _______________________________________________
> zfs-auto-snapshot mailing list
> zfs-auto-snapshot at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-auto-snapshot
>   


From tomg at mcclatchyinteractive.com  Fri Nov 20 04:49:47 2009
From: tomg at mcclatchyinteractive.com (Tom Georgoulias)
Date: Fri, 20 Nov 2009 07:49:47 -0500
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
 in snv_128
In-Reply-To: <4B062A04.3060607@sun.com>
References: <4B029288.4020707@Sun.COM>
	<4B02A26B.3060701@sun.com>	<4B02A3CA.1060206@Sun.COM>
	<4B02A72E.5010402@sun.com>	<4B02CDB7.7060707@Sun.COM>
	<4B062A04.3060607@sun.com>
Message-ID: <4B06906B.3020407@mcclatchyinteractive.com>

On 11/20/2009 12:32 AM, Niall Power wrote:
> OK, So given the protests about these changes we will back out the
> changes.

I'm very happy to hear this.  Thank you!!

I'm studying the current backup
> feature in more detail and will try to come up
> with a proposal that hopefully addresses the issue of the users of this
> feature satisfactorily.

What about my suggestion to create a server-oriented daemon that 
provides this service alongside the time-sliderd daemon that 
accomplishes more of the features that you are including?  That could 
give the desktop team the flexibility it needs to make timeslider work 
well in the GUI, while those of us who need zfs snapshot replication for 
our storage servers will have a solution that is tailored for server 
applications.

Tom

From carson at taltos.org  Fri Nov 20 13:44:05 2009
From: carson at taltos.org (Carson Gaspar)
Date: Fri, 20 Nov 2009 13:44:05 -0800
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
 in snv_128
In-Reply-To: <4B06906B.3020407@mcclatchyinteractive.com>
References: <4B029288.4020707@Sun.COM>	<4B02A26B.3060701@sun.com>	<4B02A3CA.1060206@Sun.COM>	<4B02A72E.5010402@sun.com>	<4B02CDB7.7060707@Sun.COM>	<4B062A04.3060607@sun.com>
	<4B06906B.3020407@mcclatchyinteractive.com>
Message-ID: <4B070DA5.8010108@taltos.org>

Adding my US$.02:

The service as you have described it is mostly unusable. Using DBUS as 
the only alerting mechanism is basically useless for anyone who runs 
servers. If DBUS were one optional, pluggable notification option, this 
might be almost sane.

As for the backup command facility, the existing zfs send hooks are too 
primitive to be very useful in a robust replication setting (as opposed 
to its original intended purpose of just dumping streams to USB disks). 
So I don't particularly care if they vanish, as I've already rolled my 
own code. But Sun should really consider a robust remote replication 
service if they want us to buy fewer NetApps.

Of course if Sun remains delusional that Solaris on the desktop is going 
to provide a revenue stream of any real size, there's little we can do 
but watch the company continue to fail.

-- 
Carson

From Niall.Power at Sun.COM  Fri Nov 20 17:50:11 2009
From: Niall.Power at Sun.COM (Niall Power)
Date: Sat, 21 Nov 2009 12:50:11 +1100
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
 in snv_128
In-Reply-To: <4B070DA5.8010108@taltos.org>
References: <4B029288.4020707@Sun.COM> <4B02A26B.3060701@sun.com>
	<4B02A3CA.1060206@Sun.COM> <4B02A72E.5010402@sun.com>
	<4B02CDB7.7060707@Sun.COM> <4B062A04.3060607@sun.com>
	<4B06906B.3020407@mcclatchyinteractive.com>
	<4B070DA5.8010108@taltos.org>
Message-ID: <4B074753.2080606@sun.com>

Hi Carson,

Thanks for your comments.

[...]

Carson Gaspar wrote:
> Adding my US$.02:
>
> The service as you have described it is mostly unusable. Using DBUS as 
> the only alerting mechanism is basically useless for anyone who runs 
> servers. If DBUS were one optional, pluggable notification option, 
> this might be almost sane.
DBUS is just a a messaging bus, it doesn't produce alerts itself. There 
is a corresponding desktop applet that catches this notification which 
is not intended for people who run
servers, but it is perfectly possible to write a non GUI alert mechanism 
to the system bus and receive events and produce an appropriate type of 
alert. The service also sends alert messages to syslog
with appropriate levels of urgency depending on the severity of the problem.
And last but not least, there is currently __no equivalent 
functionality__ that provides anything resembling this in 
zfs-auto-snapshot. zfs-auto-snapshot does not monitor pool usage, take 
remedial actions to reduce pool usage, or generate any type of alert 
when the pool becomes full. This is specific to time-slider.
So based on your statement, it would sound like the existing 
zfs-auto-snapshot is unusable to you also.
>
> As for the backup command facility, the existing zfs send hooks are 
> too primitive to be very useful in a robust replication setting (as 
> opposed to its original intended purpose of just dumping streams to 
> USB disks).
This would pretty much sum up my view of the current backup command 
facility, which is why I initially didn't consider implementing it a 
priority. There are however, as we have seen,
people who find it useful enough to object to it's removal.
> So I don't particularly care if they vanish, as I've already rolled my 
> own code. But Sun should really consider a robust remote replication 
> service if they want us to buy fewer NetApps.
Have you looksed at the Amber Road storage systems, like the Sun Storage 
7000? They do remote replication.

Cheers,
Niall
>
> Of course if Sun remains delusional that Solaris on the desktop is 
> going to provide a revenue stream of any real size, there's little we 
> can do but watch the company continue to fail.
>


From Niall.Power at Sun.COM  Sun Nov 22 19:09:10 2009
From: Niall.Power at Sun.COM (Niall Power)
Date: Mon, 23 Nov 2009 14:09:10 +1100
Subject: [zfs-auto-snapshot] Heads up: SUNWzfs-auto-snapshot obsoletion
 in snv_128
In-Reply-To: <4B06906B.3020407@mcclatchyinteractive.com>
References: <4B029288.4020707@Sun.COM> <4B02A26B.3060701@sun.com>
	<4B02A3CA.1060206@Sun.COM> <4B02A72E.5010402@sun.com>
	<4B02CDB7.7060707@Sun.COM> <4B062A04.3060607@sun.com>
	<4B06906B.3020407@mcclatchyinteractive.com>
Message-ID: <4B09FCD6.1070204@sun.com>

Hi Tom,


Tom Georgoulias wrote:
> On 11/20/2009 12:32 AM, Niall Power wrote:
>> OK, So given the protests about these changes we will back out the
>> changes.
>
> I'm very happy to hear this.  Thank you!!
>
> I'm studying the current backup
>> feature in more detail and will try to come up
>> with a proposal that hopefully addresses the issue of the users of this
>> feature satisfactorily.
>
> What about my suggestion to create a server-oriented daemon that 
> provides this service alongside the time-sliderd daemon that 
> accomplishes more of the features that you are including?  That could 
> give the desktop team the flexibility it needs to make timeslider work 
> well in the GUI, while those of us who need zfs snapshot replication 
> for our storage servers will have a solution that is tailored for 
> server applications.
I have also considered such an option. The requirements of a zfs 
snapshotting mechanism targeted towards server and desktop
use differ in significant ways and I don't like banging square pegs into 
round holes, generally speaking.  From a practical point
of view it does raise some concerns though. It would require additional 
resourcing to maintain and enhance both. Unless resourced
in some way, I would be concerned that the server oriented service may 
be under resourced or neglected. As it stands right now,
I'm the only person working on the time-slider daemon.

So speaking personally, I think it makes sense, as it would eliminate 
the current conflict of interests. I wonder how others feel about this?

Thanks sincerely for your creative suggestions.

Niall.
> Tom
> _______________________________________________
> zfs-auto-snapshot mailing list
> zfs-auto-snapshot at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/zfs-auto-snapshot