On- and Off-site Data Protection - Revision history

Pa-P at 13:45, 22 September 2020

2020-09-22T13:45:11Z

← Older revision		Revision as of 13:45, 22 September 2020
Line 11:		Line 11:
	For each source volume we can set up a single backup volume or multiple backup volumes. The interval-retention plan can be separately defined on the source volume and any destination backup volumes.		For each source volume we can set up a single backup volume or multiple backup volumes. The interval-retention plan can be separately defined on the source volume and any destination backup volumes.

	Only Scale Logic ~~Genesis~~ NX2 can be used as a backup destination server.		Only Scale Logic NX2 can be used as a backup destination server.

	Storage snapshots are not applications memory consistent, but most Windows OS and applications, including MS-SQL, and Linux virtual machines running on protected volumes can start from exported and mounted backup volumes without any problem.		Storage snapshots are not applications memory consistent, but most Windows OS and applications, including MS-SQL, and Linux virtual machines running on protected volumes can start from exported and mounted backup volumes without any problem.
Line 88:		Line 88:

	:The OODP CLI provides detailed syntax help.		:The OODP CLI provides detailed syntax help.
	:Only Scale Logic ~~Genesis~~ NX2 can be used as a destination server.		:Only Scale Logic NX2 can be used as a destination server.<br/>
	:Replication will not be done as long as the destination dataset or zvol does not exist. User needs to create the destination dataset/zvol manually.		:Replication will not be done as long as the destination dataset or zvol does not exist. User needs to create the destination dataset/zvol manually.
	:Replication will not be done if the dataset or zvol on destination node is used e.g. by iSCSI Target with an active session. Data from a particular snapshot can be accessed only via a clone created from the snapshot.		:Replication will not be done if the dataset or zvol on destination node is used e.g. by iSCSI Target with an active session. Data from a particular snapshot can be accessed only via a clone created from the snapshot.

Ma-W at 09:32, 12 March 2020

2020-03-12T09:32:59Z

← Older revision		Revision as of 09:32, 12 March 2020
Line 38:		Line 38:

	It is recommended to put the auto-skip instruction as the first line in the VM Annotations, but it will work also if it is found in any place of the VM annotations.		It is recommended to put the auto-skip instruction as the first line in the VM Annotations, but it will work also if it is found in any place of the VM annotations.



	~~'''Clustered environment:'''~~

	It is possible to use OODP in a clustered environment when both source and destination are clusters (two pairs of clusters). Each source node must then attach to each destination node using its physical IP address and tasks must be created with IP of the destination cluster ("VIP" Virtual IP).

	~~In the following configuration: source (cluster) -> destination (single node), if the destination node is inaccessible over network, it will not stop the failover process on the source (cluster).~~

	Ongoing replication processes are stopped in case of an automatic failover or manual ‘move’ operation. It applies only to the moved pools. Replication processes connected with different pools will remain and continue to function.

	<br/>'''OODP Working modes:'''		<br/>'''OODP Working modes:'''

Ma-W: 1 revision

2019-03-28T13:46:42Z

1 revision

← Older revision	Revision as of 13:46, 28 March 2019
(No difference)

Ma-W at 15:09, 27 March 2019

2019-03-27T15:09:39Z

@@ Line 1: / Line 1: @@
 OODP feature creates rotational auto-snapshots of a volume (dataset or zvol) according to user-defined retention-interval plans, and asynchronously replicates snapshots delta to local (on-site) or remote (off-site) destinations.
@@ Line 39: / Line 38: @@
 It is recommended to put the auto-skip instruction as the first line in the VM Annotations, but it will work also if it is found in any place of the VM annotations.
 <br/>'''OODP Working modes:'''

migrate>Ka-P at 13:14, 20 December 2018

2018-12-20T13:14:26Z

