Appboard/2.5/admin/backup and recovery - Revision history

imported>Jason.nicholls: /* Overview */

2015-04-30T11:25:01Z

Overview

← Older revision		Revision as of 11:25, 30 April 2015
Line 18:		Line 18:
	* provide a mechanism to migrate configuration from one environment to another, for example from development, to staging, to production.		* provide a mechanism to migrate configuration from one environment to another, for example from development, to staging, to production.
	* used when upgrading AppBoard itself.		* used when upgrading AppBoard itself.
	* used in cluster configurations (refer to [[appboard/2.4/admin/clustering_and_failover\|Clustering & Failover]])		* used in cluster configurations (refer to [[appboard/2.5/admin/clustering_and_failover\|Clustering & Failover]])
	* provide a way for Edge to further investigate support issues - sometimes we may request a backup archive.		* provide a way for Edge to further investigate support issues - sometimes we may request a backup archive.


	== Creating Backups ==		== Creating Backups ==

imported>Jason.nicholls: /* Loading Backups (archives) */

2015-04-07T09:15:12Z

Loading Backups (archives)

← Older revision		Revision as of 09:15, 7 April 2015
Line 104:		Line 104:
	# in a terminal, change into the <tt>[INSTALL_HOME]/server/bin</tt> directory		# in a terminal, change into the <tt>[INSTALL_HOME]/server/bin</tt> directory
	# run: <tt>portal ''<Load_Type>'' -jar ''<backup_archive.jar>''</tt>		# run: <tt>portal ''<Load_Type>'' -jar ''<backup_archive.jar>''</tt>
	# (Linux / UNIX) re-run <tt>post_install.sh</tt><br>This is required to ensure correct ownership, permissions, and any included scripts are set executable as jar archives do not store this information.		# (Linux / UNIX) re-run <tt>post_install.sh</tt><br>This is required to ensure correct system configuration and file ownership, permissions, and any included scripts are set executable as jar archives do not store this information.
	# start AppBoard		# start AppBoard

imported>Jason.nicholls: /* Loading Backups (archives) */

2015-04-07T09:12:46Z

Loading Backups (archives)

← Older revision		Revision as of 09:12, 7 April 2015
Line 104:		Line 104:
	# in a terminal, change into the <tt>[INSTALL_HOME]/server/bin</tt> directory		# in a terminal, change into the <tt>[INSTALL_HOME]/server/bin</tt> directory
	# run: <tt>portal ''<Load_Type>'' -jar ''<backup_archive.jar>''</tt>		# run: <tt>portal ''<Load_Type>'' -jar ''<backup_archive.jar>''</tt>
	# (Linux / UNIX) re-run <tt>post_install.sh</tt>		# (Linux / UNIX) re-run <tt>post_install.sh</tt><br>This is required to ensure correct ownership, permissions, and any included scripts are set executable as jar archives do not store this information.
	# start AppBoard		# start AppBoard

imported>Mike.berman: /* Customizing the Export */ added custom LAF example per SUP-753

2014-11-28T21:51:51Z

Customizing the Export: added custom LAF example per SUP-753

← Older revision		Revision as of 21:51, 28 November 2014
Line 70:		Line 70:
	${webapp.xmlroot}/appboard/config/iconregistry/custom_icons.csv;\		${webapp.xmlroot}/appboard/config/iconregistry/custom_icons.csv;\
	${webapp.home}/visualizer/assets/images/custom_banner_logo.png;\		${webapp.home}/visualizer/assets/images/custom_banner_logo.png;\
			${webapp.home}/framework/laf/banner_my_custom_laf;\
	${webapp.webinf}/test_dir;\		${webapp.webinf}/test_dir;\
	${webapp.webinf}/image_dir,,,.*\.png		${webapp.webinf}/image_dir,,,.*\.png
	</pre>		</pre>

	In this example a DB driver, a icon registry file, a custom graphic, and the <tt>test_dir</tt> are specific paths to be exported. The last example specifies a path and file expression so that only files ending with <tt>.png</tt> are included.		In this example a DB driver, a icon registry file, a custom graphic, a custom Look and Feel (LAF), and the <tt>test_dir</tt> are specific paths to be exported. The last example specifies a path and file expression so that only files ending with <tt>.png</tt> are included.

	The format for each export rule is noted below. The initial <tt>Path</tt> is not a regular expression and must match exactly a single file or directory. <tt>PathExpression</tt> and <tt>FileExpression</tt> are ''regular expressions'', not wildcards. The use of the <tt>exclude</tt> keyword is optional and implies the preceding expression should be excluded.		The format for each export rule is noted below. The initial <tt>Path</tt> is not a regular expression and must match exactly a single file or directory. <tt>PathExpression</tt> and <tt>FileExpression</tt> are ''regular expressions'', not wildcards. The use of the <tt>exclude</tt> keyword is optional and implies the preceding expression should be excluded.

