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>
6.1 KiB
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
- Onderzoek Cove API documentatie
- Test API authenticatie
- Test data ophalen (1 backup job)
- Mapping van Cove data → Backupchecks model
- Proof of concept script (standalone)
Phase 2: Database Aanpassingen
- Beslis: extend MailMessage model of nieuwe source type?
- Migratie:
source_typeveld toevoegen aan JobRun - Migratie:
external_idveld toevoegen aan JobRun - Update constraints/validations
Phase 3: Import Mechanisme
- Nieuw bestand:
containers/backupchecks/src/backend/app/cove_importer.py - API client voor Cove
- Data transformatie naar JobRun format
- Error handling & retry logic
- Logging & audit trail
Phase 4: Scheduling
- Cronjob/scheduled task voor polling (elke 15 min?)
- Of: webhook endpoint als Cove dat ondersteunt
- Rate limiting & throttling
- Duplicate detection (niet dubbel importeren)
Phase 5: UI Updates
- Job Details: indicatie dat job van API komt (niet email)
- No "Download EML" button voor API-sourced runs
- Mogelijk andere metadata weergave
📚 Referenties
Cove Data Protection
- Product naam: Cove Data Protection (formerly N-able Backup, SolarWinds Backup)
- Website: https://www.n-able.com/products/cove-data-protection
- API Docs: [TODO: link toevoegen na research]
- Support: [TODO: contact info]
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
- Performance: Hoeveel Cove jobs moeten we monitoren? (impact op polling frequency)
- Historical Data: Kunnen we oude backup runs ophalen, of alleen nieuwe?
- Filtering: Kunnen we filters toepassen (alleen failed jobs, specifieke clients)?
- Authentication: Waar bewaren we Cove API credentials? (SystemSettings?)
- 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
- Research eerst! - Begin met API documentatie onderzoek
- Maak POC script (standalone, buiten Backupchecks)
- Documenteer bevindingen in dit bestand
- Beslis welke architecture optie (1, 2, of 3)
- 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.)