Description of problem: Customer has requested a way to geo replicate bricks during snapshot operations. Executed similarly to how KVM does live migration of VMs. https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/chap-Managing_Geo-replication.html https://access.redhat.com/documentation/en-US/Red_Hat_Storage/3.1/html/Administration_Guide/chap-Managing_Snapshots.html The business need here is to allow for geo replication while also allowing backups (snapshots) of the CNS bricks in an OCP environment.
We discussed this RFE in mailing list and following are the outcome - Q- What are the exact technical issues with running scheduled snapshots on geo-replicated volumes? A- This limitation is to maintain same state when Snapshot is restored. For example, if Snapshot is taken only in Master Volume without taking snapshot of Slave volume. After some time if Master volume is restored to old snapshot then Slave Volume will be ahead of Master Volume and it is not possible to bring Slave Volume to same state as of restored Volume. If Slave snapshot is taken without Master snapshot, and after some time Slave volume is restored. Geo-rep session will not have any clue that Slave volume is restored and it will not sync any old files. -- So, we are planning to come up with one snapshot configure option where we can take snapshot of volume (Master or Slave) even geo-rep session is active. -- Using above option is advisable only when you are not planning to restore volume(master or slave) in future.
*** Bug 1512700 has been marked as a duplicate of this bug. ***
If the use case it to take a snapshot to use it as a backup, then we can introduce a flag that overrides the geo-replication check, steps to fix, 1) Pass one flag from cli to glusterd for allowing snapshot during geo-replication 2) Bypass the geo-replication session check (glusterd_snapshot_create_prevalidate) based on the flag 3) Maybe, store the information in the snapinfo, and during restore throw a warning
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days