backupchecks/TODO-cove-data-protection.md
Ivo Oskamp 1de1b032e7 Add TODO for Cove Data Protection integration
Created comprehensive TODO document for integrating Cove Data Protection
(formerly N-able Backup) into Backupchecks.

Key challenges:
- Cove does not use email notifications like other backup systems
- Need to research API availability and authentication methods
- Must determine optimal integration strategy (polling vs webhooks)

Document includes:
- Research questions (API availability, data structure, multi-tenancy)
- Three architecture options for integration
- Implementation phases (research, database, import, scheduling, UI)
- Success criteria and open questions
- References section for documentation links

Status: Research phase - waiting on API documentation investigation

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
2026-02-10 15:32:12 +01:00

6.1 KiB

TODO: Cove Data Protection Integration

Datum: 2026-02-10 Status: Research fase Prioriteit: Medium


🎯 Doel

Cove Data Protection (formerly N-able Backup / SolarWinds Backup) integreren in Backupchecks voor monitoring van backup status.

Uitdaging: Cove werkt NIET met email notificaties zoals andere backup systemen (Veeam, Synology, NAKIVO). We moeten een alternatieve methode vinden om backup status informatie binnen te halen.


🔍 Research Vragen

1. API Beschikbaarheid

  • Heeft Cove Data Protection een publieke API?
  • Welke authenticatie methode gebruikt de API? (API key, OAuth, basic auth?)
  • Welke endpoints zijn beschikbaar voor backup status?
  • Is er rate limiting op de API?
  • Documentatie URL: ?

2. Data Structuur

  • Welke informatie kunnen we ophalen per backup job?
    • Job naam
    • Status (success/warning/failed)
    • Start/eind tijd
    • Backup type
    • Client/device naam
    • Error messages
    • Objects/files backed up
  • Is er een webhook systeem beschikbaar?
  • Hoe vaak moet de API gepolld worden?

3. Multi-Tenancy

  • Ondersteunt Cove multi-tenant setups? (MSP use case)
  • Kunnen we meerdere customers/partners monitoren vanuit 1 account?
  • Hoe worden permissions/access geregeld?

4. Integratie Strategie

  • Optie A: Scheduled Polling

    • Cronjob die periodiek API aanroept
    • Parse resultaten naar JobRun records
    • Pro: Eenvoudig, consistent met huidige flow
    • Con: Delay tussen backup en registratie in systeem
  • Optie B: Webhook/Push

    • Cove stuurt notificaties naar ons endpoint
    • Pro: Real-time updates
    • Con: Requires external endpoint, security considerations
  • Optie C: Email Forwarding

    • Als Cove toch email support heeft (hidden setting?)
    • Pro: Hergebruikt bestaande email import flow
    • Con: Mogelijk niet beschikbaar

📋 Technische Overwegingen

Database Model

Huidige JobRun model verwacht:

  • mail_message_id (FK) - hoe gaan we dit aanpassen voor API-sourced runs?
  • Mogelijk nieuw veld: source_type ("email" vs "api")
  • Mogelijk nieuw veld: external_id (Cove job ID)

Parser Systeem

Huidige parser systeem werkt met email content. Voor API:

  • Nieuw "parser" concept voor API responses?
  • Of direct JobRun creatie zonder parser layer?

Architecture Opties

Optie 1: Extend Email Import System

API Poller → Pseudo-MailMessage → Existing Parser → JobRun
  • Pro: Hergebruik bestaande flow
  • Con: Hacky, email velden hebben geen betekenis

Optie 2: Parallel Import System

API Poller → API Parser → JobRun (direct)
  • Pro: Clean separation, geen email dependency
  • Con: Duplicatie van logic

Optie 3: Unified Import Layer

         → Email Import →
Unified  →                → Common Processor → JobRun
         → API Import   →
  • Pro: Future-proof, schaalbaar
  • Con: Grotere refactor

🔧 Implementatie Stappen (Na Research)

Phase 1: API Research & POC

  1. Onderzoek Cove API documentatie
  2. Test API authenticatie
  3. Test data ophalen (1 backup job)
  4. Mapping van Cove data → Backupchecks model
  5. Proof of concept script (standalone)

Phase 2: Database Aanpassingen

  1. Beslis: extend MailMessage model of nieuwe source type?
  2. Migratie: source_type veld toevoegen aan JobRun
  3. Migratie: external_id veld toevoegen aan JobRun
  4. Update constraints/validations

Phase 3: Import Mechanisme

  1. Nieuw bestand: containers/backupchecks/src/backend/app/cove_importer.py
  2. API client voor Cove
  3. Data transformatie naar JobRun format
  4. Error handling & retry logic
  5. Logging & audit trail

Phase 4: Scheduling

  1. Cronjob/scheduled task voor polling (elke 15 min?)
  2. Of: webhook endpoint als Cove dat ondersteunt
  3. Rate limiting & throttling
  4. Duplicate detection (niet dubbel importeren)

Phase 5: UI Updates

  1. Job Details: indicatie dat job van API komt (niet email)
  2. No "Download EML" button voor API-sourced runs
  3. Mogelijk andere metadata weergave

📚 Referenties

Cove Data Protection

Vergelijkbare Integraties

Andere backup systemen die API gebruiken:

  • Veeam: Heeft zowel email als REST API
  • Acronis: REST API beschikbaar
  • MSP360: API voor management

Resources

  • API documentation (nog te vinden)
  • SDK/Client libraries beschikbaar?
  • Community/forum voor integratie vragen?
  • Example code/integrations?

Open Vragen

  1. Performance: Hoeveel Cove jobs moeten we monitoren? (impact op polling frequency)
  2. Historical Data: Kunnen we oude backup runs ophalen, of alleen nieuwe?
  3. Filtering: Kunnen we filters toepassen (alleen failed jobs, specifieke clients)?
  4. Authentication: Waar bewaren we Cove API credentials? (SystemSettings?)
  5. Multi-Account: Ondersteunen we meerdere Cove accounts? (MSP scenario)

🎯 Success Criteria

Minimum Viable Product (MVP)

  • Backup runs van Cove worden automatisch geïmporteerd
  • Status (success/warning/failed) correct weergegeven
  • Job naam en timestamp beschikbaar
  • Zichtbaar in Daily Jobs & Run Checks
  • Errors en warnings worden getoond

Nice to Have

  • Real-time import (webhook ipv polling)
  • Backup object details (individuele files/folders)
  • Retry history
  • Storage usage metrics
  • Multi-tenant support

🚀 Volgende Stappen

  1. Research eerst! - Begin met API documentatie onderzoek
  2. Maak POC script (standalone, buiten Backupchecks)
  3. Documenteer bevindingen in dit bestand
  4. Beslis welke architecture optie (1, 2, of 3)
  5. Dan pas implementatie starten

Status: Wachten op API research completion.


📝 Notes

  • Dit TODO document moet bijgewerkt worden na elke research stap
  • Voeg API voorbeelden toe zodra beschikbaar
  • Documenteer edge cases en beperkingen
  • Overweeg security implications (API keys opslag, rate limits, etc.)