• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

ZFS zRep for backups (dumb) question

stevebaynet

Limp Gawd
Joined
Nov 9, 2011
Messages
204
I know several ppl on here use zrep to backup their ZFS storage servers, so i'm hoping somone can chime in here.

I am going to be using zrep to one way sync my production ZFS servers to a napp-it "all in one" server for disaster recovery purposes.

seems like zrep is the easiest way to do this. Relevant snippet from the zrep manual:

Code:
 Use in a backup server

    Some folks may be looking just for a way to simplify their backup mechanisms, rather than doing fancy failover. In this scenario, there is one centralized backup server that has trusted root ssh OUT, but does not allow root ssh IN. (This way, it is possible to have independant clients, in separate zones of trust or system administration from each other)

    In this setup, typical setup and use would look something like the following.

        Set up the filesystem initially on the backup server
        Do "zrep init {localfs} {clienthost} {clientfs}"
        "zrep failover {localfs}" 

    You have now set up initial state cleanly.

        If you already have a client zfs filesystem with a bunch of data, it is technically possible to do a manual initialization to the backup server. However, this is not supported at this time. A smart sysadmin should be able to figure out what is needed by looking at the output of "zrep list -v" after a normal init 

    Once this is done, you can then set up a special zrep job on the backup server, instead of the master. It will look just like a "zrep sync" job, but instead, you will want to call

    	zrep refresh pool/fs

    Now, instead of the master side "pushing" new data, you will be "pulling" the latest bits to your read-only backup server copy of the filesystem.

The part that confuses me, is it states that zrep will create the "client" FS (the one i wanna backup) for you. I already have a FS and zpool setup. I'm fine with starting from scratch (this stuff isnt in production yet) but the thing i dont get is:

do i run zrep init {localfs} {clienthost} {clientfs} first and then create the zpool?

or do i create the zpool, and then run it.

*scratching head*

any thoughts appreciated.
 
hrmmm, trying this locally first withing the napp-it server.

so i created a pool, called testpool, then i created a pool called bakpool.

next, created an FS called bakpool/fs

ran: ./zrep init bakpool/fs 127.0.0.1 testpool/fs

it created testpool/fs for me and i see it in the napp-it GUI.

i noticed both were set to read only, i fergot to run:

zrep failover bakpool/fs

however, last step failed with a bash error saying it couldnt find zrep, im assuming zrep needs to be added to my path, or stuck in a bin dir.
 
ok, copied zrep to /usr/bin

cleared zrep, dumped testpool/fs and started over. now it works:

Code:
root@bns-bsan1:/testpool/fs# touch text.txt
root@bns-bsan1:/testpool/fs# ls
text.txt
root@bns-bsan1:/testpool/fs# zrep refresh bakpool/fs
DEBUG: refresh step 1: Going to 127.0.0.1 to snapshot bakpool/fs
Password:
DEBUG: refresh step 2: Pulling testpool/fs@zrep_000002
Password:
DEBUG: _refreshpull: snapname=testpool/fs@zrep_000002, fs=testpool/fs
root@bns-bsan1:/testpool/fs# ls
text.txt
root@bns-bsan1:/testpool/fs# cd ..
root@bns-bsan1:/testpool# cd ..
root@bns-bsan1:/# cd bakpool/fs
root@bns-bsan1:/bakpool/fs# ls
text.txt
root@bns-bsan1:/bakpool/fs#

success. i wonder if nexenta wont like zrep creating and tweaking the FS tho, will have to give it a try.

if anyone has experience with this chime on in.
 
Hrmmm, apparently nexenta will let auto-sync replicate to a non-nexenta box, but limits it to work over SSH only. im fine with this, so ill give this a try too in addition to zrep.
 
The destination fs can't exist. So for an existing pool, if you do:

zrep tank/foo/bar 10.0.0.10 tank/foo/bar, tank/foo must exist on the destination, but tank/foo/bar must not.
 
Back
Top