After evaluating Confluence as a potential primary repository for my project documentation, I've decided not to use it.
The reason isn't the editing experience. In fact, I consider the organization through hierarchical pages, the support for diagrams, and the integration between documents to be well-designed. The problem arises when I analyze the risk of data loss.
In recent years, I've already experienced the complete disappearance of three personal projects stored on different services. This experience has made trust in a platform an essential requirement. If a system doesn't allow me to easily demonstrate that I can recover my data, I can't consider it a valid solution for storing years of work.
During the evaluation, I performed several tests:
creating a completely new workspace;
creating a page hierarchy;
adding diagrams;
exporting the workspace;
deleting the workspace;
attempting to restore using Confluence's own import mechanism.
The result was always the same: the import process failed with the error "Failed to start a long running task," even when replicating the scenario from scratch.
Regardless of whether it's a specific bug or a borderline case, the practical consequence is the same: I can't verify that an exported copy can be successfully restored.
For long-term technical documentation, this poses an unacceptable risk.
Furthermore, exporting has limitations on certain types of content (such as whiteboards, databases, or slides), and the backup and import mechanisms are complex and unintuitive for a scenario as basic as "making a copy and restoring it."
I don't question that Confluence is a useful tool for many companies. Its collaborative capabilities, permissions, Jira integration, and simultaneous editing are valuable in corporate environments.
However, my priorities are different. I need a tool whose data recovery is simple, verifiable, and robust enough to rely on for many years.
Until I can practically demonstrate that a backup can be fully restored without surprises, I will not use Confluence as my primary repository for personal documentation.
No administrator needs to try to reproduce the problem. I've spent several hours isolating and reproducing it from scratch in a completely new environment, always getting the same result. For me, the inability to verify a reliable restore is enough to rule out Confluence as a documentation solution. I consider the matter closed.
As a result of this experience, I will not recommend Confluence for projects I participate in or advise on, unless a reliable backup and restore process can be verified beforehand. For me, the ability to recover years of documentation is a non-negotiable requirement, and the tool failed to meet this requirement during my evaluation.
I've also attached the exported HTML package of one of the test spaces. It is a minimal, reproducible example that can be used to verify the issue.
https://drive.google.com/file/d/1D5GS5OL5bXU9Bx7sK18LywYIgv_Vi9rB/view?usp=sharing
The fact that such a fundamental flaw still exists in a mature product in 2026 says enough. If I can find this in two days, I have no reason to believe this is the only critical issue waiting to be discovered. A backup that cannot be trusted is not a backup. I'm out.
I also tested the import process with a completely new, default space created from scratch, without adding any custom content.
I exported the space immediately after creation and attempted to import it back.
The result was exactly the same: "Failed to start a long running task."
At this point, the issue is no longer related to my documentation or any specific content. I can reproduce the same failure even with a default space created by Confluence itself.
From my perspective, I cannot verify that any exported space, including a default one, can be successfully restored using the current import process.
