[OmniOS-discuss] zfs send | recv

[Guenther Alka]

I suppose you can either keep the last snaps identical on source and 
target with a simple zfs send recursively or
you need a script that cares about and does a send per filesystem to 
allow a different number of snaps on the target system.

This is not related to Nexenta but I saw the same on current OmniOS -> 
OmniOS as they use the same Open-ZFS base Illumos

Gea
@naapp-it.org

Am 11.06.2018 um 10:58 schrieb Oliver Weinmann:
>
> Yes it is recursively. We have hundreds of child datasets so single 
> filesystems would be a real headache to maintain. L
>
> *Oliver Weinmann*
> Head of Corporate ICT
>
> Telespazio VEGA Deutschland GmbH
> Europaplatz 5 - 64293 Darmstadt - Germany
> Ph: +49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
> oliver.weinmann at telespazio-vega.de 
> <mailto:oliver.weinmann at telespazio-vega.de>
> www.telespazio-vega.de
>
> Registered office/Sitz: Darmstadt, Register court/Registergericht: 
> Darmstadt, HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller
>
> *From:*OmniOS-discuss <omnios-discuss-bounces at lists.omniti.com> *On 
> Behalf Of *Guenther Alka
> *Sent:* Montag, 11. Juni 2018 09:55
> *To:* omnios-discuss at lists.omniti.com
> *Subject:* Re: [OmniOS-discuss] zfs send | recv
>
> did you replicate recursively?
> keeping a different snap history should be possible when you send 
> single filesystems.
>
>
> gea
> @napp-it.org
>
> Am 11.06.2018 um 09:11 schrieb Oliver Weinmann:
>
>     Hi,
>
>     We are replicating snapshots from a Nexenta system to an OmniOS
>     system. Nexenta calls this feature autosync. While they say it is
>     only 100% supported between nexenta systems, we managed to get it
>     working with OmniOS too. It’s Not rocket science. But there is one
>     big problem. In the autosync job on the Nexenta system one can
>     specify how many snaps to keep local on the nexenta and how many
>     to keep on the target system. Somehow we always have the same
>     amount of snaps on both systems. Autosync always cleans all snaps
>     on the dest that don’t exist on the source. I contacted nexenta
>     support and they told me that this is due to different versions of
>     zfs send and zfs recv. There should be a –K  flag, that instructs
>     the destination to not destroy snapshots that don't exist on the
>     source. Is such a flag available in OmniOS? I assume the flag is
>     set on the sending side so that the receiving side has to
>     understand it.
>
>     Best Regards,
>
>     Oliver
>
>     *Oliver Weinmann*
>     Head of Corporate ICT
>
>     Telespazio VEGA Deutschland GmbH
>     Europaplatz 5 - 64293 Darmstadt - Germany
>     Ph: +49 (0)6151 8257 744 | Fax: +49 (0)6151 8257 799
>     oliver.weinmann at telespazio-vega.de
>     <mailto:oliver.weinmann at telespazio-vega.de>
>     www.telespazio-vega.de <http://www.telespazio-vega.de>
>
>     Registered office/Sitz: Darmstadt, Register court/Registergericht:
>     Darmstadt, HRB 89231; Managing Director/Geschäftsführer: Sigmar Keller
>
>
>
>
>     _______________________________________________
>
>     OmniOS-discuss mailing list
>
>     OmniOS-discuss at lists.omniti.com
>     <mailto:OmniOS-discuss at lists.omniti.com>
>
>     http://lists.omniti.com/mailman/listinfo/omnios-discuss
>
>
>
> -- 

-- 
H          f   G
Hochschule für Gestaltung
university of design

Schwäbisch Gmünd
Rektor-Klaus Str. 100
73525 Schwäbisch Gmünd

Guenther Alka, Dipl.-Ing. (FH)
Leiter des Rechenzentrums
head of computer center

Tel 07171 602 627
Fax 07171 69259
guenther.alka at hfg-gmuend.de
http://rz.hfg-gmuend.de

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://omniosce.org/ml-archive/attachments/20180611/33cb0678/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png
Type: image/png
Size: 7535 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20180611/33cb0678/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 7535 bytes
Desc: not available
URL: <https://omniosce.org/ml-archive/attachments/20180611/33cb0678/attachment-0003.png>