Infrastructure as Code (IaC) and GitOps workflows have transformed delivery pipelines into a single source of truth. Tests, security scans, and policy checks are now standard requirements enforced at merge time.
But backups? They usually remain completely out of band. They are usually scheduled on a separate platform, triggered manually by a different team, verified in a separate UI that is totally disconnected from the repository. And critically, they run on a schedule that has no relationship to when your repository actually changes.
This post walks through a practical way to bring GitHub repository backups into the delivery pipeline using GitHub Actions and Rubrik, turning data protection into a code-enforced behavior rather than an afterthought.
Prefer to watch? Here’s a full video walkthrough of the action…in action!
The Problem: Backups Live Outside the Workflow
If you are running code out of GitHub, you likely already enforce formatting and linting, unit and integration tests, security scanning (SAST/DAST), and policy-as-code checks (OPA, Sentinel) as part of your pipeline.
But your repository backups? Those still rely on time-based schedules or post-incident validation ("We think it was backed up"). The delivery pipeline is highly automated and predictable, but the protection of the code flowing through it often remains disconnected.
This gap is particularly risky for repositories that represent critical business logic, configuration, or infrastructure definitions. A corrupted or deleted repository without a recent backup is a recovery nightmare, and a daily 2:00 AM schedule does nothing for the merge that happened at 3:00 PM.
What "Backup as Code" Actually Means
Backup as code doesn't necessarily mean writing your backup logic in Terraform. It means:
Event-Driven: Backups are triggered by specific pipeline events (e.g., a PR merge).
Verifiable: Backup success or failure is machine-verifiable within the pipeline.
Enforced: Governance happens where merges are decided.
In other words: If a failed test can block a merge, a failed backup should too.
The Solution: A GitHub Action for Rubrik
To bridge this gap, I built a GitHub Action that communicates directly with Rubrik Security Cloud (RSC) to protect your GitHub repositories. The action performs three functions:
Triggers an on-demand Rubrik snapshot of the GitHub repository associated with the workflow.
Polls Rubrik's API to monitor the backup job progress.
Fails the workflow if the backup fails or times out, preventing the pipeline from proceeding.
Rubrik already supports GitHub as a protected workload. This action simply lets you trigger and enforce that protection from within your pipeline rather than relying solely on scheduled policies and supports two common backup patterns:
Non-Blocking on PRs: The action kicks off the backup process within Rubrik Security Cloud asynchronous, allowing the code tomerge into the main branch quickly, with no reliance on the backup.
Always Blocking: For high-risk or regulated repositories, you may want to require a successful backup before the merge takes place, aiming to ensure you have a known good state available for recovery.
Below, we’ll walk through how this all works as is. The example action is in a public repo so feel free to fork and modify to your business needs.
Example Workflow
Here is a minimal workflow that enforces a Rubrik backup upon merging to the main branch. Simply add your action.yml file to .github/workflows, create your repo secrets, and begin leveraging backup as code.
First let’s look at the entire syntax:
name: Rubrik On-Demand Backup
on:
push:
branches:
- main
jobs:
backup:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Rubrik On-Demand Backup
uses: mwpreston/rubrik-on-demand-backup-action@v1
with:
rsc-uri: ${{ secrets.RUBRIK_RSC_URI }}
client-id: ${{ secrets.RUBRIK_CLIENT_ID }}
client-secret: ${{ secrets.RUBRIK_CLIENT_SECRET }}
repository: ${{ github.repository }}
sla-name: "Gold"
wait: "true"
What Happens Under the Hood?
First, we specify the action to kick off on any push to the main branch. This includes direct pushes with git push, and during the merges upon approval of pull requests.
From there, we are going to check out the latest code for the action; the python syntax that will actually perform the backup.
And finally, we pass it some variables:
rsc-uri: This will be the url to your RSC instance, stored within a GitHub secret (ie: https://mycompany.my.rubrik.com)
client-id: This is the client ID from your service account, stored within a GitHub secret.
client-secret: This is the client secret from your service account, stored within a GitHub secret.
repository: This holds the repository name to backup. In this case, we are using the built in github.repository variable to retrieve the current repo.
sla-name: The name of the SLA to apply to the backup within Rubrik Security Cloud.
wait: This is a boolean that determines whether the action waits for a backup completion before completing the merge. If true, the action will wait. If false, the backup job will be executed but not monitored, while the merge continues.
Once the yml file is present within GitHub, the action will proceed to kick off during each push to the main branch. You can view the action code here, and again, feel free to fork and modify to fit your needs. At its core, it resolves the repository and SLA names to internal RSC IDs, and then calls the GraphQL mutation to take an on-demand snapshot of the repository.
Closing Thoughts
This strategy isn't about replacing your centralized backup policies. It's about aligning data protection with modern development workflows. If we believe that tests and policy checks belong in the pipeline, then backups, the ultimate safety net, belong there as well!
The action is open source: fork it, modify it, tailor it to your needs. And if you want to see the full Rubrik GitHub protection solution beyond just this action, check out our self-guided Explore lab where you can walk through it yourself.