Safe Upgrading - Revision history

Th.lauke@arcor.de: excluding reproducible dir added, some reformatting

2024-05-08T15:27:23Z

excluding reproducible dir added, some reformatting

← Older revision		Revision as of 15:27, 8 May 2024
Line 63:		Line 63:
	and then		and then

	tar czf <eprints_root>/backups/<archive_id>.archive.backup.-<year>-<month>-<day>.tgz <archive_id>		tar czf <eprints_root>/backups/<archive_id>.archive.backup-<year>-<month>-<day>.tgz <archive_id>

	to create a zipped backup of your entire repository including static pages, documents, files and configuration. This can take a long time, for large repositories it can be several hours.		to create a zipped backup of your entire repository including static pages, documents, files and configuration. This can take a long time, for large repositories it can be several hours.

			Depending on the output of
			du -sh {var/xapian,html}
			you may prefer if you are short of disk space to exclude some big directories which are reproducible (maybe in some hours!). If it makes sense for you backup
			your archive by
			tar --exclude=<archive_id>/{var/xapian,html} -cvzf <eprints_root>/backups/<archive_id>.archive.backup-<year>-<month>-<day>.tgz <archive_id>

	===Backup your perl_lib===		===Backup your perl_lib===

	This step should not be necessary if you have followed the guide for [[Tips_to_write_plugins\|making safe plugins]]. If you didn't follow the guide and modified perl_lib (for shame) or you are particularly paranoid you may want to backup your perl_lib directory.		This step should not be necessary if you have followed the guide for [[Tips_to_write_plugins\|making safe plugins]]. If you didn't follow the guide and modified <code>perl_lib</code> (for shame) or you are particularly paranoid you may want to backup your <code>perl_lib</code> directory.

	cd <eprints_root>		cd <eprints_root>
Line 75:		Line 81:
	and then		and then

	tar czf backups/<archive_id>.archive.backup.-<year>-<month>-<day>.tgz <perl_lib>		tar czf backups/<archive_id>.archive.backup-<year>-<month>-<day>.tgz <perl_lib>

	You should now be ready to upgrade.		You should now be ready to upgrade.

Th.lauke@arcor.de: some typos corrected

2022-12-29T18:29:42Z

some typos corrected

← Older revision		Revision as of 18:29, 29 December 2022
Line 49:		Line 49:
	mysqldump -u <db_user> -p <db_name> > <archive_id>.archive.backup-<year>-<month>-<day>.sql		mysqldump -u <db_user> -p <db_name> > <archive_id>.archive.backup-<year>-<month>-<day>.sql

	at the prompt you will need to enter the password. If your repository is large this step can take a while. The purpose of the elaborate file name is so that at a glance you can tell what this file is. Also if you have multiple backups then ordering them alphabetically will put the backups for that archive in date order so you can find your most recent backup. Ending the file with .sql means you know it is a database backup.		at the prompt you will need to enter the ''password''. If your repository is large this step can take a while. The purpose of the elaborate file name is so that at a glance you can tell what this file is. Also if you have multiple backups then ordering them alphabetically will put the backups for that archive in date order so you can find your most recent backup. Ending the file with .sql means you know it is a database backup.

	If you do not no your db_user db_name or password for the above step you can find it by typing:		If you do not know your <code>db_user</code>, <code>db_name</code> or ''password'' for the above step you can find it by typing:

	cat <eprints_root/archives/<archive_id>/cfg/cfg.d/database.pl		cat <eprints_root>/archives/<archive_id>/cfg/cfg.d/database.pl

	You should now have a .sql file containing your database backup in your <eprints_root>/backups directory.		You should now have a .sql file containing your database backup in your <eprints_root>/backups directory.

Th.lauke@arcor.de: tar command corrected

2022-12-29T18:25:45Z

tar command corrected

