Foremanctl backup/restore proposed plan

Development
,
1

foremanctl backup/restore

Hello community,

Lately I’ve been working out some of the specifics about how foreman-maintain commands should look in foremanctl. My first post around this is here: (3) Foreman-maintain functionality report for foremanctl port - Development - TheForeman.

In this post I’d like to update you all on backup and restore, which could be considered one of the most complicated pieces of foreman-maintain. @sajha has just begun implementing offline backup of databases only in foremanctl following this plan.

General approach

foremanctl backup/restore are new commands that closely follow foreman-maintain backup/restore. foreman-maintain’s general backup/restore functionality is proposed to be ported to foremanctl.

Implementation steps

  1. Offline database backup
  2. Offline config file backup
  3. Offline Pulp backup (optional)
  4. Restore, which is agnostic to the backup style
  5. Online backup
  6. Incremental backup
    • I propose to use tar --listed-incremental from the start to reduce effort here
  7. Backup/restore of smart proxies
    • Container gateway DB backup will be a major part of this

And, along the way, documentation is updated/created as needed.

High-Level Design

  • Follow the same logical steps as foreman-maintain to orchestrate backup/restore.
  • Use existing Ansible functionality and architecture to avoid rewriting the low-level functionality, like grabbing postgres dumps and copying files around.
  • Rely on foremanctl deploy as much as possible to restore the machine.
  • Regenerate podman secrets from foremanctl context, like parameters.yaml.
  • Data backed up is conditional based on what features or flavors are in use.
  • Use metadata.yml like before to save information about the backup
    • Can include details like hostname, foremanctl version, backup type, enabled features, container image inventory
  • backup and restore are playbooks exposed as CLI options via obsah
  • Preflight checks for operations that will error out if issues are detected

I wanted to keep this design as unsurprising as possible by keeping concepts from foreman-maintain and by following design principals already in foremanctl today.

I have more public design specifics on Jira, which I’m happy to discuss here.

1 Like
2

Do we not want to backup podman secrets and use for restoring?

3

I don’t think the secrets themselves need backing up since they are generated by foremanctl, which gets the config from its own internal yaml files.