RESTORE with confusion or chaos :-)

[Deleted user]

Yes, I can see we can use the zip file from JIRA 1 , restore it onto JIRA 2, however, the whole system information completely changed by JIRA 1 import (zip) , then do we need to adjust anything on JIRA 2, where database,url, users completely different from JIRA 1 ?

Yes, Project level, we can see , but system level, it's a mess :-) how can I operate on JIRA 2 with JIRA 1 settings after restoring , especially between two different platforms. 

[Nic Brough -Adaptavist-]

This appears to be totally out of context.  Could you explain the goal?

[Deleted user]

I found from my jira 1 configuration shown in jira 2 because I used zip from jira 1, that's not good as all the settings different between these two instances, how can I use jira1 settings for jira2

my goal, to transfer projects (in a zip) from jira1 to jira2, but jira 2 still running its own configuration, is it possible ?

also, jira 1 configured to db 1,  which shown on jira 2 of course during 'restore',  I wonder how that can be handled in database level even the zip file successfully used from jira 1.

[Deleted user]

I wonder whether there must be some certain step(s) after restore action. 

such as Edit configuration, like basic url update ? what about db then

[Andy Heinzer]

Hi @[deleted],

I think the problem here is a misunderstanding of the function of the system restore in Jira.  This action is intended to do a complete restoration of the data in your xml backup to your database.  This has the effect of overwriting just about all data that might have existed prior to this restore in the database, but that is the expected behavior here.

Instead, what I think you are looking for here is the Restoring a project from a backup guide.  This explains how you can import a project from an XML backup into a new Jira instance.  I could understand the confusion here, both the system restore and the project restore use the same XML  backup as a source of data, but these processes are very different.

In order to restore a single project, there is potentially a lot of configuration that has to happen in the destination instance before that import can happen.  The project restore guide even notes how complex this process is:

Restoring a project from a backup is not a trivial task. You may be required to change the configuration of your target JIRA instance to accommodate the project import. Additionally, the Project Import data mapping can be resource intensive on your hardware and may take a long time to complete, if you are importing a large project. Note, the Project Import tool will lock out your instance of JIRA during the actual data import (not during the validations), so please ensure that your instance does not need to be accessible during this time.

Because this is a really complex process, there are 3rd party solutions for Jira to help make this easier.  The two best known plugins to help with project restore are:

• Project Configurator for Jira
• Configuration Manager for Jira

I hope this helps to clarify things a bit.

Regards,

Andy

[Deleted user]

Thank you for the reply @Andy Heinzer  or Andy. 

You mentioned "expected behavior", that was I have been looking for, but not got yet. 

Regarding 'project backup and restore', I can try later, but that's not what I was planning to do, not yet :-)

Whole system, from jira 1 to jira 2,  as you confirmed, I should be able to see "expected behavior" - but for config in System details, what should I see since a complete restoration of the data on jira 2 from jira 1 , my jira 2 site now operating on which database config? 

[Andy Heinzer]

The configuration of the database is not changed by a system restore.  That is still governed by the $JIRAHOME/dbconfig.xml 

The XML backup does not actually know what values are listed in the dbconfig.xml itself, nor does restoring that backup change the dbconfig and anyway.   The system store only changes what data exists in the database itself.

Also a system restore only contains the information in your Jira database.  It does not contain the "whole system" as you put it.  There is other information that is stored outside the database, such at the avatars and attachments in the $JIRAHOME/data/ subfolder.

[Deleted user]

Thank you so much !  A few of further clarification, please @Andy Heinzer:

url in system after 'restore' NOT remains as it supposed to be , e.g. I restore a zip from quan1:8300 (jira 1) to quan2:8100 (jira 2),  I will see quan1:8300 in system info on quan2:8100, ? 

'only contains the information in your jira database' ,  do I need to care about anything related to database after a successful 'restore' , e.g. if jira1 based on mysql, jira2 based on SQL server;  or jira 1 based on SQL 2012, jira2 based on SQL 2014, ?   our DBA will maintain the database so I wonder what would be my duty to tell him/her about what I have done and what 'trouble' I could make :-) , ?

where can I get the whole list for 'there is other information that is stored outside the dtabase....'  as you addressed , please ? 

[Nic Brough -Adaptavist-]

A full restore restores everything that is in the database the xml was taken from, destroying what was in the target database before.

This data includes the base url (which you can easily change later).  If you've used urls in comments and text, they will be restored exactly as they were in the source Jira you took the backup from.

The exact database generally is not important - one of the things the XML export and full restore is for is changing from one database to another (e.g. MS-SQL to PostGres).  The XML is independent of the database, it's intended to be created and read by Jira.  It's a layer of abstraction.

Other information stored outside the database can be broken up into types:

• Attachments, including avatar pictures.  These are stored on the file system under <jira home>/attachments
• Logs - you might not want to keep these
• The index
• Working directories
• The configuration of the services (so the start up files and scripts, how much memory to allocate, where it lives in the directory tree, config for remote directories etc, etc, etc)
• Add-ons

The minimum requirement for restoring a Jira system is a copy of the database data and the attachments.  Everything else you can recreate with a clean installation, even if it's a clean install on a different operating system and database!