← Older revision		Revision as of 18:25, 29 December 2022
Line 75:		Line 75:
	and then		and then

	tar czf ~~<eprints_root>/~~backups/<archive_id>.archive.backup.-<year>-<month>-<day>.tgz <~~archive_id~~>		tar czf backups/<archive_id>.archive.backup.-<year>-<month>-<day>.tgz <perl_lib>

	You should now be ready to upgrade.		You should now be ready to upgrade.

Th.lauke@arcor.de: spelling corrected

2022-12-29T18:23:51Z

spelling corrected

← Older revision		Revision as of 18:23, 29 December 2022
Line 15:		Line 15:
	===Tell an adult===		===Tell an adult===

	Talk to your system administrator about getting a full system backup made. It is advisable to do this fairly regularly anyway in case of hardware failure or fire~~. See~~ [[Backups\|backing up]]		Talk to your system administrator about getting a full system backup made. It is advisable to do this fairly regularly anyway in case of hardware failure or fire (see [[Backups\|backing up]]).

	You should also speak to who ever you need to get permission from to cause server down time. This is not always required as many upgrades can be done with very little down time but it is best to ask for permission and not use it than find you have to apologize for an unexpected service outage.		You should also speak to who ever you need to get permission from to cause server down time. This is not always required as many upgrades can be done with very little down time but it is best to ask for permission and not use it than find you have to apologize for an unexpected service outage.

Th.lauke@arcor.de: usage of sub-version corrected

2022-12-29T18:22:35Z

usage of sub-version corrected

← Older revision		Revision as of 18:22, 29 December 2022
Line 3:		Line 3:
	==Am I Upgrading?==		==Am I Upgrading?==

	Upgrading is when you intend to update eprints code base on a server to a later version. Upgrading covers moves from EPrints 3.x.y to 3.a.b if you want to move from EPrints 2.x.y to 3.a.b then you are undertaking a migration. Also if you are moving your EPrints repository from one server to another you are migrating. Upgrading is ~~the same~~ sub-version of EPrints on the same server.		Upgrading is when you intend to update eprints code base on a server to a later version. Upgrading covers moves from EPrints 3.x.y to 3.a.b if you want to move from EPrints 2.x.y to 3.a.b then you are undertaking a migration. Also if you are moving your EPrints repository from one server to another you are migrating. Upgrading is just a different sub-version (but same main version) of EPrints on the same server.

	==Preparation==		==Preparation==

Th.lauke@arcor.de: typos corrected

2019-08-02T12:30:18Z

typos corrected

← Older revision		Revision as of 12:30, 2 August 2019
Line 1:		Line 1:
	You should really aim to upgrade your EPrints repository about once a year to keep on top of the new developments. Upgrading your EPrints repository can be a very daunting task. The aim of this page is to get people who are not confident about undertaking it into a position where it is safe to do so. Note upgrading is different to migrating (although some of the ~~proceedures~~ maybe the same).		You should really aim to upgrade your EPrints repository about once a year to keep on top of the new developments. Upgrading your EPrints repository can be a very daunting task. The aim of this page is to get people who are not confident about undertaking it into a position where it is safe to do so. Note upgrading is different to migrating (although some of the procedures maybe the same).

	==Am I Upgrading?==		==Am I Upgrading?==

	Upgrading is when you intend to update eprints code base on a server to a later version. Upgrading covers moves from EPrints 3.x.y to 3.a.b if you want to move from EPrints 2.x.y to 3.a.b then you are undertaking a migration. Also if you are moving your EPrints repository from one server to another you are migrating. Upgrading is the same sub-~~versions~~ of EPrints on the same server.		Upgrading is when you intend to update eprints code base on a server to a later version. Upgrading covers moves from EPrints 3.x.y to 3.a.b if you want to move from EPrints 2.x.y to 3.a.b then you are undertaking a migration. Also if you are moving your EPrints repository from one server to another you are migrating. Upgrading is the same sub-version of EPrints on the same server.

	==Preparation==		==Preparation==

	If you are upgrading then there are a number of precautions you can take to ensure the process runs as smoothly as possible. It is impossible to give 100% cast iron ~~garrentee~~ an upgrade will succeed particularly if you have a heavily customised repository so you must make sure that you are in position to roll back ~~should~~ in the unlikely event that the upgrade does not go to plan.		If you are upgrading then there are a number of precautions you can take to ensure the process runs as smoothly as possible. It is impossible to give 100% cast iron guarantee an upgrade will succeed particularly if you have a heavily customised repository so you must make sure that you are in position to roll back in the unlikely event that the upgrade does not go to plan.

	It is worth saying at this point that if possible you can ease your fears by performing this task on a development server as a practice run. This technique if available to you is strongly advised.		It is worth saying at this point that if possible you can ease your fears by performing this task on a development server as a practice run. This technique if available to you is strongly advised.
