Stash Replication for DR

[Shrutika sutar]

Hello,

We are looking into HADR solution for Stash, I have alreday looked into the HA document provided by Atlassian. But as far as integrity and security/corruption of device is concernced we dont to go with the block level replication. I had a couple of questions:

1.) Can we do a git pull to replicate the repo information to the other end? And should the pull be in sync with the database and Why?

2.) With the pull approach what other information from the home directory will be out of sync? And how would that affect the working of Stash.

2.) Why does the document mention the database and the home directory should be in sync? What are the components that are affected?

3.) If we use file level sync what are the concerns and the components that are affected?

I would love any recommendations on the replication other then block level, not required to be synchronous.

Also can i get a direct contact with a technical person for questions related to this topic?

Thank You.

[Jens Schumacher [Atlassian]]

Could you explain why the appoach outlined in the Stash documentation is not sufficent for your needs?

The database stores, among others, information about pull requests and commits. Therefore it is important that the database keeps in sync with the home directory to ensure that the commits that are referenced in the database actually do exist in the repository and vice versa.

You can replicate the git information seperately, but that might leave Stash in an unsupported state when you restore the data.

[Shrutika sutar]

Due to the disk corrpution concerns of block level replication we are looking at a diferent approach for home directory replication. The Stash document recommends a block level replication which we are concerned to use and looking at file level or other git level.

So my question is with git pull on our remote side will the information between the db and the home directory fall out of sync? What other information from the home directory except the repositories would make them out of sync and make stash unstable?

[Mark Lang]

I agree with Shrutika about the HA Stash documentation not being sufficent to meet our needs. We have users that live in various countries and rely on the smallest amount of downtime possible. Regular backup downtimes even if it means 5-10 mins (I know this can be reduced with the DIY type of backups) are not going to be accepted. Are there any tools for syncronization that do not require a downtime? Or are we expected to purchase enough hardware to have mirroring on the storage and built in database replication?

[Shrutika sutar]

On that note, i was testing rsync for the home directory replication and separate sync for database and that caused many errors. ANY other work around or option? How would a stash plugin for mirroring the transactions work? The same way as the hook does, is it possible to have the whole stash events respond to events and add to mirror?

[Mark Lang]

So far I've read through - https://confluence.atlassian.com/display/STASH/Data+recovery+and+backups?utm_source=SAC&utm_medium=provide_details

https://confluence.atlassian.com/display/STASH/Using+the+Stash+Backup+Client

https://confluence.atlassian.com/display/STASH/High+availability+for+Stash

So I'm not surprised that rsync caused problems. All the backup strategies include downtimes to copy both the database and the file system repos while locking the users out of the application. I am not sure it would work but the thought process I had was some means of mirroring the data using RAID disks and a failover database and then backups could be taken hot from the mirrored versions as long as it happened at the same time. But even then, I'm not sure it would be enough (or if the reasoning is sound).

[Dave Marsico]

So far I've read through - https://confluence.atlassian.com/display/STASH/Data+recovery+and+backups?utm_source=SAC&utm_medium=provide_details

https://confluence.atlassian.com/display/STASH/Using+the+Stash+Backup+Client

https://confluence.atlassian.com/display/STASH/High+availability+for+Stash

So I'm not surprised that rsync caused problems. All the backup strategies include downtimes to copy both the database and the file system repos while locking the users out of the application. I am not sure it would work but the thought process I had was some means of mirroring the data using RAID disks and a failover database and then backups could be taken hot from the mirrored versions as long as it happened at the same time. But even then, I'm not sure it would be enough (or if the reasoning is sound).