Summary

You have completed the migration of all the Git Repositories to the Bitbucket mesh nodes and want to know if any local NFS data can be removed. On the surface, it might appear that once the repository data is migrated to the Mesh nodes, the NFS server could potentially be removed. The NFS server, or more specifically the shared file system continues to host non-Git data, including project and user avatars, attachments that may be associated with pull requests and inline in comments, plugins, Git Large File Storage (LFS) objects, and many other things. 

Environment

Bitbucket Data Center 8.x and Mesh 1.x, 2.x

Good to know

• Keeping the NFS repository data around means re-migration jobs would run a lot quicker.
• If you migrate a repository that has forks, note that all related repositories are migrated together.
• You can choose to create new repositories on Mesh automatically using the Create new repositories on Mesh toggle. When this toggle is off, repositories are still created in the shared home.

Pre-requisites

• You have migrated all or some of the projects or repositories from Bitbucket NFS shared to Remote Mesh 
• Confirm if the mesh nodes and the newly migrated repositories are working as expected

Pre-checks before you remove Repository data from NFS:

• Confirm that all the forks ( of any repository ) have also been migrated successfully to Mesh
• Confirm that the repository data has been backed up successfully on a different server.

Which data is migrated to mesh?

All the GIT data for the repository is migrated to the mesh nodes. 

What data will continue to remain on NFS?

All the non-git data will remain on the NFS server. This includes project and user avatars, attachments that may be associated with pull requests and inline in comments, plugins, Git Large File Storage (LFS) objects.

Pull request conflict notes will continue to be stored under the hierarchy folder. These notes are cached and should not be deleted. It is expected that we store the conflict notes on NFS even when moving to remote Mesh nodes. All the actual refs for the pull requests will be created on the mesh nodes. 

/var/atlassian/application-data/bitbucket/shared/data/hierarchies

Example from NFS shared home for pull request conflict notes. Although this folder is recreated even after deletion, it has been recommended by the Bitbucket engineering team to keep the conflict files on NFS and this is expected.

ubuntu@ip-10-229-139-171:~/bitbucket_home/shared/data/hierarchies/58/ead0edbf16f517c617/1/pull-requests/7$ ls -ltr
total 4
-rw-rw-r-- 1 ubuntu ubuntu 149 Feb  6 07:49 conflicts
ubuntu@ip-10-229-139-171:~/bitbucket_home/shared/data/hierarchies/58/ead0edbf16f517c617/1/pull-requests/7$ cat conflicts 
From: stash_crash
To: master
Conflict: (content) Merge conflict in src/page/[crashingPath]/testpage.jsx
	MODIFY|src/page/[crashingPath]/testpage.jsx

Steps to remove NFS Repository Data

We recommend that you test out these steps on a staging server before running the same on the production environment. Also, please plan a sanity testing of the Bitbucket application once the repositories have been removed

All repositories have been migrated to remote Mesh:

It is not possible to delete the repositories automatically. But we can confirm that it is OK to take a backup of the below folder which contains the repository data and then remove it from the NFS server. 

/var/atlassian/application-data/bitbucket/shared/data/repositories

One or some repositories have been migrated to remote Mesh:

In this case, please note the repository ID that you have migrated to mesh. Take a backup of the below folder which contains the repository data for this repository ID and then remove it from the NFS server. 

/var/atlassian/application-data/bitbucket/shared/data/repositories/{REPO_ID}

The above information should help you in clearing up some space on NFS. If you have any queries on the steps given please feel free open a support ticket with the Bitbucket Data Center team and we will be happy to help.