jakman85andClaude Opus 4.8
6739339f53
MinIO's open-source edition is de-prioritised (console removed, commercial
pivot), so swap the off-cluster S3 backup target on the Proxmox host to
versitygw v1.7.0 (github.com/versity/versitygw) — a maintained Go S3 gateway
serving a POSIX filesystem as S3.
Rename role minio_backup_target -> s3_backup_target and playbook backup-minio
-> backup-s3. The role now:
- decommissions any pre-existing MinIO (service/binary/env/mc-client/user/
object-layout), KEEPING the ZFS dataset Storage/k3s-backups and its mount
- installs the pinned, checksummed versitygw binary (fetched+extracted on the
controller, host has no internet), a dedicated versitygw system user, and a
Type=simple hardened systemd unit running the posix backend rooted at
/mnt/Storage/k3s-backups/data, bound to 192.168.1.9:9000 (same endpoint),
plain HTTP / path-style
- ensures the dataset has xattr=sa (versitygw stores object metadata in xattrs)
- pre-creates the velero + cnpg buckets (bucket == top-level subdir)
Credentials are REUSED: versitygw's ROOT key is set to the same scoped
access_key/secret the cluster already uses, so endpoint + key + secret + bucket
names are byte-identical to the old MinIO target. The GitOps SOPS secret
(platform/backup/minio-credentials.sops.yaml) and all cluster-side Velero/CNPG
config need ZERO change. The vaulted group_vars now expose
s3_backup_target_access_key/_secret_key (same values, MinIO root creds retired).
Verified live on the Proxmox host: versitygw active+enabled on 192.168.1.9:9000,
MinIO fully removed, dataset intact; SigV4 ListBuckets with the reused key
returns velero+cnpg; a throwaway in-cluster pod reaches http://192.168.1.9:9000
(versitygw S3 response). Re-run is idempotent (no host changes).
Co-Authored-By: Claude Opus 4.8 <[email protected]>
24 lines
1.3 KiB
YAML
24 lines
1.3 KiB
YAML
---
|
|
# Stand up the off-cluster S3 backup target on the Proxmox host — the store Velero (R-STATE-03)
|
|
# and CloudNativePG (R-IDP-05) back up into. Implemented with versitygw (Versity Gateway), which
|
|
# REPLACES the earlier MinIO target; the role also decommissions any pre-existing MinIO install so
|
|
# a re-run is a clean swap. Host infra, surgical + idempotent: the ONE ZFS dataset it owns
|
|
# (Storage/k3s-backups), the versitygw user/service/binary, and the velero + cnpg buckets. It never
|
|
# touches other datasets, sharenfs, pvesm storage, VMs or firewall.
|
|
#
|
|
# Credentials come from Ansible vault (inventory/group_vars/proxmox_hosts/vault.yml):
|
|
# s3_backup_target_access_key / _secret_key (versitygw ROOT key)
|
|
# The SAME key is staged for the GitOps side (SOPS) at
|
|
# platform/backup/minio-credentials.sops.yaml
|
|
# Endpoint + key + secret + bucket names are byte-identical to the old MinIO target, so the
|
|
# cluster-side Velero/CNPG config + the SOPS secret need ZERO change.
|
|
#
|
|
# Prereqs: ansible-galaxy collection install -r collections/requirements.yml (community.general.zfs)
|
|
# Run: ansible-playbook playbooks/backup-s3.yml
|
|
- name: Provision the versitygw S3 backup target on the Proxmox host
|
|
hosts: proxmox_hosts
|
|
become: true
|
|
gather_facts: true # need ansible_facts.all_ipv4_addresses to discover the LAN bind addr
|
|
roles:
|
|
- role: s3_backup_target
|