← Older revision		Revision as of 13:14, 20 December 2018
Line 1:		Line 1:
	<p dir="ltr" style="line-height:1.38; margin-top:0pt; margin-bottom:0pt; text-align: center"></p>		<p dir="ltr" style="line-height:1.38; margin-top:0pt; margin-bottom:0pt; text-align: center"></p>
	OODP feature creates rotational auto-snapshots of a volume (dataset or zvol) according to user-defined retention-interval plans, and asynchronously replicates snapshots delta to local (on-site) or remote (off-site) destinations.		OODP feature creates rotational auto-snapshots of a volume (dataset or zvol) according to user-defined retention-interval plans, and asynchronously replicates snapshots delta to local (on-site) or remote (off-site) destinations.

Line 39:		Line 39:

	It is recommended to put the auto-skip instruction as the first line in the VM Annotations, but it will work also if it is found in any place of the VM annotations.		It is recommended to put the auto-skip instruction as the first line in the VM Annotations, but it will work also if it is found in any place of the VM annotations.



	~~'''Clustered environment:'''~~

	It is possible to use OODP in a clustered environment when both source and destination are clusters (two pairs of clusters). Each source node must then attach to each destination node using its physical IP address and tasks must be created with IP of the destination cluster ("VIP" Virtual IP).

	~~In the following configuration: source (cluster) -> destination (single node), if the destination node is inaccessible over network, it will not stop the failover process on the source (cluster).~~

	Ongoing replication processes are stopped in case of an automatic failover or manual ‘move’ operation. It applies only to the moved pools. Replication processes connected with different pools will remain and continue to function.

	<br/>'''OODP Working modes:'''		<br/>'''OODP Working modes:'''

migrate>To-K: To-K moved page Off-Site Data Protection Service to On- and Off-site Data Protection

2018-01-03T08:39:16Z

To-K moved page Off-Site Data Protection Service to On- and Off-site Data Protection

← Older revision	Revision as of 08:39, 3 January 2018
(No difference)

migrate>Ma-F at 15:25, 29 December 2017

2017-12-29T15:25:29Z

← Older revision		Revision as of 15:25, 29 December 2017
Line 122:		Line 122:
	:Save settings mechanism does not support OODP tasks (this does not apply for attached nodes). All information regarding OODP tasks are stored as dataset properties. If the dataset does not exist, the OODP task will not be restored.		:Save settings mechanism does not support OODP tasks (this does not apply for attached nodes). All information regarding OODP tasks are stored as dataset properties. If the dataset does not exist, the OODP task will not be restored.

	'''~~Important notes (clustered environment)~~:'''		'''Known issues:'''

	#It is possible to use ODPS in a clustered environment when both source and destination are clusters (two pairs of clusters). Each source node must then attach to each destination node using its physical IP address and tasks must be created with IP of destination cluster "VIP" Virtual IP.		*Source and destination should be of the same type (zvol-zvol, dataset-dataset). It is possible to create a task with source e.g. zvol and destination - dataset but when started, it shows error.
	~~#In following configuration: source (cluster) -> destination (single node) when destination node is inaccessible over network then it will not break failover on source (cluster).~~		*Temporary errors on GUI: OODP can cause temporary inconsistency of internal GUI cache (used by API in Python) with zfs resources. This temporary inconsistency can lead to errors displayed in the GUI that inform about missing snapshots. This issue happens because OODP refreshes the cache using a hook script. Cache is refreshed before and after any snapshot is removed by OODP. But using a hook script (only possible way of cache refresh when using external software) leaves a small window when cache is inconsistent. If GUI requests information about snapshots in time between snapshot removal and cache refresh, then cache is inconsistent and GUI gets information about non existing items which may lead to errors. Most common place of this error is the volume edition - snapshots are checked in this window in order to lock the edition of name if volume has any snapshots. The issue is only temporary and cache is refreshed when window is closed and reopened. In such case, the error will not pop up because cache is consistent again.
	#Ongoing replication processes are killed when automatic failover is performed or manual move is performed. It applies only for moved pools. replication processes connected with different pools will remain and continue to function.

	~~  '''Known issues:'''~~

	*Source and destination should be of the same type (zvol-zvol, dataset-dataset). It is possible to create task with source ~~for example~~ zvol and destination - ~~ ~~dataset but when started it shows error.
	*Temporary errors on GUI: ~~ODPS~~ can cause temporary inconsistency of internal GUI cache (used by API in Python) with zfs resources. This temporary inconsistency can lead to errors displayed in the GUI that inform about missing~~ ~~ snapshots. This issue happens because ~~ODPS~~ refreshes the cache using a hook script~~, cache~~ is refreshed before and after any snapshot is removed by ~~ODPS~~. But using a hook script (only possible way of cache refresh when using external software) leaves small window when cache is inconsistent. If GUI requests information about snapshots in time between snapshot removal and cache refresh ~~than~~ cache is inconsistent and GUI gets information about ~~none~~ existing items which may lead to errors. Most common place of this error is volume edition - snapshots are checked in this window in order to lock edition of name if volume has any snapshots. The issue is only temporary and cache is refreshed when window is closed and reopened ~~then~~ the error will not pop up because cache is consistent again.



	[[Category:Help topics]]		[[Category:Help topics]]

