A backup system is only as valuable as the confidence it provides. Before we take Litestream into production, we need to verify that everything is working correctly in our development environment. This ensures that we not only understand how Litestream operates but also confirm that our setup is correct and reliable.

To test Litestream, I have configured our application to connect to a local instance of MinIO, which is an S3-compatible storage system that you can run on your laptop. This allows us to simulate how our production backups will work in a controlled environment.

Setting Up MinIO for Local Backup Testing

Jumping back into our application, I’ve already set up and launched MinIO. Now, if we check our localhost instance, we’ll see that no buckets exist yet.

Let’s create a new bucket called lorem-news.

Now, we need to configure Litestream to backup our development database to this bucket.

To do this, we update the Litestream YAML file:

1. Include our development database in the configuration.
2. Specify the local MinIO instance as the endpoint (since we’re running it locally on port 9000).

Configuring Litestream Credentials

Since we’re using Rails credentials to store our S3 bucket details securely, let’s check that everything is set up correctly.

Running:

bin/rails credentials:show

Reveals that under the Litestream namespace, I have added:

• replica_bucket: lorem-news (which matches our MinIO bucket name).
• key_id and access_key (set to minioadmin for local testing).

For production, you will need to generate and use your actual S3 credentials—and keep the private key secure.

Ensuring Litestream Reads the Credentials

To confirm that Litestream is reading the credentials correctly, we run:

bin/rails litestream env

This command prints out the environment variables as Litestream sees them. The values match our configuration file, confirming that everything is set up properly.

Starting the Backup Process with Puma

Instead of manually starting Litestream, we want it to run automatically whenever our application starts.

To achieve this, we use Puma’s plugin system. Similar to how Solid Queue runs background jobs, we can configure Puma to automatically start Litestream when our Rails app launches.

We simply add the Litestream plugin to Puma’s configuration:

plugin :litestream

Now, whenever Rails starts, Puma will:

• Start Litestream alongside the app.
• Manage its lifecycle (stopping it when the app stops).

Let’s test it by running:

bin/dev

If everything is working, we should see Litestream logs confirming that it is replicating our database.

Verifying the Backup Process

Checking the Litestream logs, we see:

• A snapshot being written.
• WAL (Write-Ahead Log) segments being stored.

Now, let’s verify this in MinIO.

Navigating to the storage directory, we find:

• A Litestream generations directory.
• A snapshot file and WAL files, which are used to reconstruct the database at any point in time.

Litestream mirrors the file path structure from our local database, making it easy to identify where each backup corresponds to our production setup.

Conclusion: Litestream is Working!

• Our development database is replicating correctly.
• The backup files are stored securely in MinIO.
• Litestream is running automatically with Puma.

Since this works locally, we can confidently expect it to function the same way when we deploy to DigitalOcean Spaces or S3 in production.

However, we don’t just want to assume it works—we need to continuously verify our backups. In the next video, we’ll explore the tools Litestream provides to ensure our backup system is always running smoothly and securely.