Line 15:		Line 15:
	===Tell an adult===		===Tell an adult===

	Talk to your system administrator about getting a full system backup made. It is advisable to do this fairly regularly anyway ~~incase~~ of hardware failure or fire. See [[Backups\|backing up]]		Talk to your system administrator about getting a full system backup made. It is advisable to do this fairly regularly anyway in case of hardware failure or fire. See [[Backups\|backing up]]

	You should also speak to who ever you need to get permission from to cause server down time. This is not always required as many upgrades can be done with very little down time but it is best to ask for permission and not use it than find you have to ~~appologise~~ for an unexpected service outage		You should also speak to who ever you need to get permission from to cause server down time. This is not always required as many upgrades can be done with very little down time but it is best to ask for permission and not use it than find you have to apologize for an unexpected service outage.

	===Create a backups directory===		===Create a backups directory===
Line 27:		Line 27:
	===Check you have enough disk space===		===Check you have enough disk space===

	df		df -h

	Will give you a table:		Will give you a table:
Line 39:		Line 39:
	</pre>		</pre>

	You should make sure that the disk which contains your eprints directory (usually /opt or /usr) is over 50% free. The backup of the archive will take up a similar ~~ammount~~ of space to the archive itself so you should check you have ~~room~~ for it before starting.		You should make sure that the disk which contains your eprints directory (usually /opt or /usr) is over 50% free. The backup of the archive will take up a similar amount of space to the archive itself so you should check you have enough space for it before starting.

	===Backup your database===		===Backup your database===
Line 49:		Line 49:
	mysqldump -u <db_user> -p <db_name> > <archive_id>.archive.backup-<year>-<month>-<day>.sql		mysqldump -u <db_user> -p <db_name> > <archive_id>.archive.backup-<year>-<month>-<day>.sql

	at the prompt you will need to enter the password. If your repository is large this step can take a while. The purpose of the ~~elabourate~~ file name is so that at a glance you can tell what this file is. Also if you have multiple backups then ordering them alphabetically will put the backups for that archive in date order so you can find your most recent backup. Ending the file with .sql means you know it is a database backup.		at the prompt you will need to enter the password. If your repository is large this step can take a while. The purpose of the elaborate file name is so that at a glance you can tell what this file is. Also if you have multiple backups then ordering them alphabetically will put the backups for that archive in date order so you can find your most recent backup. Ending the file with .sql means you know it is a database backup.

	If you do not no your db_user db_name or password for the above step you can find it by typing:		If you do not no your db_user db_name or password for the above step you can find it by typing:
Line 65:		Line 65:
	tar czf <eprints_root>/backups/<archive_id>.archive.backup.-<year>-<month>-<day>.tgz <archive_id>		tar czf <eprints_root>/backups/<archive_id>.archive.backup.-<year>-<month>-<day>.tgz <archive_id>

	to create a zipped backup of your entire repository including static pages, documents, files and configuration. This can take a long time, for large repositories it can be ~~serveral~~ hours.		to create a zipped backup of your entire repository including static pages, documents, files and configuration. This can take a long time, for large repositories it can be several hours.

	===Backup your perl_lib===		===Backup your perl_lib===

	This step should not be necessary if you have followed the guide to [[Tips_to_write_plugins\|making safe plugins]]. If you ~~didnt~~ follow the guide and modified perl_lib (for shame) or you are particularly paranoid you may want to backup your perl_lib directory.		This step should not be necessary if you have followed the guide for [[Tips_to_write_plugins\|making safe plugins]]. If you didn't follow the guide and modified perl_lib (for shame) or you are particularly paranoid you may want to backup your perl_lib directory.

	cd <eprints_root>		cd <eprints_root>
