Hi Edward,
My own personal view on this is that the simplest option is the best.
In your script, create a new snapshot using one of 2 names. Let's call
them SNAPSEND_A and SNAPSEND_B. You can decide which one by checking
which currently exists.
As manual setup, on the first run, create SNAPS
> I send a replication data stream from one host to another. (and receive).
Have you looked at snapsend?
http://labs.omniti.com/labs/tools/browser/trunk/snapsend.sh
We've used this for a while in production for our backups and
replication. We adapted it a bit so it runs every minute without
ov
On Wed, Sep 12, 2012 at 7:16 PM, Ian Collins wrote:
> On 09/13/12 10:23 AM, Timothy Coalson wrote:
>
>> Unless i'm missing something, they didn't solve the "matching snapshots"
>> thing yet, from their site:
>>
>> "To Do:
>>
>> Additional error handling for mismatched snapshots (last destination
On 09/13/12 10:23 AM, Timothy Coalson wrote:
Unless i'm missing something, they didn't solve the "matching
snapshots" thing yet, from their site:
"To Do:
Additional error handling for mismatched snapshots (last destination
snap no longer exists on the source) walk backwards through the remote
Unless i'm missing something, they didn't solve the "matching snapshots"
thing yet, from their site:
"To Do:
Additional error handling for mismatched snapshots (last destination snap
no longer exists on the source) walk backwards through the remote snaps
until a common snapshot is found and destr
> From: zfs-discuss-boun...@opensolaris.org [mailto:zfs-discuss-
> boun...@opensolaris.org] On Behalf Of Edward Ned Harvey
>
> Question #2: What's the best way to find the latest matching snap on both
> the source and destination? At present, it seems, I'll have to build a list
> of
> sender sn
> From: Richard Elling [mailto:richard.ell...@gmail.com]
>
> Question #2: What's the best way to find the latest matching snap on both
> the source and destination? At present, it seems, I'll have to build a list
> of
> sender snaps, and a list of receiver snaps, and parse and search them, till
On 09/13/12 07:44 AM, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris) wrote:
I send a replication data stream from one host to another. (and receive).
I discovered that after receiving, I need to remove the auto-snapshot
property on the receiving side, and set the readonly property on
When I wrote a script for this, I used separate snapshots, with a different
naming convention, to use as the endpoints for the incremental send. With
this, it becomes easier: find the newest snapshot with that naming
convention on the sending side, and check that it exists on the receiving
side.
On Sep 12, 2012, at 12:44 PM, Edward Ned Harvey
(opensolarisisdeadlongliveopensolaris)
wrote:
> I send a replication data stream from one host to another. (and receive).
> I discovered that after receiving, I need to remove the auto-snapshot
> property on the receiving side, and set the readon
I send a replication data stream from one host to another. (and receive).
I discovered that after receiving, I need to remove the auto-snapshot property
on the receiving side, and set the readonly property on the receiving side, to
prevent accidental changes (including auto-snapshots.)
Question
11 matches
Mail list logo