imported>Jason.nicholls: /* Customizing the Export */

2014-11-17T09:07:41Z

Customizing the Export

← Older revision		Revision as of 09:07, 17 November 2014
Line 63:		Line 63:
	Recommended best practice is to ensure that backups include all required files for a functioning system. In many cases this is handled automatically by placing custom files within the supplied ''custom'' directories. Some files fall outside this pattern however and to handle these it's necessary to customize the export file set by creating a <tt>custom.properties</tt> file and placing it into the <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/</tt> directory.		Recommended best practice is to ensure that backups include all required files for a functioning system. In many cases this is handled automatically by placing custom files within the supplied ''custom'' directories. Some files fall outside this pattern however and to handle these it's necessary to customize the export file set by creating a <tt>custom.properties</tt> file and placing it into the <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/</tt> directory.

	This file can be used for various overrides so it may exist for other purposes already. The key part is to define an <tt>export.custom.other</tt> property with ~~the~~ list of rules defining the export ~~list~~. This is a semi-colon (<tt>;</tt>) separated list, with the backslash character (<tt>\</tt>) used to split the list over multiple lines to improve readability. For example:		This file can be used for various overrides so it may exist for other purposes already. The key part is to define an <tt>export.custom.other</tt> property with a list of rules defining the files to export. This is a semi-colon (<tt>;</tt>) separated list, with the backslash character (<tt>\</tt>) used to split the list over multiple lines to improve readability. For example:

	<pre>		<pre>

imported>Jason.nicholls: /* Customizing the Export */

2014-11-17T09:05:10Z

Customizing the Export

← Older revision		Revision as of 09:05, 17 November 2014
Line 76:		Line 76:
	In this example a DB driver, a icon registry file, a custom graphic, and the <tt>test_dir</tt> are specific paths to be exported. The last example specifies a path and file expression so that only files ending with <tt>.png</tt> are included.		In this example a DB driver, a icon registry file, a custom graphic, and the <tt>test_dir</tt> are specific paths to be exported. The last example specifies a path and file expression so that only files ending with <tt>.png</tt> are included.

	The ~~full~~ export rule ~~format~~ is noted below. The initial <tt>Path</tt> is not a regular expression and must match exactly a single file or directory. <tt>PathExpression</tt> and <tt>FileExpression</tt> are ''regular expressions'', not wildcards. The use of the <tt>exclude</tt> keyword is optional and implies the preceding expression should be excluded.		The format for each export rule is noted below. The initial <tt>Path</tt> is not a regular expression and must match exactly a single file or directory. <tt>PathExpression</tt> and <tt>FileExpression</tt> are ''regular expressions'', not wildcards. The use of the <tt>exclude</tt> keyword is optional and implies the preceding expression should be excluded.

	<pre>		<pre>

imported>Jason.nicholls: /* Customizing the Export */

2014-11-17T09:04:22Z

Customizing the Export

← Older revision		Revision as of 09:04, 17 November 2014
Line 63:		Line 63:
	Recommended best practice is to ensure that backups include all required files for a functioning system. In many cases this is handled automatically by placing custom files within the supplied ''custom'' directories. Some files fall outside this pattern however and to handle these it's necessary to customize the export file set by creating a <tt>custom.properties</tt> file and placing it into the <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/</tt> directory.		Recommended best practice is to ensure that backups include all required files for a functioning system. In many cases this is handled automatically by placing custom files within the supplied ''custom'' directories. Some files fall outside this pattern however and to handle these it's necessary to customize the export file set by creating a <tt>custom.properties</tt> file and placing it into the <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/</tt> directory.

	This file can be used for various overrides so it may exist for other purposes already. The key part is to define an <tt>export.custom.other</tt> property with the list of rules defining the export list, ~~for~~ example:		This file can be used for various overrides so it may exist for other purposes already. The key part is to define an <tt>export.custom.other</tt> property with the list of rules defining the export list. This is a semi-colon (<tt>;</tt>) separated list, with the backslash character (<tt>\</tt>) used to split the list over multiple lines to improve readability. For example:

	<pre>		<pre>

imported>Jason.nicholls: /* Customizing the Export */

2014-11-17T08:58:40Z

Customizing the Export