Line 77:		Line 77:
	tar czf <eprints_root>/backups/<archive_id>.archive.backup.-<year>-<month>-<day>.tgz <archive_id>		tar czf <eprints_root>/backups/<archive_id>.archive.backup.-<year>-<month>-<day>.tgz <archive_id>

	You should now ~~be ready to~~ be ready to upgrade.		You should now be ready to upgrade.

	==Upgrading==		==Upgrading==

Kgoetz: adding categories upgrading and out of date

2018-08-30T06:03:03Z

adding categories upgrading and out of date

← Older revision		Revision as of 06:03, 30 August 2018
Line 82:		Line 82:

	Make sure you have re-read the list of things to know about upgrading your specific EPrints version up to the one you are moving to.		Make sure you have re-read the list of things to know about upgrading your specific EPrints version up to the one you are moving to.

			[[Category:Out of Date]]
			[[Category: Upgrading]]

Pm705: /* Backup your perl_lib */

2011-08-15T11:05:02Z

Backup your perl_lib

← Older revision		Revision as of 11:05, 15 August 2011
Line 69:		Line 69:
	===Backup your perl_lib===		===Backup your perl_lib===

	This step should not be necessary if you have followed the guide to [[making safe plugins]]. If you didnt follow the guide and modified perl_lib (for shame) or you are particularly paranoid you may want to backup your perl_lib directory.		This step should not be necessary if you have followed the guide to [[Tips_to_write_plugins\|making safe plugins]]. If you didnt follow the guide and modified perl_lib (for shame) or you are particularly paranoid you may want to backup your perl_lib directory.

	cd <eprints_root>		cd <eprints_root>

Pm705: /* Tell an adult */

2011-08-15T11:03:45Z

Tell an adult

← Older revision		Revision as of 11:03, 15 August 2011
Line 15:		Line 15:
	===Tell an adult===		===Tell an adult===

	Talk to your system administrator about getting a full system backup made. It is advisable to do this fairly regularly anyway incase of hardware failure or fire. See [[Backups:backing up]]		Talk to your system administrator about getting a full system backup made. It is advisable to do this fairly regularly anyway incase of hardware failure or fire. See [[Backups\|backing up]]

	You should also speak to who ever you need to get permission from to cause server down time. This is not always required as many upgrades can be done with very little down time but it is best to ask for permission and not use it than find you have to appologise for an unexpected service outage		You should also speak to who ever you need to get permission from to cause server down time. This is not always required as many upgrades can be done with very little down time but it is best to ask for permission and not use it than find you have to appologise for an unexpected service outage

Pm705: /* Tell an adult */

2011-08-15T11:03:19Z

Tell an adult

← Older revision		Revision as of 11:03, 15 August 2011
Line 15:		Line 15:
	===Tell an adult===		===Tell an adult===

	Talk to your system administrator about getting a full system backup made. It is advisable to do this fairly regularly anyway incase of hardware failure or fire. See [Backups:backing up]		Talk to your system administrator about getting a full system backup made. It is advisable to do this fairly regularly anyway incase of hardware failure or fire. See [[Backups:backing up]]

	You should also speak to who ever you need to get permission from to cause server down time. This is not always required as many upgrades can be done with very little down time but it is best to ask for permission and not use it than find you have to appologise for an unexpected service outage		You should also speak to who ever you need to get permission from to cause server down time. This is not always required as many upgrades can be done with very little down time but it is best to ask for permission and not use it than find you have to appologise for an unexpected service outage