migrate>Ma-F at 15:23, 29 December 2017

2017-12-29T15:23:21Z

← Older revision		Revision as of 15:23, 29 December 2017
Line 98:		Line 98:
	<br/>'''Important notes''':		<br/>'''Important notes''':

	~~#ODPS is managed via CLI.~~ The ~~ODPS~~ CLI provides detailed syntax help.		:The OODP CLI provides detailed syntax help.
	#Only Genesis NX2 can be used as a destination ~~node~~.		:Only Scale Logic Genesis NX2 can be used as a destination server.
	#Replication will not be done as long as destination dataset or zvol does not exist. User needs to create destination dataset/zvol manually.		:Replication will not be done as long as the destination dataset or zvol does not exist. User needs to create the destination dataset/zvol manually.
	#Replication will not be done if dataset or zvol on destination is used e.g. by iSCSI Target with active session. Data from particular snapshot can be accessed only via a clone created from the snapshot.		:Replication will not be done if the dataset or zvol on destination node is used e.g. by iSCSI Target with an active session. Data from a particular snapshot can be accessed only via a clone created from the snapshot.
	#User snapshots created on destination dataset or zvol will be deleted by ~~ODPS service~~ during rotation round.		:User snapshots created on the destination dataset or zvol will be deleted by OODP during rotation round.
	#User snapshots created on source dataset or zvol are not deleted by ~~ODPS service~~ during rotation round.		:User snapshots created on the source dataset or zvol are not deleted by OODP during rotation round.
	#Snapshots on both source and destination that are cloned are not deleted by ~~ODPS service~~ during rotation round.		:Snapshots on both source and destination that are cloned are not deleted by OODP during rotation round.
	~~#When a replication~~ round fails due to the fact that it is not possible to replicate a snapshot to destination e.g. caused by:		:Replication round fails due to the fact that it is not possible to replicate a snapshot to destination e.g. caused by:
	##Lack of communication between nodes		::Lack of communication between nodes
	##Busy dataset on destination (used e.g. by iSCSI Target)		::Busy dataset on destination server (used e.g. by iSCSI Target)
	##Existence of user’s own snapshot with clone on destination,		::Existence of user’s own snapshot with a clone on destination server,
	~~##Existence of~~ user’s ~~own~~ snapshot on destination created before first replication ~~then~~ source snapshots ~~are~~ not rotated. ~~At the~~ next ~~round of~~ replication ~~when conditions to replication are passed then~~ rotation of snapshots on both source and destination is performed.		::If user’s manual snapshot on destination server was created before the first replication, the source snapshots will not be rotated. During next replication the rotation of snapshots on both source and destination is performed, provided that all replication requirements are fulfilled
	~~#When~~ nodes have different sets of snapshots (no common snapshot between source and destination) ~~then~~ snapshots on destination are deleted and re-replicated from source.		:If nodes have different sets of snapshots (no common snapshot between source and destination), snapshots on destination server are deleted and re-replicated from the source.
	~~#ODPS service~~ is activated when at least one backup task ~~exist~~ in the system (at pool import and system start).		:OODP is activated when at least one backup task exists in the system ( at pool import and system start).
	~~#ODPS service~~ is deactivated when ~~there’s~~ no backup tasks in the system (at pool export).		:OODP is deactivated when there are no backup tasks in the system (at pool export).
	#Replication to remote destination is encrypted (SSH).		:Replication to remote destination is encrypted (SSH).
	~~#ODPS~~ replication processes are ~~killed~~ at pool export/destroy.		:OODP replication processes are stopped at pool export/destroy.
	#Ongoing replication process is not ~~killed~~ when ~~ODPS~~ task is deleted. After finishing this process ~~there’s~~ no more replications.		:Ongoing replication process is not stopped when OODP task is deleted. After finishing this process there are no more replications.
	#When backup plan is created ~~like this~~: 1min_every_10min backup task ~~won't~~ start. Retention time must be ~~always~~ larger than the interval: 10min_every_1min.		:When the backup plan is created as follows: 1min_every_10min, the backup task will not start. Retention time must always be larger than the interval: 10min_every_1min.
	#The Source snapshot that is being replicated (replication of older snapshot is still in progress)~~ ~~blocks rotation of snapshots on source. New snapshots ~~however~~ are created according to the scheduled plan.		:The Source snapshot that is being replicated (replication of older snapshot is still in progress) blocks the rotation of snapshots on source. New snapshots are created according to the scheduled plan.
	~~#When~~ many ~~destinations~~ used only one replication is performed at given time.		:In case many destination servers are used, only one replication is performed at given time.
	#It is not recommended to create ~~own~~ snapshots on destination ~~nodes~~. This may break synchronization process. If access ~~is needed for~~ the data on destination use snapshots created by ~~ODPS~~.		:It is not recommended to create manual snapshots on destination servers. This may break the synchronization process. If access to the data on the destination server is required, use snapshots created by OODP.
	#Save settings mechanism does not support ~~ODPS~~ tasks (this does not apply for attached nodes). All information ~~connected with ODPS~~ tasks are stored as ~~ ~~dataset properties. If the dataset does not exist ~~then ODPS~~ task is not restored.		:Save settings mechanism does not support OODP tasks (this does not apply for attached nodes). All information regarding OODP tasks are stored as dataset properties. If the dataset does not exist, the OODP task will not be restored.

	'''Important notes (clustered environment):'''		'''Important notes (clustered environment):'''

