anyway doing this senario with znapzend? about znapzend HOT 13 CLOSED

well ... znapzend does not replicate its own configuration, so theoretically, you can have a separate znapzend configuration on the destination target, BUT there is no provision for preventing the syncing going in both directions at once which would not be ideal, so I guess some extra safeguards would have to be put in place to make such a scenario work.

from znapzend.

Tobi in my case ,I want one time reverse replication from destination to source (only changed blocks since last successful replication from source to destination,not all data) even manually,is it possible?

from znapzend.

I understand your scenario ... it is certainly possible ... as I said, the problem is to make absolutely sure that things run in the right direction ... imagine, znapzend on 'source' starts running again before you have managed to sync back ... then all your changes on destination will be cleared away.

from znapzend.

ok,could you make adaptation of znapzend for this senario as a customization?and how much will it cost?

from znapzend.

👍 we'll look into this and let you know

from znapzend.

it will probably be a few weeks before we can tell you something as @hadfl is currently in a major rewrite of znapzend.

from znapzend.

maybe zrep script code will help you about this senario,as I know zrep has failover and takeoker features.

from znapzend.

our current idea is that the normal znapzend script would detect that you have modified files on the destinaton device and stop sending new snapshots there but complain loudly. You would then start znapzend in interactive mode on the source and get it to sync the changes from dest back to source. I guess the implementation of such a feature would be in the range of a few thousand dollar.

from znapzend.

ok, thank you for info,
please keep in mind,zvol wiil not receive replication if its shared(***cannot receive new filesystem stream: dataset is busy),maybe znapzend will control destination ,if its zvol(volume) and shared then first will unshare it and then start send replication.

as I understand znapzend will run on source node only and will coordinate these tasks from source,it's better than running znapzend on all nodes,less complex.

from znapzend.

yes that is the idea ... as for syncing back volumes, there merging is not realistic I guess it is all or nothing really, so the volume must not be shared prior to backsync, since otherwise is would basically imply it is in active use ...

from znapzend.

I misunderstood few thousand with few hundreds sorry:((my max budget 500$ for this customization,sorry again

from znapzend.

This would be a wonderful feature. Maybe you could setup a donation pool for features like this one?

from znapzend.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

from znapzend.