# [OmniOS-discuss] zfs send | recv

Oliver Weinmann oliver.weinmann at telespazio-vega.de
Mon Jun 11 10:31:31 UTC 2018

- Previous message: [OmniOS-discuss] zfs send | recv
- Next message: [OmniOS-discuss] VEEAM backups to CIFS fail only on OmniOS hypercongerged VM
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    I think I really have to start investigating using 3rd party apps again. Nexenta doesn't let me change the zfs send command. I can only adjust settings for the autosync job.

    [cid:Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png]

    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 12:16
    To: omnios-discuss at lists.omniti.com
    Subject: Re: [OmniOS-discuss] zfs send | recv

    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

    [cid:image001.png at 01D40180.1FD80740]

    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

    From: OmniOS-discuss <omnios-discuss-bounces at lists.omniti.com><mailto: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<mailto: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

    [cid:image001.png at 01D40180.1FD80740]

    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<mailto:guenther.alka at hfg-gmuend.de>

    http://rz.hfg-gmuend.de
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180611/2f0308e9/attachment-0001.html>
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: image001.png
    Type: image/png
    Size: 7535 bytes
    Desc: image001.png
    URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180611/2f0308e9/attachment-0002.png>
    -------------- 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: Logo_Telespazio_180_px_signature_eng_b58fa623-e26d-4116-9230-766adacfe55e1111111111111.png
    URL: <http://lists.omniti.com/pipermail/omnios-discuss/attachments/20180611/2f0308e9/attachment-0003.png>

- Previous message: [OmniOS-discuss] zfs send | recv
- Next message: [OmniOS-discuss] VEEAM backups to CIFS fail only on OmniOS hypercongerged VM
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the OmniOS-discuss mailing list