Hi Community!
Just to inform you if you are using the closed beta backup option to store confluence backup to an external aws s3 bucket of your company:
The attachments are not copied into the s3 bucket - only references are stored.
I tripped over this because the size shown in the atlassian confluence backend and the usage size of my s3 bucket differed huge - so about 4.9GB vs. 43MB.
As I opened up a ticket about this the support confirmed that checking the "include attachments" does not really store the attachment files into your bucket but only a reference to the attachment withing atlassian s3 storage.
This is a huge difference as I am not in control where and how the real attachment file is stored.
So to be precisly the info here:
https://support.atlassian.com/organization-administration/docs/what-data-is-backed-up-and-restored/
is wrong - because “attachments” are not backed up - only reference is stored - this is misleading as one would always think that attachments are within the bucket.
For an external backup and the option "include attachments" I would definitly think that most admins assume after backup all data is within my private external bucket.
If you are using this backup-feature - did you know and how do you think about it now?
Greetings from austria
-Wolfgang
Quoting atlassian support the behaviour is the expected one:
Our backup uses reference-based storage, which means that the actual files in S3 are not full copies of the attachments — instead, S3 stores lightweight pointers/references to the attachments. These references point back to the original media. This is why the physical size in S3 is significantly smaller than what is shown in the Atlassian Backup and Restore UI.
My follow up question in my ticket was if there is any changed planned for this in the future - there is a ticket to collect interests:
https://jira.atlassian.com/browse/CLOUD-12799
Greetings
Wow, that's not good. Does that mean if the attachment is deleted in the production environment it can't be restored?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
they say:
Also, if a referenced file is deleted after the backup, our internal systems will keep the file available for the 30-day backup retention period and for restore.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Oha i wasn't aware of that. Thank you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I agree with @marc -Collabello--Phase Locked- Is this expected behaviour or in fact a bug? Have you raised this to Atlassian?
Seems a bit risky to depend on a backup solution that does not actually back everything up 🤨
Thanks for sharing!
/Staffan
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It's an "entity coverage gap", not a bug...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.