Comments (17)
Top level should work now according to #48 ... I'm using latest zrep directly from git.
from zrep.
from zrep.
Okay, so if I manually send the entire rpool
tree from client1.foo.bar
into the backup/client1/rpool
tree on backup1.foo.bar
, then what? It's not really clear to me what zrep commands needs to be issued on client1
and backup1
, and in what order, for this to work.
I guess the inverted behavior of the "backup server" mode sets me a bit off here (but then again the instructions in the documentation isn't that straight forward regarding this topic (-: ).
from zrep.
from zrep.
But that section needs to be reversed due to how "backup server" mode works, yes?
Then it would be something like this;
- Copy the ZFS tree manually from
client1
tobackup1
- Make first snapshot (matching the zrep naming scheme) manually on
client1
? - Then we need to set the configuration, in "reverse". On
client1
(aka "srchost"?):zrep changeconfig -f rpool backup1.foo.bar backup/client1/rpool
. Onbackup1
(aka "dsthost"?):zrep changeconfig -f -d backup/client1/rpool client1.foo.bar rpool
. Yes? No? - Then we do
zrep sentsync rpool@zrep_snapnamehere
onclient1
? - Then we do
zrep failover backup/client1/rpool
onbackup1
to "failover" toclient1
? - Then we do
zrep refresh backup/client1/rpool
onbackup1
every time we want to take a new backup?
I'm sorry if I'm asking dumb questions here. Even if I have a somewhat OK understanding on how ZFS works, I feel that it wasn't really "straight forward" how to do this by just reading the documentation for zrep (the combination of "srchost", "dsthost", and the "reverse behaviour", and with no real examples when having pre-existing file systems when in "backup server" mode). I'd be happy to make a PR explaining the steps in detail once I hammer this down, but until then; please bear with me (-:
from zrep.
from zrep.
So, there's still something funky with the order of dsthost/srchost.
This is what I've done so far;
- On
client1
:zfs snapshot -r rpool@zrep_000000
(had to search a bit to find the "standard naming scheme" -- the documentation is referring to it, but never explains the default). - On
backup1
:ssh [email protected] "zfs send -R rpool@zrep_000000" | pv | zfs recv -e backup/client1/rpool
. This completes successfully, and the entire tree (including snapshots) is copied. - On
client1
:$ZREP_PATH changeconfig -f rpool backup1.foo.bar backup/client1/rpool
. - On
backup1
:$ZREP_PATH changeconfig -f -d backup/client1/rpool client1.foo.bar rpool
. - At this point, trying to do
$ZREP_PATH sentsync rpool@zrep_000000
onclient1
, it would try to SSH intobackup1
. Either step 3) and/or 4) has the wrong "direction", or step 6) is correct. - Setting
$ZREP_PATH sentsync backup/client1/rpool@zrep_000000
onbackup1
works.
At this point, if I try to failover, the following happens;
root@backup1:~# $ZREP_PATH failover backup/client1/rpool
Setting readonly on local backup/client1/rpool, then syncing
ERROR: we are not master host for backup/client1/rpool
print master is client1.foo.bar, we are backup1
Error: zrep_sync could not create new snapshot for backup/client1/rpool
It already thinks it's in read-only mode, and that client1
is master. However, trying to refresh/sync;
root@backup1:~# $ZREP_PATH refresh backup/client1/rpool
Error: Sorry, you cant run refresh on a master mode fs backup/client1/rpool
Now it suddenly says it's master mode, while trying to failover it says it's not master? Sigh.
edit: fixed typo (extra -d
on client1
).
from zrep.
This is the status after doing the above commands... looks correct to me, except that it's saying both readonly on
and zrep:master yes
on backup1
(so it should probably be zrep:master no
on backup1
, and zrep:master yes
on client1
, but not sure how to change that "properly" -- either manually, or by figuring out what went wrong in my commands above).
root@client1:~# $ZREP_PATH list -v
rpool:
zrep:savecount 5
zrep:dest-host backup1.foo.bar
zrep:dest-fs backup/client1/rpool
zrep:src-fs rpoool
zrep:src-host client1
last snapshot synced:
root@backup1:~# $ZREP_PATH list -v
backup/client1/rpool:
readonly on
zrep:master yes
zrep:src-fs rpoool
zrep:dest-fs backup/client1/rpool
zrep:src-host client1.foo.bar
zrep:savecount 5
zrep:dest-host backup1
zrep:lock-pid 19482
zrep:lock-time 20170627211932
last snapshot synced: backup/client1/rpool@zrep_000000
from zrep.
from zrep.
But the backup1
is already master? Or does the takover
command remove the readonly on
flag? And on that topic, what does the readonly
flag "mean"? Is readonly on
== "we should never do zfs recv
on this host"?
from zrep.
from zrep.
But there is still something wrong here? You say that client1
should be the source here..
Your code clearly states the following;
# setfsconfigs srcfs desthost destfs
# setfsconfigs -d destfs srchost srcfs
... and as such, my previous steps should be correct (skipping the "copy the ZFS tree manually beforehand", as that is now solved);
- On
client1
:$ZREP_PATH changeconfig -f rpool backup1.foo.bar backup/client1/rpool
. - On
backup1
:$ZREP_PATH changeconfig -f -d backup/client1/rpool client1.foo.bar rpool
.
This results in the following;
###
### as seen on client1
###
root@client1:~# $ZREP_PATH changeconfig -f rpool backup1.foo.bar backup/client1/rpool
root@client1:~# $ZREP_PATH list -v
rpool:
zrep:savecount 5
zrep:dest-host backup1.foo.bar
zrep:dest-fs backup/client1/rpool
zrep:src-fs rpool
zrep:src-host client1
last snapshot synced:
###
### as seen on backup1
###
root@backup1:~# $ZREP_PATH changeconfig -f -d backup/client1/rpool client1.foo.bar rpool
root@backup1:~# $ZREP_PATH list -v
backup/client1/rpool:
readonly on
zrep:src-fs rpool
zrep:dest-fs backup/client1/rpool
zrep:src-host client1.foo.bar
zrep:savecount 5
zrep:dest-host backup1
last snapshot synced:
Which seems correct to me? Source is client1
on both sides, and destination is backup1
on both sides.
At this point, according to the documentation you linked to, we need to do a zrep sentsync
(before doing the zrep takeover
). However, sentsync
can only be issued on backup1
(if I try to issue it on client1
, then it tries to SSH into backup1
, which is not what we want). If I issue it on backup1
, the backup1
gets the zrep:master yes
flag...
At this point;
- If I issue
zrep sentsync
onclient1
, it tries to SSH intobackup1
, which defeats the point of "backup server" mode. - If I issue
zrep sentsync
onbackup1
, it works, butzrep:master yes
is set onbackup1
, which, according to you is wrong? - If I issue
zrep takeover
onbackup1
before settingzrep sentsync
, it fails withStarting failover from remote side client1.foo.bar. Error: rpool not master. Cannot fail over
. This is because none of the sides havezrep:master yes
. - In order for
zrep takeover
to work, thenrpool
onclient1
needszrep:master yes
set, but that only seems to happen ifzrep sentsync
is set onclient1
, which does not work. - If I set
zrep sentsync
onbackup1
, then bothzrep failover
andzrep takeover
fails;
root@backup1:~# $ZREP_PATH takeover backup/client1/rpool
Error: backup/client1/rpool is already master. Cannot takeover
root@backup1:~# $ZREP_PATH failover backup/client1/rpool
Setting readonly on local backup/client1/rpool, then syncing
ERROR: we are not master host for backup/client1/rpool
print master is client1.foo.bar, we are backup1
Error: zrep_sync could not create new snapshot for backup/client1/rpool
I feel I have tested all possible combinations now, but it still doesn't seem clear to me how this is supposed to work.
In stead of all this back-and-forth, can't you just give the exact commands you mean is needed to set this up from scratch given the test values I've provided? (see below). Should be 3 or 4 commands, based on what you've said so far (two changeconfig
, one sentsync
, one takeover/failover
).
### backup server
hostname = backup1.foo.bar
zfs_dataset = backup/client1/rpool
### client
hostname == client1.foo.bar
zfs_dataset = rpool
from zrep.
Due to lack of answer, and not getting this to work (I tried other things not mentioned in this issue), I gave up. Tried to figure out where the logic might be broken in the code, but never got that far. Ended up using znapzend.
from zrep.
from zrep.
Hi,
You clearly didn't read my latest post (Jun 28th), which basically covers every single combination (as far as I can see). Specifically this part;
- If I set
zrep sentsync
onbackup1
, then bothzrep failover
andzrep takeover
fails;
root@backup1:~# $ZREP_PATH takeover backup/client1/rpool
Error: backup/client1/rpool is already master. Cannot takeover
root@backup1:~# $ZREP_PATH failover backup/client1/rpool
Setting readonly on local backup/client1/rpool, then syncing
ERROR: we are not master host for backup/client1/rpool
print master is client1.foo.bar, we are backup1
Error: zrep_sync could not create new snapshot for backup/client1/rpool
Again, as I asked in my latest update, if you believe this should work, can you please provide the commands needed, given the following;
### backup server
hostname = backup1.foo.bar
zfs_dataset = backup/client1/rpool
### client
hostname == client1.foo.bar
zfs_dataset = rpool
from zrep.
from zrep.
After updating the code with a new flag, yes. I won't be surprised if it works now, tbh (-:
from zrep.
Related Issues (20)
- don't zrep_errquit in zrep_sync() while loop when using "all" HOT 2
- don't sync if not master HOT 7
- add check-for-remote parameter HOT 1
- fix code for #178 HOT 1
- possibility to add additional rcve parameters HOT 14
- zrep not updating/setting src-host / dest-host on the receiving side HOT 17
- don't destroy local fs if init is used wrong HOT 4
- zrep2 (bash) not working via cronjob HOT 1
- Is there an issue with zrep sync filesystem@snapshot? HOT 3
- Possibly missing `-s` to `zfs recv` when using `zrep refresh` HOT 3
- [enhancement] Add support of netcat for initial replication HOT 1
- large_blocks error HOT 6
- ZREP_SKIP_EXPIRE should also affect remote expiration of snapshots
- ZREP_INC_FLAG="-I" not used with custom zrep tag HOT 3
- ZREP - Filesystem will not be mounted HOT 1
- After connection problems: cannot receive incremental stream: destination ... has been modified HOT 12
- Changeconfig -d not working HOT 3
- On FreeBSD 15 CURRENT, `ZREP_R=-R zrep sync <dataset>` also syncs `zrep:master`
- zrep sync fails after solaris 11 upgrade from SRU60 to SRU68 HOT 5
- Zrep takeover fails after setting master. Reports "bash: line 1: zrep: command not found". HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from zrep.