I need to take db back up of two projects.

[l]

I have around 900 projects in jira.So took the xml back up and uploaded in a test jira instance.So is it possible to delete all the issues from the db of this test jira and take back up of the reamaing two.I can use delete/update command in db to delete the unwanted issues of projects in test jira db.Please help

[Rene Verschoor [Atlassian]]

You could script the deletion of the unwanted projects.
There is a deleteProject SOAP call you can use for this.
AFAIK there's no corresponding REST call.

[Norman Abramovitz]

Good catch, I forgot about the SOAP interface. There is one flaw though, it is deprecated, so it will disappear as noted by the url below, you must be ready to rewrite your script in the future.

https://developer.atlassian.com/display/JIRADEV/SOAP+and+XML-RPC+API+Deprecated+in+JIRA+6.0

Nic's answer is the safer approach of using the UI. Maybe using a web page testing tool could be used to script things up.

[Nic Brough [Adaptavist]]

Deleting issues from a Jira database is complex and painful, you have to hit a dozen tables and use all sorts of foreign keys and lookups. You need to go for jiraissue, jiraaction, nodeassociation, customfieldvalue, worklogs, changeitem and changegroup at the very least, and I know I've not listed them all here.

I'd do this by deleting the projects you don't want in the UI. Or think about getting the basic config right in an empty Jira and then just import the projects you need.

[l]

Its too pain ful as our instance consists 950 projects.

[Nic Brough [Adaptavist]]

I'm afraid you don't have any options. You either need to backup and remove the stuff you don't want, or spend a long time understanding the exact structure of the data.

[Norman Abramovitz]

Would it be easier to remove all the issues from the another copy of the xml backup file to create the database project structure and then import the projects you want from the original xml file?

[Nic Brough [Adaptavist]]

Removing them from the xml is easier than using SQL, but you still need to get it right - that's why I tend to prefer telling people to import everything into a dev system and then scrub what's unneeded.