migrate>Ma-F at 15:18, 29 December 2017

2017-12-29T15:18:47Z

← Older revision		Revision as of 15:18, 29 December 2017
Line 79:		Line 79:
	GUI provides a step-by-step wizard to define the replication tasks.		GUI provides a step-by-step wizard to define the replication tasks.

	~~<br/>~~'''~~Options~~''':

			'''If CLI is used to define the replication tasks, the following tasks options are provided''':

	#It is possible to attach, list and detach backup nodes (remote nodes used for the asynchronous replication)		#It is possible to attach, list and detach backup nodes (remote nodes used for the asynchronous replication)
	#It is possible to create a backup task in following modes:		#It is possible to create a backup task in the following modes:
	##Only source node details provided -> snapshots created locally, no replication.		##Only source node details provided -> snapshots created locally, no replication.
	##Source and destination node details provided -> snapshots created locally and replicated to destination. Un-Kh source and destination keep rotational auto-snapshots.		##Source and destination node details provided -> snapshots created locally and replicated to destination. Un-Kh source and destination keep rotational auto-snapshots.
	##Optionally it is possible to use mbuffer (with parameter ''mbuffer size'') as a tool for buffering data streams.		##Optionally, it is possible to use mbuffer (with parameter mbuffer size) as a tool for buffering data streams.
	#It is possible to get details of all backup tasks.		#It is possible to get details of all backup tasks.
	#It is possible to delete backup task.		#It is possible to delete the backup task.
	#It is possible to get status of the ~~ODPS~~ service:		#It is possible to get the status of the ODP service:
	##Service status		##Service status
	##Last entries from logs		##Last entries from logs
	#It is possible to debug backup task - run it in dry mode in order to check ~~what’s wrong~~.		#It is possible to debug the backup task - run it in dry mode in order to check what is the issue.
	#It is possible to restart all tasks so configuration of tasks will be reset.		#It is possible to restart all tasks - configuration of tasks will be reset.

	'''Important notes''':		<br/>'''Important notes''':

	#ODPS is managed via CLI. The ODPS CLI provides detailed syntax help.		#ODPS is managed via CLI. The ODPS CLI provides detailed syntax help.

