gem

Scheduling

Solid Queue

The default in Rails 8, and the one bb install wires up for you.

# config/recurring.yml
production:
  boring_backup:
    class: BoringBackup::BackupJob
    schedule: every day at 3am

The job runs on the :default queue. Keeping the entry under production: means development and staging never dump anything.

sidekiq-cron

# config/schedule.yml
boring_backup:
  cron: "0 3 * * *"
  class: BoringBackup::BackupJob

bb doctor recognises this file too, so the scheduler check passes once the entry names BoringBackup::BackupJob.

Any other ActiveJob backend

BoringBackup::BackupJob is a plain ActiveJob::Base subclass, so GoodJob, Delayed Job, Que and friends can all enqueue it. Write your own job when you want a different queue, priority or error handling:

class NightlyBackupJob < ApplicationJob
  queue_as :maintenance

  def perform
    result = BoringBackup::Commands::Backup.execute

    raise BoringBackup::BackupFailedError, result unless result.success?
  end
end

Raising on failure is what makes the run visible. A job that swallows the result reports success to your queue dashboard while the backup is missing.

Plain cron

No Rails and no scheduler needed. The command exits non-zero on failure, so cron mail carries the bad news.

0 3 * * *  cd /srv/app && bundle exec bb backup >> log/backup.log 2>&1

Cron runs with a minimal environment. If pg_dump or the AWS credentials come from a shell profile, they will be missing here. Run bb doctor through the same cron entry once to confirm.

Picking a time

Backups are read-heavy, so put them where the database is quiet. Whatever you pick, tell sentinel the same schedule when you create the monitor, in the same timezone. A monitor that expects 03:00 UTC while the job runs at 03:00 local goes overdue every day it is late by an hour.

Set the grace period from how long a backup actually takes, plus room for a slow night. Too tight and a big Sunday dump pages you for nothing.