When building Remora Backup, we set out to build a secure, simple, offsite backup service that would continue to run and serve customers for many years into the future.
We decided early on to not roll our own backup utility. We would use standard Postgres tools such as pg_backup, as well as simple, open source utilities such as scp for transferring files and gpg for encryption.
We also wanted to do the same for the key Heroku pieces. Building a complex process on top of Heroku would only have been a burden for our customers, as well as us. Below are some of the simple Heroku Constructs we’ve used to build Remora Backup, along with an explanation of why their choice was important.
A Helper App Defined by a Simple app.json File
The Helper App is a key building block in the Remora Backup architecture. What sets Remora apart from other backup options is that you own and control the backup app. This app is really a bare bones app capable of running a Heroku dyno. It’s defined using the app.json schema, and you can view the entire app’s definition here.
Because we used app.json as a building block, you are not required to create and configure a Helper App on your own. We provide a ‘Deploy to Heroku’ button that makes the process simple and correct each time.
API Access to the Helper App
With the Helper App created, and the Remora Backup add-on attached to the Helper App, we have all the access we need to run your backups, via the Heroku Platform API.
At the scheduled time, the Remora Backup app “reaches out” to your Helper App and starts the backup process, all via the Heroku Platform API. There’s nothing fancy happening here, and the API we use is the same API the Heroku CLI tool uses when you call heroku ps:run --detached command.
Using this method to run backups means Remora Backup has limited access to your environment, whether on the Common Runtime or inside a Private or Shield Space. In fact, our only access is to the Helper App, and that’s the way we want it. It’s secure and limited, only what is required, which is just as it should be.
Read-Only Access to Postgres via a Credential
Of course, to run backups against a Postgres database, we do need to be able to read the data, but that’s really it. We do not need or want write access.
Heroku has provided the Postgres Credentials system for just this type of scenario, and it’s really perfect for the backup process.
You define a credential that has read-only access to the database you need backups to run against, and then attach that credential to the Helper App.
When our backup process runs, we “see” only what we need via the credential, and have no access to change or otherwise tamper with your data.
Backups Run via Your Dyno
Because we have API access to the Helper App that you own, we are able to run the backup process via a dyno that you own and control. If you are using a Private or Shield Space, the backup runs entirely within your Space.
Put another way, your data will never leave your control until it is encrypted and being copied offsite to our secure storage provider (or the server you control if using our Bring Your Own plan).
One of the options we had when designing Remora Backup was to run the pg_dump backup process on a server or dyno we controlled, but we felt this would have been too insecure and introduced too much liability into the process.