Upcoming changes to attachment data storage in Confluence

Hello everyone,

We’ve heard the feedback and we’re excited to announce that with Confluence 8.0, our team will begin building out support for object storage for attachment data. This will be an ongoing piece of work, but we’re keen to get started.

With this work we will be making it possible to optionally store your attachment data in object storage, other than a filesystem. The nature of this type of data is better served by these storage types, with the intention being an improvement in Confluence’s operational experience when managing this data.

For the latest details on this, please keep an eye on the page Preparing for Confluence 8.0.

Thanks,
Dylan
Engineer, Confluence DC.

6 Likes

I inherited a legacy system with several terabytes of attachments. As near as I can determine, somewhere between 20 and 30 percent of the files are no longer accessible through the Confluence API. Will your new design have a method to find and purge these things in Object Storage? Because it’s already nearly impossible to do it in file storage.

Hi @RobertEgan ,
Thanks for the comment. To your question, in a roundabout way, the answer is yes.

This new feature intends to also provide a means of syncing existing attachment data from the file system to the nominated object storage medium. As such, data to be synced will need to be physically available on the FS and also registered in the database. In that sense, once the sync is complete the object storage will only have been hydrated with data that was/is accessible.

As long as you’re okay with moving to object storage this could be a clean way of purging inaccessible data for you.

Thanks.

So, if I understand correctly, once the hydration is complete, the contents of the FS may be deleted?

Not for this initial release. Only attachment data will be managed on object storage. Confluence config data will still reside on the FS and so it will need to stick around.