Remote-replication (DR) - Revision history

Qadmin: CephFS shares can now be replicated (scale-out file replication): correct the Requirements sentence that said they cannot, add the Scale up / Scale out radio, current no-destination message, and a link to Scale-out File Replication

2026-09-28T16:43:12Z

CephFS shares can now be replicated (scale-out file replication): correct the Requirements sentence that said they cannot, add the Scale up / Scale out radio, current no-destination message, and a link to Scale-out File Replication

← Older revision		Revision as of 16:43, 28 September 2026
Line 25:		Line 25:
	\|-		\|-
	\| [[#Monitoring replication\|Monitoring replication]] \|\| Where state, history and throughput are visible		\| [[#Monitoring replication\|Monitoring replication]] \|\| Where state, history and throughput are visible
			\|-
			\| [[#Scale-out (CephFS) share replication\|Scale-out (CephFS) share replication]] \|\| Replicating CephFS shares between Ceph Clusters, which works differently
	\|}		\|}

Line 51:		Line 53:
	* '''A [[Storage Pools\|Storage Pool]] on each system.''' The pools do not need to match in size, layout, disk type or hardware.		* '''A [[Storage Pools\|Storage Pool]] on each system.''' The pools do not need to match in size, layout, disk type or hardware.
	* '''A license with the remote-replication feature.''' Without it, creating a link fails with {{Code\|1=Remote replication is not licensed for this storage system.}} Trial and cloud-edition licenses always include it.		* '''A license with the remote-replication feature.''' Without it, creating a link fails with {{Code\|1=Remote replication is not licensed for this storage system.}} Trial and cloud-edition licenses always include it.
	* '''A destination pool of a compatible type.''' The Remote Pool list in the schedule dialog only offers pools on the remote system, and it never offers XFS, CephFS or Ceph object pools. Ceph RBD pools are offered only when the remote system belongs to the same Ceph cluster as the source. Network Shares in scale-out CephFS ~~pools cannot be replicated~~; ~~use~~ [[~~Backup Policies~~]] ~~for those~~.		* '''A destination pool of a compatible type.''' The Remote Pool list in the schedule dialog only offers pools on the remote system, and it never offers XFS, CephFS or Ceph object pools. Ceph RBD pools are offered only when the remote system belongs to the same Ceph cluster as the source. Network Shares on scale-out CephFS file systems replicate to another Ceph Cluster through Ceph snapshot mirroring instead; see [[#Scale-out (CephFS) share replication\|Scale-out (CephFS) share replication]].
	* '''TCP reachability between the two addresses you choose for the link.''' Replication data moves over SSH (or, on an unencrypted link, over an mbuffer TCP session) between the two link addresses.		* '''TCP reachability between the two addresses you choose for the link.''' Replication data moves over SSH (or, on an unencrypted link, over an mbuffer TCP session) between the two link addresses.

Line 157:		Line 159:
	* '''Policy Name''' -- pre-filled with a generated name such as {{Code\|1=replication-sched-1}}. Names may contain letters, digits and {{Code\|1=-_.}} only.		* '''Policy Name''' -- pre-filled with a generated name such as {{Code\|1=replication-sched-1}}. Names may contain letters, digits and {{Code\|1=-_.}} only.
	* '''Description''' -- free text.		* '''Description''' -- free text.
			* '''Scale up replication''' / '''Scale out replication''' -- the replication type. Scale up, the default, is the ZFS replication this page describes. Scale out mirrors CephFS Network Share snapshots to another Ceph Cluster and changes the rest of the dialog; see [[Scale-out File Replication]].
	* '''Replica Destination''' -- the Storage System Replication Link to use. '''This choice sets the direction of replication''': the link {{Code\|1=A --> B}} replicates from A to B. Because links exist in both directions, both appear in the list. Selecting a link that is offline clears the Remote Pool list.		* '''Replica Destination''' -- the Storage System Replication Link to use. '''This choice sets the direction of replication''': the link {{Code\|1=A --> B}} replicates from A to B. Because links exist in both directions, both appear in the list. Selecting a link that is offline clears the Remote Pool list.
	* '''Remote Pool''' -- the destination Storage Pool, labelled with its system: {{Code\|1=pool-name [system-name]}}. Only pools on the link's remote system appear, subject to the type rules in [[#Requirements\|Requirements]].		* '''Remote Pool''' -- the destination Storage Pool, labelled with its system: {{Code\|1=pool-name [system-name]}}. Only pools on the link's remote system appear, subject to the type rules in [[#Requirements\|Requirements]].
	* '''Start date''' and '''Enabled''' -- when the schedule becomes eligible to run, and whether it is active. Enabled is checked by default.		* '''Start date''' and '''Enabled''' -- when the schedule becomes eligible to run, and whether it is active. Enabled is checked by default.

	If no replication link ~~exists at all~~, the dialog closes immediately with ''There ~~are no remote storage systems~~ to replicate ~~your volumes. Add a link~~ to ~~a remote storage system first~~.''		If there is neither a replication link nor a CephFS mirror peer, the dialog closes immediately with ''There is nothing to replicate to.''

	=== Schedule Interval tab ===		=== Schedule Interval tab ===
Line 495:		Line 498:

	Every replication run appears in the Tasks pane as an ''Initiating Remote-Replication'' task on the source system, with a per-transfer description and progress, followed by an ''Importing Replica(s)'' task on the destination as it takes the new checkpoint and snapshots into inventory. Replication failures, invalid resume tokens and blocked automatic activations all raise alerts; see [[Call-home / Alerting]] for delivering them off the appliance.		Every replication run appears in the Tasks pane as an ''Initiating Remote-Replication'' task on the source system, with a per-transfer description and progress, followed by an ''Importing Replica(s)'' task on the destination as it takes the new checkpoint and snapshots into inventory. Replication failures, invalid resume tokens and blocked automatic activations all raise alerts; see [[Call-home / Alerting]] for delivering them off the appliance.

			== Scale-out (CephFS) share replication ==

			Network Shares on a scale-out CephFS file system are replicated to a CephFS file system in a second Ceph Cluster by Ceph's cephfs-mirror daemon, not by the ZFS replication described on this page. They use a mirroring service and a mirror peer in place of a Storage System Replication Link, share only the Create Replication Schedule dialog with scale-up replication, and have no checkpoints, replication reports or failover. See [[Scale-out File Replication]] for setup, monitoring and its limitations.

	== Related pages ==		== Related pages ==
Line 504:		Line 511:
	* [[Snapshot Schedules]] -- local point-in-time recovery points		* [[Snapshot Schedules]] -- local point-in-time recovery points
	* [[Backup Policies]] -- pulling data in from non-QuantaStor sources		* [[Backup Policies]] -- pulling data in from non-QuantaStor sources
			* [[Scale-out File Replication]] -- replicating CephFS shares between Ceph Clusters
	* [[Site Cluster Create]] -- creating the Site Cluster whose VIF drives automatic activation		* [[Site Cluster Create]] -- creating the Site Cluster whose VIF drives automatic activation
	* [[Configure Member Standby]] -- per-node standby state, which governs where a cluster VIF may move		* [[Configure Member Standby]] -- per-node standby state, which governs where a cluster VIF may move

Qadmin: Replace redlink to High-availability VIF Management with plain text; link Site Cluster Create instead (QSTOR-12352)

2026-09-03T05:36:56Z

Replace redlink to High-availability VIF Management with plain text; link Site Cluster Create instead (QSTOR-12352)

← Older revision		Revision as of 05:36, 3 September 2026
Line 362:		Line 362:
	=== Automatic failover on VIF arrival ===		=== Automatic failover on VIF arrival ===

	Set up on the schedule's '''Automatic Activation''' tab, this activates a schedule's checkpoints when a Site Cluster virtual interface moves to the node that owns the destination pool -- which is what happens when the primary site goes offline. Create the Site Cluster and its VIF under [[High-availability VIF Management]] first, spanning the source and destination systems, then select that VIF in the schedule.		Set up on the schedule's '''Automatic Activation''' tab, this activates a schedule's checkpoints when a Site Cluster virtual interface moves to the node that owns the destination pool -- which is what happens when the primary site goes offline. Create the Site Cluster and its VIF under the '''High-availability VIF Management''' tab first, spanning the source and destination systems, then select that VIF in the schedule.

	When the VIF arrives, QuantaStor raises an alert and runs the same activation task as the dialog, always for '''every''' volume and share in the schedule and always with alias auto-creation on.		When the VIF arrives, QuantaStor raises an alert and runs the same activation task as the dialog, always for '''every''' volume and share in the schedule and always with alias auto-creation on.
Line 504:		Line 504:
	* [[Snapshot Schedules]] -- local point-in-time recovery points		* [[Snapshot Schedules]] -- local point-in-time recovery points
	* [[Backup Policies]] -- pulling data in from non-QuantaStor sources		* [[Backup Policies]] -- pulling data in from non-QuantaStor sources
	* [[~~High-availability VIF Management~~]] -- Site ~~Clusters and the VIFs that drive~~ automatic activation		* [[Site Cluster Create]] -- creating the Site Cluster whose VIF drives automatic activation
	* [[Configure Member Standby]] -- per-node standby state, which governs where a cluster VIF may move		* [[Configure Member Standby]] -- per-node standby state, which governs where a cluster VIF may move
	* [[QuantaStor CLI Command Reference]] -- full argument lists for the commands above		* [[QuantaStor CLI Command Reference]] -- full argument lists for the commands above

Qadmin: Full rewrite from the product: link/schedule dialogs tab by tab with defaults and enablement rules, checkpoint model, delta vs full sync mechanism, failover/failback, failure handling, monitoring. Corrects minimum interval (3 not 5 min), checkpoint numbering suffix, blocked-schedule state, and removes unverifiable performance claims and the unreachable link-refresh procedure (QSTOR-12352)

2026-09-03T05:35:46Z

Full rewrite from the product: link/schedule dialogs tab by tab with defaults and enablement rules, checkpoint model, delta vs full sync mechanism, failover/failback, failure handling, monitoring. Corrects minimum interval (3 not 5 min), checkpoint numbering suffix, blocked-schedule state, and removes unverifiable performance claims and the unreachable link-refresh procedure (QSTOR-12352)

Show changes

Qadmin: Remove version-era references: removed 1 QuantaStor 5 video link(s) -- all customers run QuantaStor 6 or newer (wiki-docs rule 13, QSTOR-12352)

2026-09-03T03:15:13Z

Remove version-era references: removed 1 QuantaStor 5 video link(s) -- all customers run QuantaStor 6 or newer (wiki-docs rule 13, QSTOR-12352)

← Older revision		Revision as of 03:15, 3 September 2026
Line 4:		Line 4:

	QuantaStor supports remote-replication of both Storage Volumes (SAN) and Network Shares (NAS). Remote-replication is typically setup with a Remote-Replication Schedule but can also be done as a one-time replication without a schedule. Remote-replication is done asynchronously and is block-level incremental for both Storage Volumes and Network Shares. Block-level incremental means that only the changes (aka deltas) made to the source volumes and shares are replicated to the destination. This makes efficient use of WAN bandwidth and enables near-CDP type functionality replication schedules can be set to replicate ever couple minutes to keep the destination copies in close lock-step with the sources.		QuantaStor supports remote-replication of both Storage Volumes (SAN) and Network Shares (NAS). Remote-replication is typically setup with a Remote-Replication Schedule but can also be done as a one-time replication without a schedule. Remote-replication is done asynchronously and is block-level incremental for both Storage Volumes and Network Shares. Block-level incremental means that only the changes (aka deltas) made to the source volumes and shares are replicated to the destination. This makes efficient use of WAN bandwidth and enables near-CDP type functionality replication schedules can be set to replicate ever couple minutes to keep the destination copies in close lock-step with the sources.

	~~''' OSNEXUS Videos '''~~
	* [[Image:youtube_icon.png\|50px\|link=https://www.youtube.com/watch?v=33jctl-UEUM]] [https://www.youtube.com/watch?v=33jctl-UEUM Covers QuantaStor 5 Remote-replication Setup [16:08]]

	==== Full Copy vs Incremental Replication ====		==== Full Copy vs Incremental Replication ====

Qadmin: /* Setup Process Overview */

2023-12-09T16:33:41Z

Setup Process Overview

← Older revision		Revision as of 16:33, 9 December 2023
Line 34:		Line 34:

	# Select the 'Remote Replication' tab and choose '''Create''' from the 'Replication Link' toolbar. This will exchange keys between the two systems so that a replication schedule can be created. You can create an unlimited number of links. The link also stores information about the ports to be used for remote-replication traffic.		# Select the 'Remote Replication' tab and choose '''Create''' from the 'Replication Link' toolbar. This will exchange keys between the two systems so that a replication schedule can be created. You can create an unlimited number of links. The link also stores information about the ports to be used for remote-replication traffic.
	#'''Navigation:''' Remote Replication --> Storage System Replication Links --> Replication Link --> Create ''(toolbar)''		'''Navigation:''' Remote Replication --> Storage System Replication Links --> Replication Link --> Create ''(toolbar)''

	# Select the 'Volume & Share Replication Schedules' section in the left pane and choose '''Create''' in the 'Replication Schedule' toolbar to bring up the dialog to [[Remote-replication_/_Disaster_Recovery_Setup#Creating_a_Storage_System_Link_for_Replication \| create a new remote replication schedule.]]		# Select the 'Volume & Share Replication Schedules' section in the left pane and choose '''Create''' in the 'Replication Schedule' toolbar to bring up the dialog to [[Remote-replication_/_Disaster_Recovery_Setup#Creating_a_Storage_System_Link_for_Replication \| create a new remote replication schedule.]]

Qadmin: /* Setup Process Overview */

2023-12-09T16:27:24Z

Setup Process Overview

← Older revision		Revision as of 16:27, 9 December 2023
Line 34:		Line 34:

	# Select the 'Remote Replication' tab and choose '''Create''' from the 'Replication Link' toolbar. This will exchange keys between the two systems so that a replication schedule can be created. You can create an unlimited number of links. The link also stores information about the ports to be used for remote-replication traffic.		# Select the 'Remote Replication' tab and choose '''Create''' from the 'Replication Link' toolbar. This will exchange keys between the two systems so that a replication schedule can be created. You can create an unlimited number of links. The link also stores information about the ports to be used for remote-replication traffic.
	'''Navigation:''' Remote Replication --> Storage System Replication Links --> Replication Link --> Create ''(toolbar)''		#'''Navigation:''' Remote Replication --> Storage System Replication Links --> Replication Link --> Create ''(toolbar)''

	# Select the 'Volume & Share Replication Schedules' section in the left pane and choose '''Create''' in the 'Replication Schedule' toolbar to bring up the dialog to [[Remote-replication_/_Disaster_Recovery_Setup#Creating_a_Storage_System_Link_for_Replication \| create a new remote replication schedule.]]		# Select the 'Volume & Share Replication Schedules' section in the left pane and choose '''Create''' in the 'Replication Schedule' toolbar to bring up the dialog to [[Remote-replication_/_Disaster_Recovery_Setup#Creating_a_Storage_System_Link_for_Replication \| create a new remote replication schedule.]]

Qadmin at 16:26, 9 December 2023

2023-12-09T16:26:56Z

← Older revision		Revision as of 16:26, 9 December 2023
Line 34:		Line 34:

	# Select the 'Remote Replication' tab and choose '''Create''' from the 'Replication Link' toolbar. This will exchange keys between the two systems so that a replication schedule can be created. You can create an unlimited number of links. The link also stores information about the ports to be used for remote-replication traffic.		# Select the 'Remote Replication' tab and choose '''Create''' from the 'Replication Link' toolbar. This will exchange keys between the two systems so that a replication schedule can be created. You can create an unlimited number of links. The link also stores information about the ports to be used for remote-replication traffic.
			'''Navigation:''' Remote Replication --> Storage System Replication Links --> Replication Link --> Create ''(toolbar)''

	# Select the 'Volume & Share Replication Schedules' section in the left pane and choose '''Create''' in the 'Replication Schedule' toolbar to bring up the dialog to [[Remote-replication_/_Disaster_Recovery_Setup#Creating_a_Storage_System_Link_for_Replication \| create a new remote replication schedule.]]		# Select the 'Volume & Share Replication Schedules' section in the left pane and choose '''Create''' in the 'Replication Schedule' toolbar to bring up the dialog to [[Remote-replication_/_Disaster_Recovery_Setup#Creating_a_Storage_System_Link_for_Replication \| create a new remote replication schedule.]]
	## Select the replication link that will indicate the direction of replication.		## Select the replication link that will indicate the direction of replication.

Qadmin: /* Network Share Checkpoints */

2023-12-05T23:40:50Z

Network Share Checkpoints

← Older revision		Revision as of 23:40, 5 December 2023
Line 138:		Line 138:

	Network share check-points also contain the ''_chkpnt'' suffix just as with ''Storage Volume'' replica check-points and this can create some challenges if users are expecting to find their data under a share with the same name. For example, a share named ''backups'' will have the name ''backups_chkpnt'' at the destination / DR site system. There is an easy way to resolve this through the use of Network Share Aliases. Simply right-click on the check-point for the ''Network Share'' (eg. backups_chkpnt) and choose ''Create Alias/Sub-share...'' which allows one to assign alternate names to a share as can be seen below. After the alias is created as ''backups'' the share will be accessible both as ''backups'' and ''backups_chkpnt''. If users find the dual-naming confusing then the ''browsable'' setting may be adjusted on the ''backups_chkpnt'' to hide it from users using the ''Modify Share'' dialog.		Network share check-points also contain the ''_chkpnt'' suffix just as with ''Storage Volume'' replica check-points and this can create some challenges if users are expecting to find their data under a share with the same name. For example, a share named ''backups'' will have the name ''backups_chkpnt'' at the destination / DR site system. There is an easy way to resolve this through the use of Network Share Aliases. Simply right-click on the check-point for the ''Network Share'' (eg. backups_chkpnt) and choose ''Create Alias/Sub-share...'' which allows one to assign alternate names to a share as can be seen below. After the alias is created as ''backups'' the share will be accessible both as ''backups'' and ''backups_chkpnt''. If users find the dual-naming confusing then the ''browsable'' setting may be adjusted on the ''backups_chkpnt'' to hide it from users using the ''Modify Share'' dialog.

			'''Navigation:''' Storage Management --> Volume & Share Replication Schedules --> Create Alias... ''(rightclick)''

	[[File:Create Network Share Alias.jpg\|512px]]		[[File:Create Network Share Alias.jpg\|512px]]

Qadmin: /* Option 2: Send checkpoint side changes back to the source side, then resume replication from source to destination */

2023-11-24T20:29:40Z

Option 2: Send checkpoint side changes back to the source side, then resume replication from source to destination

← Older revision		Revision as of 20:29, 24 November 2023
Line 177:		Line 177:

	==== Option 2: Send checkpoint side changes back to the source side, then resume replication from source to destination ====		==== Option 2: Send checkpoint side changes back to the source side, then resume replication from source to destination ====
	[[File:Rollback ~~Stor~~ Rep - Web.jpg\|512px\|thumb\|Sending the changes made to the DR site checkpoints back to the source side.]]		[[File:Rollback Strg Rep - Web.jpg\|512px\|thumb\|Sending the changes made to the DR site checkpoints back to the source side.]]

	The process of sending the changes made to the DR site checkpoints back to the source side is called 'Rollback from Replica...' in QuantaStor and is done from the 'Volume & Share Replica Associations' section. Within that section one must select the link between a given source and destination and then choose 'Rollback from Replica...' in the pop-up menu. This must be done for each share and volume to be rolled back to the source side. '''Once the rollback activity is completed be sure''' to do a 'Rescan Storage Pools...' from the Storage Management-->Storage Pools section on each source side system. Once all the rollback replication activity has completed the source side will have a GMT snapshot with the same timestamp as the destination side. In effect rollback is done by taking a snapshot of the destination side changes and then sending these delta based incremental changes back to the source side volume/share. Use caution with this as the source side will be an identical copy of the destination after rollback so any changes made to the source side will be overwritten.		The process of sending the changes made to the DR site checkpoints back to the source side is called 'Rollback from Replica...' in QuantaStor and is done from the 'Volume & Share Replica Associations' section. Within that section one must select the link between a given source and destination and then choose 'Rollback from Replica...' in the pop-up menu. This must be done for each share and volume to be rolled back to the source side. '''Once the rollback activity is completed be sure''' to do a 'Rescan Storage Pools...' from the Storage Management-->Storage Pools section on each source side system. Once all the rollback replication activity has completed the source side will have a GMT snapshot with the same timestamp as the destination side. In effect rollback is done by taking a snapshot of the destination side changes and then sending these delta based incremental changes back to the source side volume/share. Use caution with this as the source side will be an identical copy of the destination after rollback so any changes made to the source side will be overwritten.

	After the data has been sent (rolled-back from DR site) use the steps from Option 1 to resume regular replication.		After the data has been sent (rolled-back from DR site) use the steps from Option 1 to resume regular replication.

Qadmin: /* Automatic DR Failover - Activating Checkpoints via VIF */

2023-11-24T20:22:16Z

Automatic DR Failover - Activating Checkpoints via VIF

← Older revision		Revision as of 20:22, 24 November 2023
Line 149:		Line 149:
	=== Automatic DR Failover - Activating Checkpoints via VIF ===		=== Automatic DR Failover - Activating Checkpoints via VIF ===

	[[File:Mod Rplctn Schd - Auto Activation.jpg\|600px\|thumb\|Choose 'Enable Automatic Checkpoint Activation' then a Site Cluster VIF to activate the schedule on.]]		[[File:Mod Rplctn Schd - Auto Activation.jpg\|600px\|thumb\|Choose 'Enable Automatic Checkpoint Activation' then a Site Cluster VIF to activate the schedule.]]

	In some environments it may be preferable to have the DR site checkpoints activate automatically in the event of an outage of a given primary site. This may be easily setup by creating a 'Site Cluster' in the 'High-availability VIF Management' section. The Site Cluster must spans the source and destination systems so that when the source side system goes offline the VIF will automatically move to the destination side. After the 'Site Cluster' is created one will next create a Site VIF (virtual network interface). When the VIF becomes active at the destination side it will automatically activate the Remote Replication Schedule's checkpoints just as if it was done manually using the Activate Checkpoints dialog. Once the VIF has been created within the Site Cluster choose the 'Modify Remote Replication Schedule' option in the WUI and then select the 'Automatic Activation' tab. Within there select the 'Enable Automatic Checkpoint Activation' option and then choose the VIF to activate on.		In some environments it may be preferable to have the DR site checkpoints activate automatically in the event of an outage of a given primary site. This may be easily setup by creating a 'Site Cluster' in the 'High-availability VIF Management' section. The Site Cluster must spans the source and destination systems so that when the source side system goes offline the VIF will automatically move to the destination side. After the 'Site Cluster' is created one will next create a Site VIF (virtual network interface). When the VIF becomes active at the destination side it will automatically activate the Remote Replication Schedule's checkpoints just as if it was done manually using the Activate Checkpoints dialog. Once the VIF has been created within the Site Cluster choose the 'Modify Remote Replication Schedule' option in the WUI and then select the 'Automatic Activation' tab. Within there select the 'Enable Automatic Checkpoint Activation' option and then choose the VIF to activate.

	=== Resolving DR Failover - Deactivating Checkpoints ===		=== Resolving DR Failover - Deactivating Checkpoints ===