migrate>Ma-F at 15:16, 29 December 2017

2017-12-29T15:16:04Z

← Older revision		Revision as of 15:16, 29 December 2017
Line 28:		Line 28:
	Following syntax options are accepted:		Following syntax options are accepted:

	'##<code>auto-snap-skip##8:45..12:30,13:15..18:30##Mon..Fri##</code>		##<code>auto-snap-skip##8:45..12:30,13:15..18:30##Mon..Fri##</code>

	'##<code>auto-snap-skip##08:45..12:30,13:15..18:45##Mon..Fri##</code>		##<code>auto-snap-skip##08:45..12:30,13:15..18:45##Mon..Fri##</code>

	'##<code>auto-snap-skip##08:45..12:30,1:15PM..6:45PM##Mon..Fri##</code>		##<code>auto-snap-skip##08:45..12:30,1:15PM..6:45PM##Mon..Fri##</code>

	'##<code>auto-snap-skip##08:45..12:30,13:15..18:45##Mon,Tue,Wed,Thu,Fri##</code>		##<code>auto-snap-skip##08:45..12:30,13:15..18:45##Mon,Tue,Wed,Thu,Fri##</code>


Line 66:		Line 66:
	'''Retention plans''':		'''Retention plans''':

	The ~~ODPS '''~~retention~~'''~~-~~'''~~interval ~~'''~~plan consists of a series of retention periods to interval associations~~: "retention_every_interval''','''retention_every_interval''','''retention_every_interval''','''~~..~~.". Example:   1hour_every_10min''','''3day_every_1hour''','''1month_every_1day Un~~-~~Kh intervals and retention periods~~ use ~~standard units of time or multiples of them, with full names or a shortcut according to the~~ following ~~list~~: second\|sec\|s, minute\|min, hour\|h, day\|d, week\|w, month\|mon\|m, year\| Rotational auto-snapshots on both source and destination are created according to retention plans. It is possible to have different retention plans for source and destination pool.		The ODP retention-interval plan consists of a series of retention periods to interval associations. It can be intuitively defined in the replication task wizard on the GUI. If CLI is used the retention-interval use following syntax:

	'''Options''':		"retention_every_interval,retention_every_interval,retention_every_interval,...".

			Example: 1hour_every_10min,3day_every_1hour,1month_every_1day


			Un-Kh intervals and retention periods use standard units of time or multiples of them, with full names or a shortcut according to the following list: second\|sec\|s, minute\|min, hour\|h, day\|d, week\|w, month\|mon\|m, year\|

			<br/>Rotational auto-snapshots on both source and destination are created according to retention plans. It is possible to have different retention plans for source and destination pool.

			GUI provides a step-by-step wizard to define the replication tasks.

			<br/>'''Options''':

	#It is possible to attach, list and detach backup nodes (remote nodes used for the asynchronous replication)		#It is possible to attach, list and detach backup nodes (remote nodes used for the asynchronous replication)