Bitbucket DR clarifications

[Noel Walsh]

- Are home directory snapshots triggered solely via the bitbucket diy backup script, and is this script also intended to trigger replication to the failover site?

- If using LVM/XFS or ZFS, is the replication to the failover site done at the file system level and not at the storage level.  If this is the case, is the assumption that no storage replication should be performed correct?

- As the database is replicated via the database engine, again, is the assumption is that no storage level replication should be performed correct?

- Are the bitbucket diy backup script commands capable of recycling old snapshots, or is this done at the file/storage system level?

[Abyyba]

Hello @Noel Walsh ,

I'm reviewing older unanswered questions in the community.

Since Atlassian products evolve quickly, especially over the past few years, some of the concepts you mentioned could be outdated, changed or even no longer needed. If you could clarify this question, I (or another community member) might be able to provide a solution or at least mark this question as resolved in order to keep the community as organized as possible.

• Are all the questions still valid or just some of them?
• How would you say this question stands?

Despite everything, I have investigated and explored some information that may be helpful, otherwise I invite you and the community to participate on this question, together we will surely find a solution creating a place of unique value ;)

1. Home Directory Snapshots and Replication Trigger:

Yes, the home directory snapshots are primarily triggered by the Bitbucket DIY backup script. While this script handles the snapshot creation, the actual replication to the failover site is typically orchestrated separately, either through additional scripts or tools that work in conjunction with the backup process.

2. File System vs. Storage Level Replication (LVM/XFS or ZFS):

You're correct. When using file systems like LVM/XFS or ZFS, replication to the failover site is indeed done at the file system level. This is because these file systems offer built-in snapshotting and replication capabilities. The assumption that no storage-level replication is needed in this scenario is generally accurate, as the file system handles the data consistency during replication.

These file systems offer built-in snapshotting and replication capabilities that facilitate this process. The assumption that no storage-level replication is needed is generally correct. Since these file systems handle data consistency during replication, there's no need to duplicate this effort at the storage level.

However, it's always recommended to verify the specific documentation of your file system and your configuration to confirm the implementation details.

• Asynchronous replication: File system-level replication is usually asynchronous, meaning there might be a slight delay between data being written on the primary site and replicated to the secondary site.
• Performance: File system-level replication can impact system performance, especially in environments with large data volumes or high write rates.
• Granular recovery: If you need to recover individual files rather than the entire file system, you might need to consider additional backup solutions.

3. Database Replication and Storage-Level Considerations:

Yes, since the database is replicated using its own engine (e.g., PostgreSQL or MySQL replication), there's typically no need for additional storage-level replication for the database data. The database engine ensures data consistency between the primary and failover sites.

Advantages of native database replication:

• Data consistency: Database engines ensure data is replicated consistently and orderly, maintaining the integrity of the database on the backup site.
  Ease of use: Native replication is usually easier to set up and manage than storage-level replication.
• Efficiency: Native replication often consumes fewer resources and can be faster than storage-level replication.

When to consider storage-level replication:

• Granular recovery: If you need to recover individual files or specific parts of the database rather than the entire database, storage-level replication might be more flexible.
• Backup performance: In very large database environments or with high change rates, storage-level replication might offer better backup performance.
• Additional protection: Some organizations use storage-level replication as an additional layer of protection along with native database replication for added security.

In most cases, native database replication such as PostgreSQL or MySQL is sufficient to ensure data consistency and availability in a disaster recovery (DR) environment. However, depending on the specific requirements of your system, storage-level replication might be an option to consider for greater flexibility and protection.

4. Recycling Old Snapshots:

The Bitbucket DIY backup script itself might not have explicit commands for recycling old snapshots. However, it can be integrated with the snapshot management features of your file system (LVM/XFS or ZFS). These file systems provide tools to automatically manage snapshot lifecycles, including the deletion of old snapshots based on retention policies you define.

• The Bitbucket DIY backup script does not include snapshot recycling features: The script focuses mainly on creating backups, not managing the snapshot lifecycle.
• Integration with file systems: LVM, XFS, and ZFS have native tools to manage snapshots, including their automatic deletion based on retention policies.
• Automation: It's possible to configure these file systems to automatically delete old snapshots, which facilitates storage space management.

----

Of course, correct me if I'm wrong about anything, I invite you again and the community to participate and contribute knowledge. Feel free to ask whenever you need.

Regards,
Sergio G.