← Older revision		Revision as of 08:58, 17 November 2014
Line 63:		Line 63:
	Recommended best practice is to ensure that backups include all required files for a functioning system. In many cases this is handled automatically by placing custom files within the supplied ''custom'' directories. Some files fall outside this pattern however and to handle these it's necessary to customize the export file set by creating a <tt>custom.properties</tt> file and placing it into the <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/</tt> directory.		Recommended best practice is to ensure that backups include all required files for a functioning system. In many cases this is handled automatically by placing custom files within the supplied ''custom'' directories. Some files fall outside this pattern however and to handle these it's necessary to customize the export file set by creating a <tt>custom.properties</tt> file and placing it into the <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/</tt> directory.

	This file can be used for various overrides so it may exist for other purposes already. The key part is to define an <tt>export.custom.other</tt> property with the list of ~~files to be exported~~, so for example:		This file can be used for various overrides so it may exist for other purposes already. The key part is to define an <tt>export.custom.other</tt> property with the list of rules defining the export list, for example:

	<pre>		<pre>

imported>Jason.nicholls: /* Customizing the Export */

2014-11-17T08:53:26Z

Customizing the Export

← Older revision		Revision as of 08:53, 17 November 2014
Line 82:		Line 82:
	</pre>		</pre>

	To verify the ~~export~~ contains the files, ~~perform a backup and simply~~ unzip ~~the file~~ to ~~inspect (or rename~~ to <tt>.zip</tt>).
			After making changes to the set of excludes perform a backup and verify the resulting (.jar) archive contains the desired set of files. The archive can be uncompressed using unzip, depending on the unzip tool it may need to be renamed to end with <tt>.zip</tt>.

	=== Unattended Backups ===		=== Unattended Backups ===

imported>Jason.nicholls: /* Customizing the Export */

2014-11-17T08:48:47Z

Customizing the Export

← Older revision		Revision as of 08:48, 17 November 2014
Line 61:		Line 61:

	=== Customizing the Export ===		=== Customizing the Export ===
	Recommended best ~~practices~~ is to ensure that backups include all required files for a functioning system. In many cases this is handled automatically by placing custom files within the supplied ''custom'' directories. Some files fall outside this pattern however and to handle these it's necessary to customize the export file set by creating a <tt>custom.properties</tt> file and placing it into the <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/</tt> directory.		Recommended best practice is to ensure that backups include all required files for a functioning system. In many cases this is handled automatically by placing custom files within the supplied ''custom'' directories. Some files fall outside this pattern however and to handle these it's necessary to customize the export file set by creating a <tt>custom.properties</tt> file and placing it into the <tt>[INSTALL_HOME]/server/webapps/enportal/WEB-INF/config/</tt> directory.

	This file can be used for various overrides so may exist for other purposes already. The key part is to define a <tt>export.custom.other</tt> property with the list of files to be exported~~. This is a semi-colon (<tt>;</tt>) separated list~~, ~~with the backslash character (<tt>\</tt>) used to split the list over multiple lines to improve readability. For~~ example:		This file can be used for various overrides so it may exist for other purposes already. The key part is to define an <tt>export.custom.other</tt> property with the list of files to be exported, so for example:

	<pre>		<pre>
	# below is a list of additional files to export on a full backup		# below is a list of additional files to export on a full backup
	export.custom.other=${webapp.webinf}/lib/mysql-connector-java-5.1.~~19.jar;\~~		export.custom.other=${webapp.webinf}/lib/mysql-connector-java-5.1.34.jar;\
	~~${webapp.webinf}/lib/jtds-1.2.4~~.jar;\
	${webapp.xmlroot}/appboard/config/iconregistry/custom_icons.csv;\		${webapp.xmlroot}/appboard/config/iconregistry/custom_icons.csv;\
	${webapp.home}/visualizer/assets/images/custom_banner_logo.png		${webapp.home}/visualizer/assets/images/custom_banner_logo.png;\
			${webapp.webinf}/test_dir;\
			${webapp.webinf}/image_dir,,,.*\.png
	</pre>		</pre>

	In this example ~~two~~ DB driver ~~files~~, a icon registry file, ~~and~~ a custom graphic ~~will~~ be included ~~in the export~~.		In this example a DB driver, a icon registry file, a custom graphic, and the <tt>test_dir</tt> are specific paths to be exported. The last example specifies a path and file expression so that only files ending with <tt>.png</tt> are included.

	To verify the export contains the files ~~then~~ perform a backup and simply unzip the file to inspect (or rename to <tt>.zip</tt>).		The full export rule format is noted below. The initial <tt>Path</tt> is not a regular expression and must match exactly a single file or directory. <tt>PathExpression</tt> and <tt>FileExpression</tt> are ''regular expressions'', not wildcards. The use of the <tt>exclude</tt> keyword is optional and implies the preceding expression should be excluded.

			<pre>
			<Path>,<PathExpression>,exclude,<FileExpression>,exclude,<FileExpression>,exclude,...
			</pre>

			To verify the export contains the files, perform a backup and simply unzip the file to inspect (or rename to <tt>.zip</tt>).

	=== Unattended Backups ===		=== Unattended Backups ===