de0b1ee4db92bab0433533fd6dbfb86c6268a8b8
Two separate bugs found while testing the Audit/Details UI against a real k8s-format backup (myapps-k8s-backup-*): 1. Format-hardcoded checks. audit_backup()'s Internal Structure and Volume Count checks assumed the legacy Docker-era archive layout (volumes/*.tar.gz, compose-files/) and would fail every k8s-format backup (per-app dirs with manifests.yaml/db-dump.sql.gz/pvc-data.tar.gz) even when it's perfectly healthy - same root cause as the myapps-backup-*/myapps-k8s-backup-* prefix bug fixed earlier, just in the audit checks instead of the listing/delete glob. cloud_backup.py's r2_audit_backup() had the identical unpatched filename regex, and app.py's /api/backups/details route had its own, which outright 400'd any k8s-format filename before even looking at it. 2. A bigger, separate bug this surfaced: get_local_backups(), get_vm_backups(), and _resolve_archive_path() all branch on RUNNING_ON_MAIN_SERVER to decide between direct filesystem access and SSH-to-self - and from inside the management-platform pod that flag's hostname check can be wrong for the pod's own ephemeral hostname depending on how it's evaluated, sending these down the SSH branch using a topology (separate warm-standby-on-the-VM SSH path) that doesn't apply to a pod that already has /root hostPath-mounted in. Fixed by trying direct filesystem access first wherever the archive would already be locally reachable, falling back to the existing SSH paths otherwise - this preserves the original warm-standby-on-VM failover design (a real second deployment of this platform on the VM host, kept reachable via SSH when the main server is down) completely unchanged; it only adds the fast local path for the case where the caller already has direct filesystem access. Verified against both a real k8s-format backup (odoo, single-app) and a real legacy-format backup on disk - both audit correctly now, with format-appropriate checks and labels. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017avLHFqkiti3g62Anq9sVA
CloudOps - Infrastructure Management & Disaster Recovery Platform
Overview
This repository contains the complete infrastructure code for Navitrends' backup and disaster recovery platform.
Components
- Platform: Flask web application for backup/restore management
- Scripts: Backup, restore, and sync scripts
- Docker Compose: Configuration for all 5 applications
Applications Managed
- Nextcloud (File sharing)
- Odoo (ERP/CRM)
- Frappe/ERPNext
- Mautic (Marketing automation)
- n8n (Workflow automation)
Servers
- Main Server: 173.249.20.244
- Backup VM: 192.168.152.128
Description
Languages
PHP
66.6%
JavaScript
15.8%
Twig
8.6%
CSS
4.4%
Less
2.1%
Other
2.4%