6. API di stato dei backup

L'appliance espone un'interfaccia programmatica che restituisce lo stato dei backup in formato JSON. Serve a portare quell'informazione dentro un sistema di monitoraggio, un cruscotto o uno script, senza dover leggere i messaggi di posta.

Il percorso è Storage → API.

6.1 Chiave di accesso

La pagina mostra l'indirizzo dell'endpoint e la chiave API generata dall'appliance, conservata in un file di sistema. Il pulsante Rigenera API Key la sostituisce con una nuova.

La chiave è una credenziale

Chi possiede la chiave può interrogare l'appliance senza altra autenticazione. Non va incollata in documenti condivisi, ticket o messaggi, e va rigenerata quando qualcuno che la conosceva non deve più averla.

Rigenerandola, tutti gli script che la usano smettono di funzionare finché non ricevono quella nuova.

6.2 Chiamare l'API

La richiesta si fa in GET o in POST verso https://<indirizzo-appliance>:8443/adm/api/noauth_backups_status/.

Parametro	Note
APIKEY	Obbligatorio, è la chiave mostrata nella pagina
pretty	1 restituisce il JSON formattato, più leggibile
type	job, remote oppure all (predefinito)
name	Filtra su un singolo backup, per nome

Un esempio con curl:

curl --insecure -X GET \
  "https://192.168.1.50:8443/adm/api/noauth_backups_status/?APIKEY=LA_TUA_CHIAVE&type=job&pretty=1"

L'opzione --insecure serve finché l'appliance presenta un certificato autofirmato; con un certificato riconosciuto va tolta.

6.3 La risposta

La risposta contiene due elenchi: jobs, con i backup job, e remotes, con i backup remoti. Ogni voce riporta:

Campo	Significato
name, type	Nome del backup e sua natura
enabled	Se il backup è abilitato
status	Stato corrente, per esempio idle
error	Se l'ultima esecuzione si è conclusa con errore
last_exec, last_exec_ts	Data dell'ultima esecuzione; la seconda in secondi Unix, ricavata dalla data del file di log
running, running_since, running_pid	Se il backup è in corso e da quando

{
  "result": "ok",
  "generated_at": "2026-02-04T16:25:31+01:00",
  "jobs": [
    {
      "name": "server-gestionale",
      "type": "job",
      "status": "idle",
      "enabled": true,
      "error": false,
      "last_exec": "2026-02-04T02:15:00+01:00",
      "last_exec_ts": 1770167700,
      "running": false
    }
  ],
  "remotes": []
}

Il controllo utile è l'età dell'ultima esecuzione

Un backup che fallisce si nota, perché error diventa vero. Un backup che non parte più non produce alcun errore: resta idle con enabled a vero e last_exec_ts fermo.

Il controllo da automatizzare è quindi la distanza fra last_exec_ts e l'ora attuale: se supera l'intervallo previsto, qualcosa non sta girando.