DevOps
Create Automatic Firestore Backups with GitHub Actions
Backup your customers’ data automatically with GitHub Actions and Google Cloud Platform.
Have ever experienced one of the following situations? You just released your app, but somehow your users’ data started to disappear. Or, you deployed your app without writing any Firestore rules, and some malicious users got access to it and deleted every document.
Cloud Firestore by itself does not create any backups of your data for you to ask them to roll back the database. To prevent this from happening, first and foremost, you need to write strong security rules, making sure to only allow access to the data that users need. And second, you should create backups of your Cloud Firestore data.
In case you encounter any problems, there is a troubleshooting section at the end of this article.
Firestore is part of Google Cloud Platform (GCP for short). We will use GCP to make the backups (I will also teach you how to roll back the data), and GitHub actions to trigger the backup (in our case I want it to happen every two days).
First, you need a GitHub repo with your project — in case you are already using it, great! Otherwise, consider switching to GitHub, it has a ton of free features, but you can achieve this with other services using their pipelines, or tools like Jenkins. However, in this post, we will focus on the GitHub way.
You might have seen a .github folder in some projects, this is where our actions will live. Inside another folder called workflows, we will create a firestore.yml for our backups config. Create this structure in the root of your project: .github/workflows/firestore.yml
This is what the fields mean:
- name: The name of your GitHub action
- on: This is what triggers GitHub to do the backup
- workflow_dispatch: This is to create a button on the GitHub actions which will allow us to run the backup by clicking. In case you’re about to do something important and don’t want the data to be lost, note that you can altogether remove this block if you wish
- schedule: This is where we provide GitHub with a cronjob of how often theAction should trigger. In my case, every two days. Here is a tool if you want to set yours, replace the string in the cron value.
- jobs: This is what GitHub triggers when any on block meets the condition, there are two things you should change inside this, replace
yourappidandyourbucket. You can use the Firebase Storage bucket, or create a new one on GCP.
If you read the YAML file, there is a part where it says secrets.GCP_SA_KEY
This is the GCP ServiceAccount Key for your project. To get this key, go to this link.
Select your project and then click edit on the one named firebase-adminsdk.
Then click Create new key under the Add Key section, Select the JSON key type and click Create.
You will get a JSON file, but we need to convert this JSON into a Base64 string to use it inside GitHub, you can go to the command-line (If you are on windows use GitBash). Navigate to the directory where your JSON file is, and run openssl base64 -in yourfile.json -out output.txt, now you can run code output.txt to open the output file inside VSCode.
Go to your GitHub project > Settings, Secrets, New secret. The name is GCP_SA_KEY and paste the Base64 from your output file.
Your project is now ready for backups. Go to the Actions tab of your repo, select the name of your action and run it manually by tapping the button we created.
To see the output of our Action, click All Workflows at the tabs on the left, and you should see an item of our task running. To see the output of the console, click it and then select the bottom tab on the left.
Troubleshooting
There are two errors that I encountered.
Billing
You will get a PERMISSION_DENIED error if your Firebase project doesn’t have the Blaze plan. You’ll need to upgrade — it’s free anyway if your project is small.
Permissions
Your service account doesn’t have enough permissions.
Go to the IAM Admin and select the one named firebase-adminsdk . Click the pencil, then click Add Another Role and add the following permission:
If this doesn’t work, try with the permission of Owner under Project > Owner
If this still doesn’t work, you have to make sure that you used the correct project ids, and made all of the configs on the right project.
Now you should see a green checkmark on the left of the task.
To see your backups you can go to your firebase console and go to the storage tab.
Rolling Back your Data
To restore your backup, you will need the GCP Terminal
Select your project with gcloud config set project yourprojectid
Then run gcloud firestore import gs://yourprojectid/backupid/ replacing yourprojectid, and backupid with the name of the backup that you can see on the picture above in your Cloud Storage bucket.
You can also import specific collections, as explained in the documentation.
Conclusion
Now you have your data being backed up automatically to Cloud Storage. If you ever need it, you can roll it back. Please make sure you write strong security rules for your Firestore and storage. It will be useful if you save the backups into a folder and add a security rule setting write to false for the backups folder.
Thanks for reading, I hope you found this information useful, Good-Bye 👌😎
