Voor WordPress bureaus die meerdere websites van klanten beheren, is een solide backupstrategie essentieel. In het geval van een onverwachte storing, een defecte plugin of een menselijke fout, zorgen backups ervoor dat gegevens snel kunnen worden hersteld – waardoor de downtime tot een minimum wordt beperkt en het risico voor de klant afneemt.
Bij Kinsta begrijpen we de cruciale rol die backups spelen en daarom bieden we zes backupopties: automatische dagelijkse, optionele uurlijkse (en elke zes uur), handmatige, door het systeem gegenereerde, downloadbare en externe backups die rechtstreeks naar Amazon S3 of Google Cloud Storage worden gestuurd.
Hoewel het beheren van deze backups eenvoudig is via het MyKinsta dashboard, biedt Kinsta’s API geweldige mogelijkheden voor het automatiseren van repetitieve processen.
Stel je voor dat je simpelweg een commando in Slack typt of een cron job instelt om backups te activeren voor al je WordPress sites in het Kinsta account van je bureau zonder handmatig door tientallen of zelfs honderden site dashboards te hoeven navigeren.
Deze flexibiliteit is een van de vele voordelen van het gebruik van een host die prioriteit geeft aan de behoeften van zijn klanten door hen de tools te bieden om custom, tijdbesparende oplossingen te creëren.
Deze gids legt uit hoe je de Kinsta API kunt gebruiken om backups op meerdere sites te automatiseren. Of je nu integreert met de stack van je voorkeur, tools zoals Slack gebruikt of geautomatiseerde schema’s instelt, deze gids biedt je de kennis om je backupproces te stroomlijnen en je workflow te verbeteren.
Backups maken voor alle sites en geselecteerde sites
Voordat je in de planning duikt, is het belangrijk om eerst te begrijpen hoe je backups activeert voor alle sites in je Kinsta account en hoe je specifieke sites of omgevingen kunt targeten met behulp van de Kinsta API.
Zodra we de basis hebben voor het maken van backups, kunnen we eenvoudig plannen integreren om het proces te automatiseren.
Backups triggeren voor alle sites in een Kinsta account
Zoals bij elke API is er niet altijd één endpoint dat alles doet wat je nodig hebt – vaak moet je meerdere endpoints combineren om het gewenste resultaat te bereiken.
De Kinsta API is niet anders. Hoewel er specifieke endpoints zijn voor het beheren van backups, vereisen deze endpoints bepaalde parameters, zoals omgevings-ID’s, die je verkrijgt door aanvullende verzoeken te doen aan andere endpoints.
Om bijvoorbeeld een handmatige backup voor een site te activeren, heb je de omgevings-ID voor die specifieke omgeving nodig. Om de omgevings-ID te krijgen, heb je eerst de site-ID nodig. Dit betekent dat je meerdere API-aanroepen moet doen: één om de site-ID te krijgen, één om de omgevings-ID op te halen en tot slot een verzoek om de backup te activeren.
Stap 1: Alle WordPress sites ophalen met Kinsta API
De eerste stap is het ophalen van een lijst met alle sites die aan je Kinsta account zijn gekoppeld. Kinsta’s API biedt een endpoint om deze gegevens op te halen, waaronder site-ID’s, namen en andere relevante details. Met behulp van het GET /sites endpoint kun je een lijst opvragen van alle sites onder het account van je bedrijf.
Hier is een voorbeeld met Node.js en 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
}Deze functie retourneert een array van alle sites in je account. Elke site bevat informatie zoals de ID van de site, de naam en de omgeving(en).
Stap 2: Omgevings-ID’s ophalen voor elke WordPress site
Elke site kan meerdere omgevingen hebben (zoals productie of test) en backups worden per omgeving gestart. Om de omgevings-ID’s voor elke site op te halen, doe je nog een API-aanroep naar het GET /sites/{site_id}/environments endpoint.
Hier is een voorbeeldfunctie die omgevingen ophaalt voor een specifieke site:
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;
}Stap 3: Backups triggeren voor elke omgeving
Zodra je de omgevings-ID’s hebt, kun je backups voor elke omgeving activeren met het POST /sites/environments/{env_id}/manual-backups endpoint. Met de API kun je een handmatige backup maken door een omgevings-ID en een optionele tag op te geven om de backup te identificeren.
Zo activeer je een backup voor een bepaalde omgeving:
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}`);
}
}Deze functie activeert een handmatige backup voor de opgegeven omgevings-ID. Je kunt je backup ook taggen om identificatie te vergemakkelijken.
Stap 4: Backups voor alle sites automatiseren
Nu je functies hebt om alle sites op te halen, omgevings-ID’s op te halen en backups te starten, kun je ze combineren om een script te maken dat backups automatiseert voor elke site in je Kinsta account.
Dit is hoe je alles kunt samenvoegen:
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.');
}Deze functie doorloopt alle sites, haalt hun omgevingen op en activeert backups voor elke omgeving met een tag met tijdstempel.
Als je nu backupAllSites() uitvoert, wordt er een backup gemaakt van elke omgeving in je Kinsta-account.
Voorbeeld van een Slack commando
Je kunt dit backupproces integreren in een Slack commando voor nog eenvoudiger beheer. Met een Slack-app kunnen gebruikers backups maken van alle sites met één commando zoals /backup_all_sites.
Hier is een kort voorbeeld van hoe dit zou kunnen werken:
app.command('/backup_all_sites', async ({ ack, say }) => {
await ack();
await backupAllSites();
say('Backups for all sites have been triggered.');
});Backups triggeren voor geselecteerde sites met behulp van omgevings-ID’s
In sommige gevallen wil je misschien backups activeren voor alleen specifieke sites of omgevingen in plaats van alle sites in je Kinsta account. Dit kan handig zijn als je alleen een backup wilt maken van productieomgevingen of van bepaalde sites met hoge prioriteit.
Met behulp van de Kinsta API kunnen we backups automatiseren voor geselecteerde omgevingen door een array van omgevings-ID’s door te geven. Laten we eens doorlopen hoe we dit kunnen implementeren.
Stap 1: Omgeving ID’s doorgeven
Als je backups voor geselecteerde sites wilt activeren, heb je de omgevings-ID’s voor die sites nodig. Je kunt deze ID’s hard coderen, ophalen uit de Kinsta API of dynamisch doorgeven (zoals via een opdrachtregelargument, Slack commando, etc.).
Hier is een functie die een array van omgevings-ID’s accepteert en voor elke omgeving een backup activeert:
async function backupSelectedEnvironments(environmentIds, tag) {
for (const envId of environmentIds) {
await createBackup(envId, tag);
}
}De bovenstaande functie ontvangt een array van omgevings-ID’s waarvan je een backup wilt maken (environmentIds). De functie createBackup(envId, tag) activeert de backup voor elke omgeving in de array met behulp van de functie createBackup() (uitgelegd in Stap 2).
Stap 2: De backup triggeren
Om de daadwerkelijke backup voor elke omgeving te triggeren, gebruik je het Kinsta API POST /sites/environments/{env_id}/manual-backups endpoint zoals we voor alle sites hebben gedaan. Dit is hoe het werkt:
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}`);
}
}Stap 3: Backups uitvoeren voor geselecteerde omgevingen
Nu we functies hebben om backups te triggeren en meerdere omgevingen af te handelen, kunnen we ze combineren om een backup te maken van specifieke omgevingen. In dit voorbeeld gaan we ervan uit dat we al de ID’s van de omgevingen hebben waarvan we een backup willen maken.
const selectedEnvironments = ['12345', '67890']; // Replace with actual environment IDs
backupSelectedEnvironments(selectedEnvironments, 'Manual Backup');In dit geval:
- De array
selectedEnvironmentsbevat de omgevings-ID’s waarvan je een backup wilt maken. - De functie
backupSelectedEnvironments()doorloopt elke ID en activeert de backup met de tag ‘Manual Backup’.
Voorbeeld Slack commando
Als je een Slack app of opdrachtregelinterface gebruikt, kun je gebruikers ook laten opgeven van welke omgevingen een backup moet worden gemaakt.
Hier zie je hoe je dit zou kunnen implementeren in een Slack app:
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}.`);
});De gebruiker voert een commando in als /backup_selected_envs Backup-Tag 12345 67890, waarbij Backup-Tag de tag is en 12345, 67890 de omgevings-ID’s.
De tekst van het commando wordt gesplitst en de omgevings-ID’s worden doorgegeven aan de functie backupSelectedEnvironments().
Nadat de backups zijn gestart, antwoordt de app de gebruiker dat de backup is gemaakt.
Backups plannen voor je WordPress sites
Een van de krachtigste aspecten van automatisering is de mogelijkheid om taken te plannen op specifieke tijdstippen zonder handmatige tussenkomst.
Nu we hebben behandeld hoe je backups voor alle sites en geselecteerde sites kunt activeren, is de volgende stap om deze processen te automatiseren door planning toe te voegen.
Of je nu lokaal backups wilt plannen, op een gehost platform zoals Kinsta, of dynamisch via Slack, er zijn verschillende manieren om dit te implementeren.
Cron expressies begrijpen
Voordat je de verschillende benaderingen voor het plannen van backups gaat verkennen, is het belangrijk om cron expressies te begrijpen, die worden gebruikt om de timing voor geplande taken op te geven op verschillende platforms en tools.
Cron expressies definiëren wanneer een taak moet worden uitgevoerd. Ze worden gebruikt in veel planningsbibliotheken en -services, zoals node-cron, node-schedule en zelfs cron jobs aan de serverkant, zoals die beschikbaar zijn in Kinsta’s Applicatie Hosting platform.
Cron expressies bestaan uit vijf velden, die elk een specifiek aspect bepalen van wanneer de taak moet worden uitgevoerd. Een typische cron expressie ziet er als volgt uit:
* * * * *
| | | | |
| | | | └─── 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)Laten we eens uitsplitsen wat elk veld voorstelt:
- Minute: De minuut van het uur waarop de taak moet worden uitgevoerd (0 – 59).
- Hour: Het uur van de dag waarop de taak moet worden uitgevoerd (0 – 23).
- Day of the month: De specifieke dag van de maand waarop de taak moet worden uitgevoerd (1 – 31).
- Month: De maand van het jaar om de taak uit te voeren (1 – 12).
- Day of the week: De specifieke dag van de week om de taak uit te voeren (0 – 7, waarbij 0 en 7 beide voor zondag staan).
Je kunt specifieke waarden, jokertekens (*) of bereiken in elk veld gebruiken om het schema te definiëren.
Voorbeelden van cron expressies:
0 0 * * *: Elke dag om middernacht (00:00)0 3 * * 1: Elke maandag om 3 uur ’s nachts*/10 * * * *: Elke 10 minuten0 9-18 * * *: Elk uur tussen 9.00 en 18.00 uur.
Met een goed begrip van cron expressies kunnen we nu verder gaan met verschillende methoden voor het plannen van backups voor je WordPress sites met behulp van de Kinsta API.
Aanpak 1: Lokaal plannen met node-cron
Het Node.js pakket node-cron kan geplande taken uitvoeren op basis van een cron-achtige syntaxis. Het is ideaal voor het uitvoeren van geautomatiseerde taken in lokale of zelfstandige Node.js applicaties en het is een populaire keuze voor het plannen van backups, het verzenden van e-mails of het uitvoeren van andere terugkerende taken.
In node-cron definieer je een taak (zoals je backupfunctie) en gebruik je een cron expressie om aan te geven wanneer de taak moet worden uitgevoerd. De cron expressie bestaat uit vijf velden die de minuut, het uur, de dag van de maand, de maand en de dag van de week aangeven wanneer de taak moet worden uitgevoerd.
Installeer eerst node-cron in je project:
npm install node-cronLaten we zeggen dat je een dagelijkse backup van alle sites om middernacht wilt plannen met behulp van node-cron. Dit is hoe je dat kunt doen:
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();
});Op dezelfde manier, als je elke dag om 2 uur ’s nachts een backup wilt maken van geselecteerde omgevingen, zou je dat als volgt kunnen plannen:
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');
});Aanpak 2: Cron jobs gebruiken in cloud hosting (zoals Kinsta)
Als je je Node.js applicatie inzet op een platform zoals dat van Kinsta, kun je de ingebouwde cron job functionaliteit van het platform gebruiken om taken zoals backups te plannen. Het instellen van cron jobs in cloud omgevingen vereist echter een iets andere structuur dan lokale scheduling tools zoals node-cron.
Als je je app uitrolt naar Kinsta, moet deze een draaiend webproces hebben (zelfs als deze niet daadwerkelijk webverkeer afhandelt).
Om ervoor te zorgen dat je project correct draait en niet automatisch backup functies callt, kun je een bestand maken dat een eenvoudige webserver draait. Dit bestand fungeert als een “dummy” webproces, terwijl cron jobs de backuplogica afhandelen.
Je kunt deze code toevoegen:
require('http').createServer((req, res) => {
res.writeHead(302, { Location: 'https://www.google.com' });
res.end();
}).listen(process.env.PORT);Op deze manier kun je een scriptcommando instellen om onderscheid te maken tussen het webproces (start) en het cron job proces (cron).
"scripts": {
"start": "node index.js", // Web process
"cron": "node app.js" // Cron job process
},Tot slot configureer je de cron job in Kinsta om je backupfunctie op het opgegeven tijdstip te callen. Met behulp van de cron job instellingen kun je het commando definiëren om de backup uit te voeren.
Stel in het tabblad Processen van de applicaties van het MyKinsta dashboard het commando voor het webproces in op:
npm run startEn stel het commando voor de cron job in op:
npm run cronOm de cron job op een specifieke tijd uit te voeren (elke dag om 11:30), stel je de cron expressie als volgt in:
30 11 * * *Deze opdracht activeert de backupAllSites() functie elke dag om 11:30 uur.
Aanpak 3: Plannen met node-schedule
Een andere Node.js bibliotheek, node-schedule, kan taken plannen met het cron format en ondersteunt ook complexere schema’s.
Hier is een voorbeeld waarmee gebruikers backups kunnen plannen via Slack met behulp van het cron-format van 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.`);
});Een gebruiker kan bijvoorbeeld het volgende Slack commando uitvoeren om een backup te plannen voor 23:30 uur:
/schedule_backup 23:30Na het uitvoeren van dit commando wordt de backup elke dag om 23:30 uur ingepland. Het antwoord van Slack zou er als volgt uit kunnen zien:
Backup scheduled at 23:30 successfully.Met deze aanpak kunnen gebruikers dynamisch backups plannen vanuit Slack door simpelweg de tijd op te geven zonder interactie met de server of de applicatiecode. Het is een flexibele en krachtige manier om geplande taken zoals backups op een gebruiksvriendelijke manier af te handelen.
Samenvatting
Het plannen van backups op meerdere WordPress sites is handig voor bureaus die veel websites van klanten beheren. Het automatiseren van deze backups bespaart niet alleen tijd, maar zorgt ook voor consistentie, vermindert de kans op menselijke fouten en zorgt voor gemoedsrust.
Zou jouw bureau baat hebben bij deze oplossing? We horen graag wat je ervan vindt. Deel ze in de comments hieronder!
Laat een reactie achter