Scheduling backups for multiple sites with Kinsta API

For WordPress agencies managing multiple client websites, having a robust backup strategy is essential. In the event of an unexpected outage, plugin failure, or human error, backups ensure data can be quickly restored — minimizing downtime and reducing client risk.

At Kinsta, we understand the critical role backups play, which is why we offer six backup options: automatic daily, optional hourly (and every six hours), manual, system-generated, downloadable, and external backups sent directly to Amazon S3 or Google Cloud Storage.

While managing these backups is straightforward via the MyKinsta dashboard, Kinsta’s API opens up great possibilities for automating repetitive processes.

Imagine simply typing a command in Slack or setting up a cron job to trigger backups for all your WordPress sites in your Kinsta agency account without manually navigating through dozens or even hundreds of site dashboards.

This flexibility is one of the many advantages of using a host that prioritizes its clients’ needs by providing them with the tools to create custom, time-saving solutions.

This guide explains how to leverage the Kinsta API to automate backups across multiple sites. Whether you’re integrating with your preferred stack, using tools like Slack, or setting up automated schedules, this guide provides you with the knowledge to streamline your backup process and enhance your workflow.

Implementing backups for all sites and selected sites

Before diving into scheduling, it’s important to first understand how to trigger backups for all sites in your Kinsta account and how to target specific sites or environments using the Kinsta API.

Once we have the foundation for creating backups, we can easily integrate scheduling to automate the process.

Triggering backups for all sites in a Kinsta account

Like with every API, there isn’t always a single endpoint to do everything you need — you often have to combine multiple endpoints to achieve your desired result.

The Kinsta API is no different. While there are specific endpoints for managing backups, these endpoints require certain parameters, such as environment IDs, which you obtain by making additional requests to other endpoints.

For example, to trigger a manual backup for a site, you need the environment ID for that particular environment. To get the environment ID, you first need the site ID. This means you must make multiple API calls: one to get the site ID, another to retrieve the environment ID, and finally, a request to trigger the backup.

Step 1: Fetch all WordPress sites with Kinsta API

The first step is to retrieve a list of all the sites associated with your Kinsta account. Kinsta’s API provides an endpoint to fetch this data, which includes site IDs, names, and other relevant details. Using the GET /sites endpoint, you can pull a list of all sites under your company’s account.

Here’s an example using Node.js and 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
}

This function returns an array of all the sites in your account. Each site contains information such as the site’s ID, name, and environment(s).

Step 2: Fetch environment IDs for each WordPress site

Each site can have multiple environments (like production or staging), and backups are triggered per environment. To retrieve the environment IDs for each site, you make another API call to the GET /sites/{site_id}/environments endpoint.

Here’s an example function that fetches environments for a specific 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;
}

Step 3: Trigger backups for each environment

Once you have the environment IDs, you can trigger backups for each environment using the POST /sites/environments/{env_id}/manual-backups endpoint. The API allows you to create a manual backup by providing an environment ID and an optional tag to identify the backup.

Here’s how to trigger a backup for a given environment:

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}`);
    }
}

This function triggers a manual backup for the given environment ID. You can also tag your backup for easier identification.

Step 4: Automate backups for all sites

Now that you have functions to fetch all sites, retrieve environment IDs, and trigger backups, you can combine them to create a script that automates backups for every site in your Kinsta account.

Here’s how you can tie everything together:

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.');
}

This function loops through all the sites, retrieves their environments, and triggers backups for each environment with a timestamped tag.

Now, when you run backupAllSites(), it triggers a backup for every environment in your Kinsta account.

Slack command example

You can integrate this backup process into a Slack command for even easier management. With a Slack app setup, users can trigger backups across all sites with a single command like /backup_all_sites.

Here’s a quick example of how this could work:

app.command('/backup_all_sites', async ({ ack, say }) => {
    await ack();
    await backupAllSites();
    say('Backups for all sites have been triggered.');
});

Triggering backups for selected sites using environment IDs

In some cases, you may want to trigger backups for only specific sites or environments rather than all sites in your Kinsta account. This could be useful if you’re interested in backing up only production environments or certain high-priority sites.

Using the Kinsta API, we can automate backups for selected environments by passing an array of environment IDs. Let’s walk through how to implement this.

Step 1: Pass environment IDs

When you want to trigger backups for selected sites, you need the environment IDs for those sites. You can either hardcode these IDs, retrieve them from the Kinsta API, or pass them dynamically (like through a command-line argument, Slack command, etc.).

Here’s a function that accepts an array of environment IDs and triggers backups for each one:

async function backupSelectedEnvironments(environmentIds, tag) {
    for (const envId of environmentIds) {
        await createBackup(envId, tag);
    }
}

The function above receives an array of environment IDs that you want to back up (environmentIds). The createBackup(envId, tag) function triggers backup for each environment in the array using the createBackup() function (explained in Step 2).

Step 2: Trigger the backup

To trigger the actual backup for each environment, use the Kinsta API’s POST /sites/environments/{env_id}/manual-backups endpoint as we did for all sites. Here’s how it works:

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}`);
    }
}

Step 3: Execute backups for selected environments

Now that we have functions to trigger backups and handle multiple environments, we can combine them to back up specific environments. This example assumes we already have the environment IDs that we want to back up.

const selectedEnvironments = ['12345', '67890']; // Replace with actual environment IDs
backupSelectedEnvironments(selectedEnvironments, 'Manual Backup');

In this case:

• The selectedEnvironments array contains the environment IDs you want to back up.
• The backupSelectedEnvironments() function loops through each ID and triggers the backup with the tag ‘Manual Backup’.

Slack command example

If you’re using a Slack app or command-line interface, you can also allow users to specify which environments to back up.

Here’s how you might implement this in a 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}.`);
});

The user inputs a command like /backup_selected_envs Backup-Tag 12345 67890, where Backup-Tag is the tag, and 12345, 67890 are the environment IDs.

The command’s text is split, and the environment IDs are passed to the backupSelectedEnvironments() function.

After triggering the backups, the app responds to the user confirming the backup.