When we use ZFS backups, we no longer back them up to tape (tape is just too small for our requirements nowadays)
we run zfs at our "remote" sites, then snapshot each day, zfs send them to files on the disk, rsync them to the receiving machine and them zfs restore them into the "backup" ... this checks that the zfs send files are correct and gives us a live copy of the data for accessing. I have a perl script that sits and watches the rsync queues all day and restores only when it sees files appear, rsync copies files with a dot prefix, and renames them when it's finished so the perl script only restores a completed file. The snapshot/send script is a nasty POS written by my colleague in <shudder>csh</shudder> but it was working and he'd have gone nuts if I'd changed that script as well. I can send/upload either script if it helps anybody. Jon On 10 July 2014 08:16, John McEntee via illumos-discuss < [email protected]> wrote: > Gabriele > > Just so I understand. What is wrong with a zfs pool on the client machine > and zfs send /receive to the server machine which can then back it up to > tape? Why do you need zfs in the mix? > > John > ------------------------------ > *From:* Gabriele Bulfon via illumos-discuss [[email protected]] > *Sent:* 10 July 2014 08:09 > *To:* Reginald Beardsley; [email protected] > *Subject:* Re: [discuss] zfs lofi file pool double mount > > NFS is slow, expecially with small files. > So what I'm trying to do is: > > - have the NFS client run his daily work on local zfs pools, fast. > - have periodic zfs incremental send of these pools on the NFS lofi files > - have the NFS server access these lofi files periodically to backup them > old manner (tape) > > Just experimenting, to have some kind of zfs incremental backup over nfs > > > > ---------------------------------------------------------------------------------- > > Da: Reginald Beardsley <[email protected]> > A: [email protected] Gabriele Bulfon <[email protected]> > Data: 9 luglio 2014 18.16.16 CEST > Oggetto: Re: [discuss] zfs lofi file pool double mount > > What are you trying to do? It's not possible for the server to have RO > access and the client have R/W access. The server has to have R/W to > service the client requests. > > As for making certain clients RO and other R/W, that's provided by NFS. > You can even make the NFS mountpoint RO on the server, but the physical > mountpoint still has to be R/W at least for nfsd. You *could* make the > physical mountpoint completely inaccessible to anything other than nfsd by > setting ownership and permissions properly. > > You can actually do pretty much anything you can imagine using NFS maps. > Folding maps based on system architecture is one of my favorites, i.e. > /app/bin -> /app/${ARCH}/bin, but it's not needed much now that so much of > the *nix world has converged on Linux. Back during the workstation wars it > was very useful. > > But again, what's the objective? > > Reg > > -------------------------------------------- > On Wed, 7/9/14, Gabriele Bulfon via illumos-discuss < > [email protected]> wrote: > > Subject: [discuss] zfs lofi file pool double mount > To: [email protected] > Date: Wednesday, July 9, 2014, 8:44 AM > > Hi, > > as > an experiment. > > Let's say I have a zfs fs > shared as an NFS resource to another illumos client. > Let's say I have created a 152GB file on this > resrouce. > Let's say I have added the file as a lofi > dev on the NFS server, and created a 512GB zpool on it. > Finally, let's say I have added the file as a lofi dev > on the NFS client too. > > Now I can export / import > the pool both from the NFS server, and the NFS client. > > Obviously I can't import the pool from both > machines. > > But...what if one would "import -f > -o readonly=on" and the other would import -f > read/write? > Would it be possible? > This would let > me zfs send the client pool to the lofi pool on the NFS > share, while have the server > be able to read the > contained files. > > Is it safe? > > Gabriele. > > > > > > illumos-developer | Archives > > | Modify > Your Subscription > > > > illumos-discuss | Archives > > | Modify > Your Subscription > > > > *illumos-discuss* | Archives > <https://www.listbox.com/member/archive/182180/=now> > <https://www.listbox.com/member/archive/rss/182180/24506464-f4272eae> | > Modify <https://www.listbox.com/member/?&;> Your Subscription > <http://www.listbox.com> > > _______________________________________________________________________ > > The contents of this e-mail and any attachment(s) are strictly > confidential and are solely for the person(s) at the e-mail address(es) > above. If you are not an addressee, you may not disclose, distribute, copy > or use this e-mail, and we request that you send an e-mail to > [email protected] and delete this e-mail. Stirling Dynamics > Ltd. accepts no legal liability for the contents of this e-mail including > any errors, interception or interference, as internet communications are > not secure. Any views or opinions presented are solely those of the author > and do not necessarily represent those of Stirling Dynamics Ltd. Registered > In England No. 2092114 Registered Office: 26 Regent Street, Clifton, > Bristol. BS8 4HG > VAT no. GB 464 6551 29 > _______________________________________________________________________ > > This e-mail has been scanned for all viruses MessageLabs. > *illumos-discuss* | Archives > <https://www.listbox.com/member/archive/182180/=now> > <https://www.listbox.com/member/archive/rss/182180/23508059-3f15f76a> | > Modify > <https://www.listbox.com/member/?&;> > Your Subscription <http://www.listbox.com> > ------------------------------------------- illumos-discuss Archives: https://www.listbox.com/member/archive/182180/=now RSS Feed: https://www.listbox.com/member/archive/rss/182180/21175430-2e6923be Modify Your Subscription: https://www.listbox.com/member/?member_id=21175430&id_secret=21175430-6a77cda4 Powered by Listbox: http://www.listbox.com
