mattock / automatic-cloud-backup Goto Github PK

@mattock Does it work when you try to backup with attachments? I'm getting backup zips where the exportDescriptor.properties file indicates that backupAttachments=false. I'm wondering if something changed with the interface?

They are getting rid of cookie based authentication and replacing it with token based authentication.

https://developer.atlassian.com/cloud/jira/platform/deprecation-notice-basic-auth-and-cookie-based-auth/

I haven't looked into it much, but it might not be too bad.

I am able to download .zip files for both JIRA and Confluence, but when I attempt to unzip them, it just goes into a .cpgz->.zip infinite loop as described here: http://osxdaily.com/2013/02/13/open-zip-cpgz-file/

Further, when I attempt to upload that .zip file to restore my data to a new JIRA cloud instance, I receive this error: http://imgur.com/7jdwg0Z

It appears that this backup strategy may be broken.

backup.sh fails to generate any backup and I receive no error messages. I drilled it down to this line:

BKPMSG=$(curl -s --cookie $COOKIE_FILE_LOCATION --header "X-Atlassian-Token: no-check" -H "X-Requested-With: XMLHttpRequest" -H "Content-Type: application/json" -X POST $RUNBACKUP_URL -d "{\"cbAttachments\":\"${ATTACHMENTS}\" }" )

The curl command seems to fail due to the fact that RUNBACKUP_URL points to a nonexistent URL. I get a "Oops, you've found a dead link" response from the server. Has the format of the URL changed recently? The script was working before, several months ago.

Thanks!

If all the ENV VARS are set, use them. If not, try and read the config file.

Hi, thanks for this awesome script with the new endpoints much appreciated! The Confluence backup works great but when I try to run the Jira backup with --source jira, I get this curl error thrown:

parse error: Invalid numeric literal at line 1, column 10
curl: option -: is unknown
curl: try 'curl --help' or 'curl --manual' for more information

I've checked all your curl statements and they seem fine to me. Can you please check if you get the same issue as me with the new changes in pull 14?

Thanks!

{
    "status": "Success",
    "progress": 100,
    "description": "Compressing data & attachments",
    "result": "{\"mediaFileId\":null}",
    "startTime": 1513004884339
}

So, the actual backup file can never be found.

Currently the cookie has 0644 permissions, which means that it could potentially be taken and used by local users other than the one who created it. The script should chmod the cookie file to 0600 to limit its exposure.