Per le agenzie WordPress che gestiscono più siti web di clienti, avere una solida strategia di backup è essenziale. Nell’eventualità di un’interruzione imprevista, di un problema con i plugin o di un errore umano, i backup garantiscono un rapido ripristino dei dati, riducendo al minimo i tempi di inattività e i rischi per i clienti.
Noi di Kinsta siamo consapevoli del ruolo cruciale dei backup ed è per questo che offriamo sei opzioni di backup: automatico giornaliero, opzionale ogni ora (e ogni sei ore), manuale, generato dal sistema, scaricabile e backup esterni inviati direttamente ad Amazon S3 o Google Cloud Storage.
Sebbene la gestione di questi backup sia semplice attraverso la dashboard di MyKinsta, l’API di Kinsta offre grandi possibilità di automatizzare i processi ripetitivi.
Immaginate di digitare semplicemente un comando in Slack o di impostare un cron job per attivare i backup di tutti i vostri siti WordPress nell’account della vostra agenzia Kinsta senza dover navigare manualmente tra decine o addirittura centinaia di dashboard di siti.
Questa flessibilità è uno dei tanti vantaggi dell’utilizzo di un host che dà la priorità alle esigenze dei propri clienti fornendo loro gli strumenti per creare soluzioni personalizzate che facciano risparmiare tempo.
Questa guida spiega come sfruttare l’API di Kinsta per automatizzare i backup di più siti. Che si tratti di integrazione con il vostro stack preferito, di utilizzo di strumenti come Slack o di impostazione di pianificazioni automatiche, questa guida fornisce le conoscenze necessarie per ottimizzare il processo di backup e migliorare il vostro flusso di lavoro.
Implementare i backup per tutti i siti e per siti selezionati
Prima di immergersi nella pianificazione, è importante capire come attivare i backup per tutti i siti del vostro account Kinsta e come selezionare siti o ambienti specifici utilizzando l’API Kinsta.
Una volta costruite le basi per creare i backup, possiamo facilmente integrare la pianificazione per automatizzare il processo.
Attivare i backup per tutti i siti di un account Kinsta
Come per tutte le API, non sempre esiste un unico endpoint per fare tutto ciò di cui si ha bisogno: spesso è necessario combinare più endpoint per ottenere il risultato desiderato.
Vale lo stesso per l’API di Kinsta. Sebbene esistano endpoint specifici per la gestione dei backup, questi endpoint richiedono alcuni parametri, come gli ID dell’ambiente, che si ottengono effettuando richieste aggiuntive ad altri endpoint.
Ad esempio, per attivare un backup manuale di un sito, avete bisogno dell’ID ambiente di quel particolare ambiente. Per ottenere l’ID ambiente, serve prima ottenere l’ID sito. Ciò significa che dovrete effettuare più chiamate API: una per ottenere l’ID del sito, un’altra per recuperare l’ID dell’ambiente e infine una richiesta per attivare il backup.
Passo 1: Recuperare tutti i siti WordPress con Kinsta API
Il primo passo consiste nel recuperare un elenco di tutti i siti associati al vostro account Kinsta. L’API di Kinsta fornisce un endpoint per recuperare questi dati, che includono gli ID dei siti, i nomi e altri dettagli rilevanti. Utilizzando l’endpoint GET /sites, potete ottenere un elenco di tutti i siti associati all’account della vostra azienda.
Ecco un esempio che utilizza Node.js e Fetch API:
require('dotenv').config();
const KINSTA_API_URL = 'https://api.kinsta.com/v2';
const API_KEY = process.env.KINSTA_API_KEY;
async function getAllSites() {
const response = await fetch(`${KINSTA_API_URL}/sites`, {
headers: {
Authorization: `Bearer ${API_KEY}`
}
});
const data = await response.json();
return data.company.sites; // Returns array of all sites
}Questa funzione restituisce un array di tutti i siti del vostro account. Ogni sito contiene informazioni quali l’ID, il nome e l’ambiente del sito.
Passo 2: Recuperare gli ID degli ambienti per ogni sito WordPress
Ogni sito può avere più ambienti (come la produzione o lo staging) e i backup vengono attivati per ogni ambiente. Per recuperare gli ID ambiente per ogni sito, dovrete effettuare un’altra chiamata API all’endpoint GET /sites/{site_id}/environments.
Ecco un esempio di funzione che recupera gli ambienti per un sito specifico:
async function getSiteEnvironments(siteId) {
const response = await fetch(`${KINSTA_API_URL}/sites/${siteId}/environments`, {
headers: {
Authorization: `Bearer ${API_KEY}`
}
});
const data = await response.json();
return data.site.environments;
}Passo 3: Attivare i backup per ogni ambiente
Una volta ottenuti gli ID degli ambienti, è possibile attivare i backup per ciascun ambiente utilizzando l’endpoint POST /sites/environments/{env_id}/manual-backups. L’API permette di creare un backup manuale fornendo un ID ambiente e un tag opzionale per identificare il backup.
Ecco come attivare un backup per un determinato ambiente:
async function createBackup(environmentId, tag) {
const response = await fetch(`${KINSTA_API_URL}/sites/environments/${environmentId}/manual-backups`, {
method: 'POST',
headers: {
Authorization: `Bearer ${API_KEY}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({ tag })
});
if (response.ok) {
console.log(`Backup created for environment ${environmentId} with tag: ${tag}`);
} else {
console.error(`Failed to create backup for environment ${environmentId}`);
}
}Questa funzione attiva un backup manuale per l’ID ambiente indicato. Potete anche etichettare il vostro backup per facilitarne l’identificazione.
Passo 4: Automatizzare i backup per tutti i siti
Ora che avete le funzioni per recuperare tutti i siti, gli ID ambiente e i backup, potete combinarle per creare uno script che automatizzi i backup per tutti i siti del vostro account Kinsta.
Ecco come collegare il tutto:
async function backupAllSites() {
const sites = await getAllSites();
for (const site of sites) {
const environments = await getSiteEnvironments(site.id);
for (const environment of environments) {
await createBackup(environment.id, `Backup-${new Date().toISOString()}`);
}
}
console.log('Backups for all sites have been triggered.');
}Questa funzione esegue un loop di tutti i siti, recupera i loro ambienti e attiva i backup per ogni ambiente con un tag con data e ora.
Ora, quando eseguite backupAllSites(), viene attivato un backup per ogni ambiente del vostro account Kinsta.
Esempio di comando Slack
Potete integrare questo processo di backup in un comando Slack per una gestione ancora più semplice. Configurando un’app Slack, gli utenti possono attivare il backup di tutti i siti con un unico comando come /backup_all_sites.
Ecco un rapido esempio di come potrebbe funzionare:
app.command('/backup_all_sites', async ({ ack, say }) => {
await ack();
await backupAllSites();
say('Backups for all sites have been triggered.');
});Attivare i backup per siti selezionati utilizzando gli ID ambiente
In alcuni casi, potreste voler attivare i backup solo per siti o ambienti specifici piuttosto che per tutti i siti del vostro account Kinsta. Questo potrebbe essere utile se volete eseguire il backup solo degli ambienti di produzione o di alcuni siti ad alta priorità.
Utilizzando l’API di Kinsta, possiamo automatizzare i backup per ambienti selezionati passando un array di ID ambiente. Vediamo come implementarlo.
Passo 1: Passare gli ID degli ambienti
Per attivare i backup per i siti selezionati, avete bisogno degli ID ambiente di tali siti. Potete codificare questi ID, recuperarli dall’API di Kinsta o passarli dinamicamente (ad esempio tramite un argomento della riga di comando, un comando Slack, ecc.)
Ecco una funzione che accetta un array di ID ambiente e attiva i backup per ciascuno di essi:
async function backupSelectedEnvironments(environmentIds, tag) {
for (const envId of environmentIds) {
await createBackup(envId, tag);
}
}La funzione qui sopra riceve un array di ID ambiente di cui si vuole eseguire il backup (environmentIds). La funzione createBackup(envId, tag) attiva il backup per ogni ambiente dell’array utilizzando la funzione createBackup() (spiegata nel passaggio 2).
Passo 2: Attivare il backup
Per attivare il backup vero e proprio per ogni ambiente, usate l’endpoint POST /sites/environments/{env_id}/manual-backups dell’API di Kinsta come abbiamo fatto per tutti i siti. Ecco come funziona:
async function createBackup(environmentId, tag) {
const response = await fetch(`${KINSTA_API_URL}/sites/environments/${environmentId}/manual-backups`, {
method: 'POST',
headers: {
Authorization: `Bearer ${API_KEY}`,
'Content-Type': 'application/json'
},
body: JSON.stringify({ tag })
});
if (response.ok) {
console.log(`Backup created for environment ${environmentId} with tag: ${tag}`);
} else {
console.error(`Failed to create backup for environment ${environmentId}: ${response.statusText}`);
}
}Passo 3: Eseguire i backup per gli ambienti selezionati
Ora che abbiamo le funzioni per attivare i backup e gestire più ambienti, possiamo combinarle per eseguire il backup di ambienti specifici. Questo esempio presuppone che abbiamo già gli ID degli ambienti di cui vogliamo fare il backup.
const selectedEnvironments = ['12345', '67890']; // Replace with actual environment IDs
backupSelectedEnvironments(selectedEnvironments, 'Manual Backup');In questo caso:
- L’array
selectedEnvironmentscontiene gli ID dell’ambiente di cui si vuole eseguire il backup. - La funzione
backupSelectedEnvironments()esegue un ciclo per ogni ID e attiva il backup con il tag “Backup manuale”.
Esempio di comando Slack
Se utilizzate un’applicazione Slack o un’interfaccia a riga di comando, potete anche permettere agli utenti di specificare di quali ambienti eseguire il backup.
Ecco come potreste implementare questa funzione in un’app Slack:
app.command('/backup_selected_envs', async ({ command, ack, say }) => {
await ack();
const [tag, ...envIds] = command.text.split(' '); // First part is the tag, rest are env IDs
await backupSelectedEnvironments(envIds, tag);
say(`Backups triggered for selected environments with tag ${tag}.`);
});L’utente inserisce un comando come /backup_selected_envs Backup-Tag 12345 67890, dove Backup-Tag è il tag e 12345, 67890 sono gli ID degli ambienti.
Il testo del comando viene suddiviso e gli ID ambiente vengono passati alla funzione backupSelectedEnvironments().
Dopo aver attivato i backup, l’applicazione risponde all’utente confermando il backup.
Pianificare i backup per i propri siti WordPress
Uno degli aspetti più preziosi dell’automazione è la possibilità di programmare attività in momenti specifici senza alcun intervento manuale.
Ora che abbiamo spiegato come attivare i backup per tutti i siti e per quelli selezionati, il passo successivo è quello di automatizzare questi processi aggiungendo la pianificazione.
Se volete pianificare i backup in locale, su una piattaforma ospitata come Kinsta o in modo dinamico tramite Slack, ci sono vari modi per implementarli.
Le espressioni cron
Prima di esplorare i diversi approcci alla pianificazione dei backup, è importante capire come funzionano le espressioni cron, che vengono utilizzate per specificare le tempistiche delle attività pianificate su varie piattaforme e strumenti.
Le espressioni cron definiscono quando un’attività deve essere eseguita. Sono utilizzate in molte librerie e servizi di pianificazione, come node-cron, node-schedule e anche cron job lato server come quelli disponibili nella piattaforma dell’Hosting di Applicazioni di Kinsta.
Le espressioni cron sono composte da cinque campi, ognuno dei quali controlla un aspetto specifico del momento in cui l’attività deve essere eseguita. Una tipica espressione cron si presenta come segue:
* * * * *
| | | | |
| | | | └─── Day of the week (0 - 7) (Sunday to Saturday, 0 and 7 represent Sunday)
| | | └────── Month (1 - 12)
| | └──────── Day of the month (1 - 31)
| └────────── Hour (0 - 23)
└──────────── Minute (0 - 59)Vediamo cosa rappresenta ogni campo:
- Minute: il minuto dell’ora in cui l’attività deve essere eseguita (0 – 59).
- Hour: l’ora del giorno in cui l’attività deve essere eseguita (0 – 23).
- Day of the month: il giorno specifico del mese in cui eseguire l’attività (1 – 31).
- Month: il mese dell’anno in cui eseguire l’attività (1 – 12).
- Day of the week: il giorno specifico della settimana in cui eseguire l’attività (0 – 7, dove 0 e 7 rappresentano entrambi la domenica).
Potete utilizzare valori specifici, caratteri jolly (*) o intervalli in ogni campo per definire la pianificazione.
Esempi di espressioni cron:
0 0 * * *: ogni giorno a mezzanotte (00:00)0 3 * * 1: ogni lunedì alle 3 del mattino*/10 * * * *: ogni 10 minuti0 9-18 * * *: ogni ora tra le 9.00 e le 18.00.
Con una solida conoscenza delle espressioni cron, possiamo ora passare a diversi metodi di pianificazione dei backup per i siti WordPress utilizzando l’API Kinsta.
Approccio 1: Pianificazione locale con node-cron
Il pacchetto Node.js node-cron è in grado di eseguire attività programmate basate su una sintassi simile a quella di cron. È ideale per l’esecuzione di attività automatizzate in applicazioni Node.js locali o standalone ed è una scelta popolare per pianificare backup, inviare e-mail o eseguire altre attività ricorrenti.
In node-cron, definite un’attività (come la funzione di backup) e utilizzate un’espressione cron per specificare quando l’attività deve essere eseguita. L’espressione cron è composta da cinque campi che definiscono il minuto, l’ora, il giorno del mese, il mese e il giorno della settimana in cui l’attività deve essere eseguita.
Per prima cosa, installate node-cron nel vostro progetto:
npm install node-cronSupponiamo che vogliate programmare un backup giornaliero di tutti i siti a mezzanotte utilizzando node-cron. Ecco come fare:
const cron = require('node-cron');
const { backupAllSites } = require('./app'); // Import the backup function
// Schedule to run backups for all sites at midnight every day
cron.schedule('0 0 * * *', () => {
console.log('Running scheduled backup for all sites at midnight...');
backupAllSites();
});Allo stesso modo, se volete eseguire il backup di alcuni ambienti selezionati alle 2 del mattino di ogni giorno, potete programmarlo in questo modo:
cron.schedule('0 2 * * *', () => {
const environmentIds = ['env12345', 'env67890']; // Specific environments to back up
console.log('Running scheduled backup for selected environments...');
backupSelectedEnvironments(environmentIds, 'Scheduled Backup');
});Approccio 2: Usare i cron job nel cloud hosting (come Kinsta)
Quando distribuite la vostra applicazione Node.js su una piattaforma come Kinsta, potete sfruttare la funzionalità di cron job integrata nella piattaforma per pianificare attività come i backup. Tuttavia, l’impostazione dei cron job negli ambienti cloud richiede una struttura leggermente diversa rispetto agli strumenti di pianificazione locali come node-cron.
Quando si distribuisce un’applicazione su Kinsta, questa deve avere un processo web in esecuzione (anche se non sta effettivamente servendo il traffico web).
Per assicurarvi che il vostro progetto venga eseguito correttamente e che non richiami automaticamente le funzioni di backup, potete creare un file che esegua un semplice server web. Questo file funge da processo web “fittizio”, mentre i cron job gestiscono la logica di backup.
Potete aggiungere questo codice:
require('http').createServer((req, res) => {
res.writeHead(302, { Location: 'https://www.google.com' });
res.end();
}).listen(process.env.PORT);In questo modo, potete impostare il comando di script per distinguere tra il processo web (start) e il processo cron job (cron).
"scripts": {
"start": "node index.js", // Web process
"cron": "node app.js" // Cron job process
},Infine, configurate il cron job in Kinsta per richiamare la funzione di backup all’ora specificata. Utilizzando le impostazioni del cron job, potete definire il comando per eseguire il backup.
Nella scheda Processi della dashboard delle applicazioni di MyKinsta, impostate il comando per il processo web su:
npm run startE impostate il comando del cron job su:
npm run cronPer eseguire il cron job a un orario specifico (ogni giorno alle 11:30), impostate l’espressione cron in questo modo:
30 11 * * *Questo comando attiverà la funzione backupAllSites() ogni giorno alle 11:30.
Approccio 3: Pianificazione con node-schedule
Un’altra libreria Node.js, node-schedule, può programmare attività utilizzando il formato cron e supporta anche pianificazioni più complesse.
Ecco un esempio che permette agli utenti di programmare i backup via Slack utilizzando il formato cron di node-schedule:
const schedule = require('node-schedule');
const { backupAllSites } = require('./app');
// Slack command to schedule backups dynamically
app.command('/schedule_backup', async ({ command, ack, say }) => {
await ack();
// Extract hour and minute from the command (expects HH:MM format)
const [hour, minute] = command.text.split(':');
// Validate input
if (!hour || !minute) {
say('Please specify the time in HH:MM format.');
return;
}
// Schedule the backup using node-schedule's cron-like format
const job = schedule.scheduleJob(`${minute} ${hour} * * *`, () => {
console.log(`Running scheduled backup at ${hour}:${minute}`);
backupAllSites(); // This triggers the backup for all sites
});
say(`Backup scheduled at ${hour}:${minute} successfully.`);
});Ad esempio, un utente può eseguire il seguente comando Slack per programmare un backup per le 23:30:
/schedule_backup 23:30Dopo aver eseguito questo comando, il backup sarà programmato per essere eseguito alle 23:30 di ogni giorno. La risposta di Slack potrebbe essere la seguente:
Backup scheduled at 23:30 successfully.Questo approccio permette agli utenti di programmare dinamicamente i backup da Slack semplicemente specificando l’orario senza dover interagire con il server o il codice dell’applicazione. Si tratta di un modo flessibile ed efficace per gestire attività programmate come i backup in modo semplice e intuitivo.
Riepilogo
Pianificare i backup su più siti WordPress è utile per le agenzie che gestiscono numerosi siti web di clienti. Automatizzare questi backup non solo fa risparmiare tempo, ma assicura anche coerenza, riduce il rischio di errori umani e garantisce la massima tranquillità.
Questa soluzione sarebbe utile alla vostra agenzia? Ci piacerebbe conoscere le vostre opinioni. Condividetele con noi nella sezione commenti qui sotto!
Lascia un commento