# Getting Started Get started with Cloudback - your guide to automated backups and restores across all supported platforms. Welcome to Cloudback! Cloudback provides secure, automated backups for your repositories and workspaces across all supported platforms. ![Cloudback Supported Platforms](/files/CwQCX8Wni76laUHiSvAi) ## Choose Your Platform * [**GitHub**](/github): Backup GitHub repositories with metadata support * [**Azure DevOps**](/azure-devops): Backup Azure DevOps repositories with pull requests metadata * [**GitLab**](/gitlab): Backup GitLab projects with repository content and metadata * [**Linear**](/linear): Backup Linear workspaces including issues, projects, documents, and more ## Quick Links * [What is Cloudback?](/what-is-cloudback) - Learn about Cloudback's features * [GitHub Installation Guide](/github/installation-guide) - Get started with GitHub backups * [Azure DevOps Installation Guide](/azure-devops/installation-guide) - Get started with Azure DevOps backups * [GitLab Installation Guide](/gitlab/installation-guide) - Get started with GitLab backups * [Linear Installation Guide](/linear/installation-guide) - Get started with Linear backups # What is Cloudback? Secure, automated backup solution for GitHub, Azure DevOps, GitLab, and Linear with enterprise-grade security, metadata protection, and flexible storage options. Cloudback is a reliable SaaS solution that automatically safeguards your GitHub, Azure DevOps, GitLab, and Linear data. Whether you're an individual developer, a collaborative team, or a large organization, Cloudback ensures your code, project history, and important metadata are securely backed up and easily recoverable. ![Cloudback Dashboard](/files/x2t8FvQf7OFpSpf7W7uw) ## Core Functionality Cloudback integrates with your development platforms, providing automated, secure backups that go beyond basic repository cloning. This includes backups of repository content, project metadata, and workspace data. ### Supported Platforms * **GitHub**: Full support for GitHub.com repositories, including personal accounts, organizations, and GitHub Enterprise Cloud. Available through [GitHub Marketplace](https://github.com/marketplace/cloudback). * **Azure DevOps**: Full support for Azure DevOps repositories, available through the [Microsoft Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/myrtlelabs-sas.cloudback). * **GitLab**: Full support for GitLab.com projects, including personal namespaces and groups. Repository clone, project settings, issues, merge requests, notes, labels, milestones, boards, and members. * **Linear**: Teams, projects, issues, comments, cycles, documents, initiatives, templates, labels, custom views, and embedded files. ## Key Features ### Automated Backups Cloudback runs backups automatically without any manual work. You set the schedule, storage location, and how long to keep backups - Cloudback handles the rest. By default, backups run daily and are kept for 30 days, but you can change these settings anytime. You can also adjust the time zone to match when your team works. ### Repository protection Backups go beyond just code. Cloudback saves a snapshot of your project including key data: * **GitHub**: Issues, pull requests, wiki pages, releases, labels, milestones, collaborators, webhooks, and more. * **Azure DevOps**: Repositories, pull requests with comments and attachments, branches, refs, and commits. * **GitLab**: Repository clone, project settings, issues, merge requests, notes, labels, milestones, boards, and members. * **Linear**: Teams, projects, issues, comments, cycles, documents, initiatives, templates, labels, custom views, and embedded files. ### Fast Restore Restore your data quickly when something goes wrong. Use the restore wizard to pick which backup to restore and where to put it. You can restore to the same repository or create a new one. Need to restore many repositories at once? The bulk restore feature lets you recover multiple items in just a few clicks. Cloudback also supports cross-platform restore between GitHub and GitLab, enabling smooth platform migration. ### Enterprise-Grade Security Every backup is stored as a ZIP archive with AES-256 encryption - the same standard used by governments and military. Each archive gets a unique password that Cloudback manages for you. Even if someone gains access to your storage, they cannot read the backup contents without the password. Cloudback is SOC 2 Type II compliant and uses official APIs verified by GitHub and Microsoft. Compliance monitoring is streamlined through the [Vanta integration](/security-and-compliance/vanta-integration). ### Flexible Storage Choose where your backups are stored. Use Cloudback's built-in storage in different regions (US, EU, UK, Sydney, Singapore) or connect your own storage from AWS S3, Microsoft Azure, Google Cloud, OneDrive, Wasabi, Alibaba Cloud, or OpenStack Swift. You can also set up composite storage to save backups to multiple locations at once for extra safety. ### Customizable Backup Schedules Create backup schedules that fit how your team works. Besides daily backups, you can set up weekly, monthly, or custom schedules using simple options for specific hours, days, or months. Apply the same schedule to many repositories at once using bulk operations. ### Efficient Storage Utilization Save storage space and reduce costs with data deduplication. Cloudback compares each new backup with the previous one. If nothing changed in your repository, Cloudback keeps a link to the existing backup instead of uploading a duplicate. You can see how much space you saved in the deduplication statistics on each repository page. ## Who is Cloudback For? Cloudback is an automated backup solution designed for businesses that need reliable data protection and compliance with industry standards like SOC 2. It is ideal for: * **Organizations Requiring SOC 2 Compliance**: Businesses that need to meet SOC 2 Type II security and privacy standards. * **Developers and Development Teams**: Those looking for secure, automated backups for their data. * **Small to Medium-Sized Businesses (SMBs)**: Companies needing a simple and compliant backup solution. * **Enterprises**: Large organizations requiring scalable and secure cloud storage backups. ## Learn More Get started with your platform: * **GitHub**: [Installation Guide](/github/installation-guide) | [First Backup Walkthrough](/github/first-backup-walkthrough) | [Backup Contents](/github/backup-contents) | [Pricing](/github/pricing) * **Azure DevOps**: [Installation Guide](/azure-devops/installation-guide) | [First Backup Walkthrough](/azure-devops/first-backup-walkthrough) | [Backup Contents](/azure-devops/backup-contents) | [Pricing](/azure-devops/pricing) * **GitLab**: [Installation Guide](/gitlab/installation-guide) | [First Backup Walkthrough](/gitlab/first-backup-walkthrough) | [Backup Contents](/gitlab/backup-contents) | [Pricing](/gitlab/pricing) * **Linear**: [Installation Guide](/linear/installation-guide) | [First Backup Walkthrough](/linear/first-backup-walkthrough) | [Backup Contents](/linear/backup-contents) | [Pricing](/linear/pricing) Explore Cloudback's features: * [Automated Daily Backups](/managing-backups/automated-daily-backups) * [On-Demand Manual Backups](/managing-backups/one-click-manual-backups) * [Custom Backup Schedules](/managing-backups/setting-backup-schedules) * [Storage Configuration](/managing-backups/manage-backup-storage) * [Data Deduplication](/managing-backups/data-deduplication) # GitHub Cloudback for GitHub - setup, backup contents, restore, and pricing for GitHub repository backups. Cloudback provides secure, automated backups for your GitHub repositories. Whether you're using a personal account or managing organization repositories, Cloudback ensures your code, project history, and important metadata are protected. ## Getting Started * [Installation Guide](/github/installation-guide) - Step-by-step guide to setting up Cloudback for GitHub * [First Backup Walkthrough](/github/first-backup-walkthrough) - Learn how to monitor and manage your first backup * [Restore](/github/restore) - How to restore GitHub data from a backup, including cross-account restore ## Key Features for GitHub * **Metadata backups**: Issues, pull requests, wikis, releases, labels, milestones, and more * **GitHub Marketplace Integration**: Purchase and manage your subscription directly through GitHub * **Organization Support**: Protect all repositories across your GitHub organizations * **GitHub-Verified Application**: Cloudback uses official GitHub APIs and is a verified GitHub application ## What Gets Backed Up Cloudback backs up your GitHub repositories, including repository content, issues, pull requests, wikis, releases, and associated metadata. For a complete list of what's included, see [GitHub Backup Contents](/github/backup-contents). ## Pricing GitHub backups use a per-repository pricing model - each repository consumes 1 unit. See [GitHub Pricing](/github/pricing) for plans and details. # Installation Guide Step-by-step guide to installing and configuring Cloudback for GitHub repository backups, including plan selection, payment options, and initial setup. Cloudback provides secure, automated backups for your GitHub repositories. This guide will walk you through the process of setting up Cloudback for your GitHub account(s). ## Overview of the Setup Process To start backing up your repositories with Cloudback, you'll need to complete the following steps: 1. **Choose a Plan**: * Select a plan that covers the number of repositories you want to back up. This determines your backup capacity. You can find the full list of plans below. 2. **Purchase a Plan**: * Choose your preferred payment method and complete the purchase process. * Cloudback offers several payment options, including GitHub Marketplace, credit card, or bank transfer. 3. **Install the Cloudback GitHub Application**: * Grant Cloudback access to your repositories by installing our GitHub Application. This step is crucial for allowing Cloudback to read and backup your repository data. 4. **Verify configuration**: * While Cloudback works out of the box with default configuration, you can customize various aspects of your backup process if required. Now, let's go through each step in detail: ## 1. Choose Your Plan Cloudback offers several plans to suit your backup needs. Choose the plan that best fits the number of repositories you want to protect. Here are the available options: * **Free Plan**: * Backup one repository to the cloud * Price: $0 * **Per 10 repositories monthly plan**: * Price: $10 per 10 repositories/month * Free trial available * **Per 100 repositories monthly plan**: * Price: $75 per 100 repositories/month * Free trial available * **Per 1000 repositories monthly plan**: * Price: $500 per 1000 repositories/month * Free trial available You can purchase **multiple units** of each plan to increase coverage. For example, buy 2 units of the 10-repository plan to cover 20 repositories. Cloudback offers fair pricing based on the number of repositories, not team size. This applies to both personal and organization accounts. Cloudback allows you to protect **multiple** GitHub accounts with a single plan. This feature is useful for those who manage several GitHub accounts. For example, you can use a single 100-repository plan to cover three separate accounts with 20, 30, and 50 repositories respectively. You can assign multiple accounts to a single subscription directly from the [Subscriptions](https://github.com/cloudback/docs-internal/blob/docs/account-and-billing-management/subscription-management.md) page in the Cloudback Dashboard. ## 2. Purchase a Plan The recommended way to purchase Cloudback for GitHub is through the [GitHub Marketplace](https://github.com/marketplace/cloudback): 1. Select your preferred plan on the [Cloudback page](https://github.com/marketplace/cloudback) 2. Follow GitHub instructions to complete the purchase 3. Cloudback will automatically activate for the selected account For alternative payment methods (credit card, bank transfer, Coupa), see [Payment Methods](https://github.com/cloudback/docs-internal/blob/docs/account-and-billing-management/payment-methods.md). ## 3. Install the Cloudback Application ### Initial Installation **Note:** If you purchased a plan through the GitHub Marketplace, the Cloudback Application is already installed, so you can skip this step. To start backing up your repositories, you'll need to install the Cloudback Application for each GitHub account you wish to protect. Follow these steps: 1. **Visit** the [Cloudback Dashboard](https://app.cloudback.it). 2. **Sign in** with your GitHub account. * Authorize Cloudback to access your GitHub account when prompted. 3. **Review and accept** the Terms of Service and Privacy Policy. 4. **Click the "Install" button** on the dashboard to install the Cloudback Application on your GitHub account. During installation, you will be prompted to grant repository access. You have two options: * **Grant access to all repositories** (recommended for convenience). * **Select specific repositories** to grant access to. ### Managing GitHub Installations You can manage your GitHub installations at any time from the Cloudback Dashboard: 1. Click on your profile icon in the top-right corner. 2. Select **"Manage GitHub Installations"** from the dropdown menu. * Alternatively, you can directly access the [Manage GitHub Installations](https://github.com/apps/cloudback/installations/select_target) page. **Note for Free Plan Users:** Even if you grant access to all repositories, you will only be able to back up one repository under the free plan. ### Things to Consider * **Separate Installations for Multiple Accounts**: Install the Cloudback Application separately for each GitHub account you wish to protect. * **Multi-Account Protection**: To protect multiple accounts under a single plan, assign them to the same subscription from the [Subscriptions](https://github.com/cloudback/docs-internal/blob/docs/account-and-billing-management/subscription-management.md) page. Remember, you still need to install the app on each account individually. * **Security and Permissions**: * Cloudback uses the official GitHub API and is a GitHub-verified application. * Cloudback uses two separate GitHub Apps: a **backup app** with read-only permissions (installed during setup) and a **restore app** with write permissions (installed separately only when you need to restore). This follows the principle of least privilege. * **Installation vs. Plan Coverage**: Installing the application grants Cloudback access to your repositories based on the permissions you set. However, your chosen plan determines how many repositories you can actually back up. ## 4. Verify Configuration After installation, you'll be redirected to the Cloudback Dashboard, where you can verify and adjust your configuration settings. Cloudback applies sensible defaults (daily backups, managed storage, 30-day retention). You can customize all settings from the [Account Settings](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/account-settings.md) page. Automatic daily backups are enabled for the number of repositories covered by your selected plan. You can configure the repository name pattern to choose which new repositories are backed up automatically. ## Setup Complete Congratulations! Cloudback has been successfully installed and configured for your GitHub repositories. Here's what you can expect next: * **Backup Schedule**: Your first backups will commence according to the schedule you've set. * **Dashboard Access**: Access your Cloudback Dashboard anytime at using your GitHub account. * **Service Status**: If you experience any issues accessing the website, please check our status page at for updates on maintenance or service interruptions. * **Support**: If you have any questions or need assistance, don't hesitate to [contact support](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/contact-us.md). ### IP Address Whitelisting for Enterprise Organizations If your GitHub organization uses IP address restrictions or allowlists to control access to repositories, you'll need to add Cloudback's IP addresses to ensure uninterrupted backup operations. This is particularly common with GitHub Enterprise Cloud installations that implement network-level security policies. For detailed instructions and the list of IP addresses to whitelist, see [IP Address Whitelist](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/ip-whitelist.md). ## Learn More To get the most out of Cloudback, explore these resources: * [Automated Daily Backups](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/automated-daily-backups.md) * [On-Demand Manual Backups](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/one-click-manual-backups.md) * [Storage Configuration](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/manage-backup-storage.md) * [GitHub Backup Contents](/github/backup-contents) * [Backup Retention Policy](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/backup-retention-policy.md) * [Known Issues](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/known-issues.md) * [IP Address Whitelist](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/ip-whitelist.md) - For organizations using IP allowlists Need help? [Contact support](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/contact-us.md). # First Backup Walkthrough Learn how to monitor and manage your first GitHub repository backup with Cloudback, including dashboard navigation, automated backups, and manual backup options. ## Introduction Welcome to Cloudback! This guide will walk you through understanding your first backup process. Cloudback is designed to automatically protect your GitHub repositories, so you will find that most of the work is already done after the installation process is complete. This guide covers how to monitor these automated backups and make any customizations you might need. ## Cloudback Dashboard Cloudback provides a user-friendly dashboard to manage your backups, whether you have a single repository or multiple repositories across different organizations. ## Automated Backups Cloudback automatically backs up your repositories to the cloud. After installing Cloudback, backups start automatically with sensible defaults: daily schedule, Cloudback Managed Storage, and 30-day retention. You can customize these settings anytime in [Account Settings](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/account-settings.md). ## Your First Automated Backup Your first backup will occur within 24 hours of setup. Check the **Backup** and **Last Run** columns on your dashboard to monitor progress. For details about the dashboard layout and columns, see [Dashboard Overview](https://github.com/cloudback/docs-internal/blob/docs/dashboard/dashboard-overview.md). ## Performing a Manual Backup While automated backups cover most needs, you might want to run a manual backup before a major change. Here is how: 1. From your dashboard, find the repository you want to back up. 2. Check the checkbox in the first column next to the repository. 3. When items are selected, action buttons appear in the toolbar: **Trigger**, **Restore**, and **Edit**. Additional buttons like **Reset** (to clear selections and filters) and **Export CSV** are also available. 4. Click the **Trigger** button to start the backup immediately. 5. A confirmation dialog will show the backup progress. You can also select multiple repositories and click **Trigger** to back them all up at once. ## Accessing Your Backed-Up Data Cloudback stores your backups in a secure cloud storage. You can access your backups at any time and restore them to your GitHub repositories. You can learn more about downloading backups in the [Download Backups](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/download-backups.md) page. To restore a backup to your GitHub repository, follow the steps in the [Restoring a Backup](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/restoring-a-backup.md) page. ## Learn More * [GitHub Backup Contents](/github/backup-contents) * [Account Settings](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/account-settings.md) * [Restoring a Backup](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/restoring-a-backup.md) Need help? [Contact support](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/contact-us.md). # Backup Contents Detailed overview of what's included in Cloudback backups for GitHub repositories, including issues, pull requests, labels, and API-related limitations. Cloudback backs up your GitHub repositories, including both the code and important metadata such as issues, pull requests, milestones, and other data. This document explains what is included in a GitHub backup and what is not. You can learn how to view the details of a backup on the [Backup Details](/dashboard/backup-details) page. ## What is Included in a Backup? Here is the list of repository's data in a backup archive: * A [bare clone](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---bare) of a git repository (equivalent to `git clone --bare`, which includes all branches, tags, and refs) * A clone of a [Wiki](https://docs.github.com/en/communities/documenting-your-project-with-wikis/about-wikis) repository * All [Git LFS objects](https://docs.github.com/en/repositories/working-with-files/managing-large-files/about-git-large-file-storage) * All [Topics](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics) * All [Milestones](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones) * All custom [Labels](https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels) (GitHub's default labels like `bug`, `enhancement`, `documentation` are excluded since they are automatically created with new repositories) * All [Issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/about-issues) and Issue Comments * All [Sub-Issues](https://github.blog/changelog/2025-01-13-evolving-github-issues-public-preview/#break-down-and-nest-issues-with-sub-issues) * All [Issue Types](https://github.blog/changelog/2025-01-13-evolving-github-issues-public-preview/#organize-your-work-with-issue-types) (organization accounts only) * All [Repository Projects](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects) (ProjectV2), including: * Project fields (custom fields, iterations, single-select options) * Project items (issues, draft issues, field values) * Project views (layout, filters, sort, grouping) * Project workflows (automation rules) * Project status updates (health, dates, body) * All [Commit Comments](https://github.blog/2008-04-10-commit-comments/) * All [Releases](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases) including release asset binary files * Repository Metadata (description, settings, merge configuration, visibility, license) * All [Collaborators](https://docs.github.com/en/rest/collaborators/collaborators) * All [Webhooks](https://docs.github.com/en/rest/webhooks/repo-webhooks) * Except [secret tokens](https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries#setting-your-secret-token). Secret tokens must be set manually after restore * All [Pull Requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests), including: * Pull request reviews (approvals, change requests, comments) * Review comments (inline code comments with diff context) You can view the contents of a backup archive by downloading it and extracting the contents. Please note that for [password-protected archives](/security-and-compliance/password-protected-archives), you will need to enter the password to extract the contents. Metadata is stored as JSON files (one per data type) in the same format downloaded from the GitHub API. For example, the files containing issues, milestones, and labels are named `issues.json`, `milestones.json`, `labels.json` respectively: ![ZIP archive content](/files/MX5kUbeXpbMkS462LUxu) If you want Cloudback to add any additional metadata into a backup, please [contact support](/troubleshooting-and-support/contact-us) or just [create a feature request](https://github.com/cloudback/issue-tracker/issues/new?template=feature_request.md) and the team will consider implementing it. ## Metadata that is Not Included However, Cloudback's ability to back up metadata is constrained by either the limitations of the GitHub API or features not yet implemented in Cloudback. Key points to remember: * Your GitHub Account is not included in the backup. * Your GitHub Organization is not backed up either. * The backup provided should not be regarded as complete or all-inclusive. Please report it if there is a mistake or the API is changed - the team will fix it as soon as possible. Here is the list of metadata that is not included in a backup: ### Not yet implemented * [Deploy Keys](https://docs.github.com/en/rest/deploy-keys/deploy-keys): Not included in backup yet * [Autolinks](https://docs.github.com/en/rest/repos/autolinks): Not included in backup yet ### GitHub API restrictions * [Environments](https://docs.github.com/en/rest/deployments/environments): There is no [API](https://docs.github.com/en/rest/actions/secrets#get-an-environment-secret) to get environment variable value * [Encrypted secrets](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets): There is no [API](https://docs.github.com/en/rest/actions/secrets#get-a-repository-secret) to get an encrypted value * [Forks](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/about-forks): There is no API * [Watchers](https://docs.github.com/en/subscriptions-and-notifications/concepts/about-notifications): There is no API * [Stargazers](https://docs.github.com/en/rest/activity/starring): There is no API * [Commit Statuses](https://docs.github.com/en/rest/commits/statuses): There is an API, but it doesn't allow to explore all statuses for a whole repository * [Deployments](https://docs.github.com/en/rest/deployments/deployments): There is no API to restore completed deployments * [Pull Requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) without commits: backed up, but cannot be restored - GitHub API rejects PR creation with `No commits between feature-branch and main-branch` * [Pull Requests](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) from forks: backed up, but cannot be restored - the source branch is in the fork of the original repository, and there is no API to create a PR from an old fork into a newly created repository * [Discussions](https://docs.github.com/en/graphql/guides/using-the-graphql-api-for-discussions): There is no API to restore discussion categories * [Personal ProjectV2](https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/using-the-api-to-manage-projects#authentication): No access to personal projects using GitHub Apps. Only organization and repository projects are accessible. ## Learn More * [Azure DevOps Backup Contents](/azure-devops/backup-contents) - Compare with Azure DevOps backup contents * [Backup Details](/dashboard/backup-details) * [Password-Protected Archives](/security-and-compliance/password-protected-archives) * [Repository Details](/dashboard/repository-details) # Restore Learn how to restore GitHub repository backups using Cloudback, including the restore application, cross-account restore, source restrictions, and what gets restored. Cloudback can restore your GitHub repository data from any backup archive. This includes the full Git repository, issues, pull requests, releases, labels, milestones, projects, and more. You can restore to the same account, a different account, or even from a non-GitHub backup (GitLab) via [Cross-Platform Restore](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/cross-platform-restore.md). ## Overview Restoring a GitHub repository involves: 1. **Installing** the Cloudback Restore Application (separate from the backup app) 2. **Selecting** the target account and repository name 3. **Executing** the restore - Cloudback creates the repository, pushes the code, and restores all metadata ## Prerequisites * A successful backup archive (from GitHub or GitLab) * A **target GitHub account** (personal or organization) to restore into * The [Cloudback Restore Application](https://github.com/apps/cloudback-restore) installed on the target account ## Restore Application Cloudback uses two separate GitHub Apps following the principle of least privilege: * **Backup App** (read-only) - installed during setup, used for daily backups * **Restore App** (read-write) - installed separately, only when you need to restore ### Installing the Restore Application 1. Go to the [Cloudback Restore Application](https://github.com/apps/cloudback-restore/installations/select_target) installation page. 2. Select the target GitHub account (organization or user). 3. Grant the requested permissions - read and write access to code and metadata. > **Security Tip:** The Restore Application is only needed for the duration of the restore. Consider uninstalling it from your target account once the restore is complete. ## Step-by-Step Restore Process ### Step 1: Initiate Restore 1. Navigate to your repository in the Cloudback dashboard 2. Open the **Backups** tab and find the backup you want to restore 3. Click the **Restore** button Alternatively, select one or more repositories on the dashboard and click **Restore** in the toolbar to start a [Bulk Restore](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/bulk-restore.md). ### Step 2: Select Target 1. Enter the target GitHub account name (personal or organization) 2. Click **Start Restore** The repository name and visibility are carried over from the backup automatically. ### Step 3: Execute Restore Click **Restore** to begin. The process runs in the background - you can close the page and return later. A notification will appear when the restore completes. ## What Gets Restored | Entity | Details | | ----------------------- | -------------------------------------------------------------------------------------------------------------------- | | **Repository** | All branches, tags, refs via `git push --mirror`, plus LFS objects | | **Issues** | Title, body, state, labels, milestone, assignee, issue types, sub-issues | | **Issue Comments** | Body, author, dates | | **Pull Requests** | Unmerged PRs with title, body, state, labels, milestone, branches, reviews, review comments, and requested reviewers | | **Commit Comments** | Comments on specific commits | | **Milestones** | Title, description, state, due date | | **Labels** | Name, color, description | | **Releases** | Tag, name, body, assets (uploaded files) | | **Projects** | ProjectV2 in current backups; classic projects from older archives | | **Collaborators** | Repository collaborator invitations | | **Webhooks** | Webhook URLs and configuration | | **Repository Settings** | Description, homepage, merge methods, topics | ### Not Restored * **Merged pull requests** - skipped during restore (the commits are already in the repository history) * **Wiki pages** - not restored * **GitHub Actions workflows** - restored as files in the repository, but workflow run history is not restored ## Cross-Account Restore You can restore backups to a **different** GitHub account than the one that created the backup. This is useful for: * Migrating repositories between organizations * Disaster recovery to a standby account * Restoring data to an account that doesn't have Cloudback installed * Restoring between GitHub Enterprise Managed User (EMU) and non-EMU accounts The process is the same as a standard restore - just select a different target account in Step 2. The Restore Application must be installed on the **target** account. ### Restricting Allowed Source Accounts (Optional) By default, Cloudback allows restores from any source account. To restrict which source accounts can restore to your organization, create a GitHub Actions organization variable: 1. Navigate to the GitHub settings for your **target organization** 2. Go to **Security > Secrets and variables > Actions** 3. Click the **Variables** tab → **New organization variable** 4. Enter: * **Name**: `CLOUDBACK_ALLOWED_RESTORE_SOURCE` * **Value**: Source account name(s), each prefixed with the platform. Separate multiple entries with commas. * *GitHub source:* `github:source-org-1` * *GitLab source:* `gitlab:source-group-1` * *Mixed example:* `github:source-org-1,gitlab:source-group-2` * **Repository access**: Can be left as "Public repositories" 5. Click **Add variable** > **Note:** This variable is only checked for **organization** targets. Personal account targets skip this check. Organization **owners** also bypass this check - they can restore from any source without setting the variable. ## Learn More * [Restoring a Backup](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/restoring-a-backup.md) - General restore documentation * [Bulk Restore](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/bulk-restore.md) - Restoring multiple repositories at once * [Cross-Platform Restore](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/cross-platform-restore.md) - GitHub ↔ GitLab bidirectional restore * [GitHub Backup Contents](/github/backup-contents) - What data is in each backup * [Known Issues](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/known-issues.md) - Troubleshooting restore errors # Pricing How Cloudback pricing works for GitHub repositories, including unit costs, what's included in backups, and where to subscribe. Cloudback uses a **per-repository pricing model** for GitHub. You pay based on the number of repositories you protect, not the number of users or seats in your organization. ## How Units Work for GitHub Each GitHub repository with backups enabled consumes **1 unit** from your subscription pool. | What You Protect | Units Consumed | | ----------------------- | -------------- | | 1 GitHub repository | 1 unit | | 10 GitHub repositories | 10 units | | 100 GitHub repositories | 100 units | Units are shared across all connected accounts and platforms. For full plan details, pricing tables, and billing cycle options, see [Pricing](/account-and-billing-management/pricing). ## What's Included Every GitHub backup includes the full repository plus metadata: * Git repository (bare clone with all branches, tags, and refs) * Git LFS objects * Issues (including sub-issues and issue types) * Pull requests * Wiki pages * Releases and release assets * Labels, milestones, and topics * Projects V2 * Commit comments * Collaborators * Webhooks (excluding secrets) For a complete breakdown, see [GitHub Backup Contents](/github/backup-contents). ## How to Subscribe for GitHub The recommended way to purchase Cloudback for GitHub is through the **GitHub Marketplace**: 1. Select your preferred plan on the [Cloudback page on GitHub Marketplace](https://github.com/marketplace/cloudback) 2. Follow GitHub instructions to complete the purchase 3. Cloudback will automatically activate for the selected account For alternative payment methods (credit card, bank transfer, invoice), see [Payment Methods](/account-and-billing-management/payment-methods). ## Learn More * [Pricing](/account-and-billing-management/pricing) - Full plan comparison with pricing tables * [Subscription Management](/account-and-billing-management/subscription-management) - Manage subscriptions and account assignments # Azure DevOps Cloudback for Azure DevOps - setup, backup contents, restore, and pricing for Azure DevOps repository backups. Cloudback provides secure, automated backups for your Azure DevOps repositories, ensuring your intellectual property and project history are safe from accidental deletion, corruption, or malicious attacks. ## Getting Started * [Installation Guide](/azure-devops/installation-guide) - Step-by-step guide to setting up Cloudback for Azure DevOps * [First Backup Walkthrough](/azure-devops/first-backup-walkthrough) - Learn how to monitor and manage your first backup * [Restore](/azure-devops/restore) - How to restore Azure DevOps data from a backup ## Key Features for Azure DevOps * **Automated Daily Backups**: Set it and forget it. Cloudback automatically backs up your data every day. * **Backup coverage**: Cloudback backs up repositories, repository metadata, refs, commits, branches, pull requests, and pull request metadata. * **Azure Marketplace Integration**: Available on the [Microsoft Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/myrtlelabs-sas.cloudback) for easy setup and billing. * **Flexible Restore**: Restore repositories directly to Azure DevOps or download as secure archives. ## What Gets Backed Up Cloudback backs up your Azure DevOps repositories, including repository content, pull requests, and associated metadata. For a complete list of what's included, see [Azure DevOps Backup Contents](/azure-devops/backup-contents). **Coming Soon**: Work Items, Boards, Pipelines, Artifacts, Wikis, and Test Plans. ## Pricing Azure DevOps backups use a per-repository pricing model - each repository consumes 1 unit. See [Azure DevOps Pricing](/azure-devops/pricing) for plans and details. # Installation Guide Step-by-step guide to installing and configuring Cloudback for Azure DevOps repository backups, including Azure Marketplace subscription and initial setup. Cloudback provides secure, automated backups for your Azure DevOps repositories. This guide will walk you through the process of setting up Cloudback for your Azure DevOps organization. ## Overview of the Setup Process To start backing up your Azure DevOps repositories with Cloudback, you'll need to complete the following steps: 1. **Sign Up / Log In** to Cloudback 2. **Connect** your Azure DevOps organization 3. **Purchase a Subscription** from the Azure Marketplace 4. **Verify Configuration** and start protecting your repositories Let's go through each step in detail. ## 1. Sign Up or Log In to Cloudback 1. **Visit** the [Cloudback Dashboard](https://app.cloudback.it). 2. **Sign in** with your preferred account (GitHub or Microsoft account). 3. **Review and accept** the Terms of Service and Privacy Policy if this is your first time. ## 2. Connect Your Azure DevOps Organization After signing in, you'll need to connect your Azure DevOps organization to Cloudback: 1. From left navigation menu, click on **"Add Account"** button and then click **Connect Azure DevOps**. 2. You will be redirected to Microsoft's authorization page. 3. **Sign in** with your Microsoft account that has access to the Azure DevOps organization you want to protect. 4. Review the necessary permissions to access your Azure DevOps repositories, check **Consent on behalf of your organization** and click the **Accept** button. 5. Set up the `Cloudback Azure DevOps Backup` Service Principal for your organization. 6. Click **Refresh Projects** to see the list of projects available to the Service Principal user. Note that it may take a few minutes for the Service Principal to be added in Azure DevOps organization. 7. Once you see all the projects you want to back up, click **Add Projects**. You will be redirected to Cloudback Dashboard. > **Security Note**: Cloudback uses read-only permissions for backup operations. Write permissions are only requested in a separate application when performing restore operations. ## 3. Purchase a Subscription from Azure Marketplace Cloudback is available on the Microsoft Azure Marketplace, making setup and billing simple for Azure DevOps teams. ### Benefits of Azure Marketplace Subscription * Add Cloudback directly from your Azure account * Use your existing Azure billing setup * Consolidate Cloudback costs into your standard Azure billing cycle * Simplify procurement and subscription management ### How to Subscribe 1. Visit the [Cloudback listing on Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/myrtlelabs-sas.cloudback?tab=Overview). 2. Click **"Get it now"**. 3. Choose your preferred plan based on the number of repositories you want to protect. 4. Select your Azure subscription and resource group, insert a SaaS subscription name. 5. Complete the purchase process by clicking **Subscribe** button. 6. Wait for Azure to configure your subscription, then click **Configure Account now** button. 7. You will be redirected to the Cloudback dashboard, where you will see the confirmation message: "Your Azure subscription has been successfully activated" ### Available Plans * **Per 10 repositories monthly plan**: $10 per 10 repositories/month * **Per 100 repositories monthly plan**: $75 per 100 repositories/month * **Per 1000 repositories monthly plan**: $500 per 1000 repositories/month You can purchase multiple units of each plan to increase coverage. For alternative payment methods (credit card, bank transfer), see [Payment Methods](https://github.com/cloudback/docs-internal/blob/docs/account-and-billing-management/payment-methods.md). ## 4. Verify Configuration After connecting your organization and purchasing a subscription, you can verify your configuration: 1. Open the [Cloudback Dashboard](https://app.cloudback.it). 2. Navigate to your Azure DevOps dashboard. 3. You should see your repositories listed and ready for backup: Cloudback applies sensible defaults (daily backups, managed storage, 30-day retention). You can customize all settings from the [Account Settings](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/account-settings.md) page. ## Setup Complete Congratulations! Cloudback is now configured to protect your Azure DevOps repositories. Here's what to expect: * **First Backup**: Your first backup will run within 24 hours according to your schedule. * **Dashboard Access**: Monitor all your backups at . * **Service Status**: Check for any service updates. ### What Gets Backed Up Cloudback backs up your Azure DevOps repositories, including repository content, pull requests, and associated metadata. For details, see [Azure DevOps Backup Contents](/azure-devops/backup-contents). ## Learn More * [First Backup Walkthrough](/azure-devops/first-backup-walkthrough) - Monitor your first backup * [Azure DevOps Backup Contents](/azure-devops/backup-contents) - What's included in backups * [Restoring a Backup](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/restoring-a-backup.md) - How to restore backups Need help? [Contact support](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/contact-us.md). # First Backup Walkthrough Learn how to monitor and manage your first Azure DevOps repository backup with Cloudback, including dashboard navigation, automated backups, and manual backup options. ## Introduction Welcome to Cloudback for Azure DevOps! This guide will walk you through understanding your first backup process. Cloudback is designed to automatically protect your Azure DevOps repositories, so most of the work is already done after the setup process. This guide covers how to monitor these automated backups and make any customizations you might need. ## Cloudback Dashboard Cloudback provides a unified dashboard to manage backups across all your connected platforms, including Azure DevOps. To access your Cloudback dashboard: 1. Go to [app.cloudback.it](https://app.cloudback.it) 2. Log in with your account 3. Navigate to the Azure DevOps dashboard Once logged in, you'll see all your connected organizations and repositories. Each row in the table represents a repository with the following columns: * **Account**: The Azure DevOps organization name * **Name**: The project or repository name (format: `project/repository` for repositories) * **Type**: Indicates whether this is a "Project" or "Repository" backup * **Status**: Badge showing "Scheduled", "Not scheduled", "Restore only", or "Not accessible" * **Schedule**: The backup schedule name (e.g., "Daily at 9 pm") * **Storage**: Where backups are stored * **Retention**: How long backups are kept * **Backup**: Status of the last backup attempt (e.g., "Succeeded", "Failed", "In Progress") * **Last Run**: Time since the last successful backup (e.g., "2 hours ago") or "-" if no backup has run yet To find a specific repository, use the search bar in the top toolbar or click the filter icon to filter by various criteria. ## Automated Backups Cloudback automatically backs up your repositories to the cloud. After installing Cloudback, backups start automatically with sensible defaults: daily schedule, Cloudback Managed Storage, and 30-day retention. You can customize these settings anytime in [Account Settings](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/account-settings.md). ## Your First Automated Backup Your first backup will occur within 24 hours of setup. Check the **Backup** and **Last Run** columns on your dashboard to monitor progress. ## Performing a Manual Backup While automated backups cover most needs, you might want to run a manual backup before a major change. Here's how: 1. From your dashboard, find the repository you want to back up. 2. Check the checkbox in the first column next to the repository. 3. When items are selected, action buttons appear in the toolbar: **Trigger**, **Restore**, and **Edit**. 4. Click the **Trigger** button to start the backup immediately. 5. A confirmation dialog will show the backup progress. You can also select multiple repositories and click **Trigger** to back them all up at once. ## Accessing Your Backed-Up Data Cloudback stores your backups in a secure cloud storage. You can access your backups at any time and restore them to your Azure DevOps repositories. You can learn more about downloading backups in the [Download Backups](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/download-backups.md) page. To restore a backup to your Azure DevOps repository, follow the steps in the [Restoring a Backup](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/restoring-a-backup.md) page. ## Learn More * [Azure DevOps Backup Contents](/azure-devops/backup-contents) * [Account Settings](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/account-settings.md) * [Restoring a Backup](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/restoring-a-backup.md) Need help? [Contact support](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/contact-us.md). # Backup Contents Detailed overview of what's included in Cloudback backups for Azure DevOps repositories, including pull requests, comments, and attachments. Cloudback backs up your Azure DevOps repositories, including both the code and important metadata. This document explains what is included in an Azure DevOps backup and what is planned for future releases. You can learn how to view the details of a backup on the [Backup Details](/dashboard/backup-details) page. ## What is Included in a Backup? Here is the complete list of data included in an Azure DevOps backup archive: ### Repository Content * **Bare Git Clone**: A complete [bare clone](https://git-scm.com/docs/git-clone#Documentation/git-clone.txt---bare) of the repository including: * All branches * All tags * Complete commit history * All refs * **Git LFS Objects**: All [Git Large File Storage](https://git-lfs.com/) objects are backed up via `git lfs fetch --all` after the repository clone ### Pull Request Data Cloudback backs up detailed pull request information: * **Pull Request Details**: * Pull request ID and code review ID * Title and description * Status (active, abandoned, completed) * Source and target branches * Merge status * Draft status * Creation and completion dates * Created by and closed by user information * Completion options (merge strategy, delete source branch, squash merge, bypass policy) * **Pull Request Commits**: * Commit IDs and URLs (references to commits included in the PR) * Full commit content (messages, authors) is preserved in the bare Git clone * **Pull Request Reviewers**: * Reviewer identities * Vote status (approved, approved with suggestions, no response, waiting for author, rejected) * Required reviewer flags * **Pull Request Threads and Comments**: * All comment threads * Individual comments with content * Comment authors * Thread status (active, fixed, won't fix, closed, by design, pending) * Thread context (code location information) * Comment timestamps * Users who liked comments * **Pull Request Labels**: * Label names * Label IDs * Active status * **Pull Request Attachments**: * Attachment files (downloaded and stored in the archive) * Attachment metadata (name, description, content hash) * Uploader information * Upload timestamps * **Work Item References**: * Links to associated work items (work item content not yet backed up) ### Backup Archive Structure When you download a backup, the archive contains the following structure: ``` backup-archive/ ├── backup.json # Archive metadata (version, subject type, repository name) ├── pull-requests.json # All pull request data with threads, labels, reviewers ├── repo/ │ └── {repository-name}.git/ # Bare Git repository │ ├── objects/ # Git objects │ ├── refs/ # Branch and tag references │ ├── config # Git configuration │ └── ... └── pr-{pullRequestId}-attachments/ # Attachment files for each PR ├── {attachmentId}_{filename} └── ... ``` ### Backup Metadata Each backup records the following counts for quick reference: | Metadata | Description | | ---------------------------------- | -------------------------------------- | | Number of Pull Requests | Total count of pull requests backed up | | Number of Pull Request Attachments | Total attachments across all PRs | | Number of Pull Request Labels | Distinct labels used | | Number of Pull Request Threads | Total comment threads | ## Viewing Backup Contents You can view the contents of a backup archive by downloading it and extracting the contents. > **Note**: For [password-protected archives](/security-and-compliance/password-protected-archives), you will need to enter the password to extract the contents. Pull request data is stored in JSON format in `pull-requests.json`. The file contains an array of pull request objects with all associated metadata including threads, comments, labels, and reviewer information. ## Learn More * [GitHub Backup Contents](/github/backup-contents) - Compare with GitHub backup contents * [Backup Details](/dashboard/backup-details) - View backup details in the dashboard * [Password-Protected Archives](/security-and-compliance/password-protected-archives) * [Download Backups](/data-restoration/download-backups) * [Restoring a Backup](/data-restoration/restoring-a-backup) # Restore Learn how to restore Azure DevOps repository backups using Cloudback, including the authorization flow and what gets restored. Cloudback can restore your Azure DevOps repository data from any backup archive. This includes the full Git repository, pull requests with review threads and comments, labels, and attachments. For the general restore workflow (how to initiate a restore, select a target, and monitor progress), see [Restoring a Backup](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/restoring-a-backup.md). ## Restore Authorization Cloudback uses a separate OAuth application for restore operations, following the principle of least privilege: * **Backup** uses read-only access to clone repositories and download metadata * **Restore** uses read-write access to create repositories and push data If this is your first time restoring, you will be prompted to authorize on the Microsoft consent page. Write access is only granted when you explicitly initiate a restore. ## Target Selection * Select the target **organization** and **project** * Enter the new **repository name** * A new repository is always created - you cannot restore to an existing repository ## What Gets Restored | Entity | Details | | ------------------- | ----------------------------------------------------------------------------------------------------- | | **Repository** | All branches, tags, and refs via `git push --mirror` | | **Pull Requests** | Source branch, target branch, title, description | | **Review Threads** | Status (active, fixed, won't fix, closed, by design, pending), file context (path and line positions) | | **Thread Comments** | Comment body with original author and timestamp | | **PR Labels** | Label names applied to each pull request | | **PR Attachments** | Files attached to pull requests | > **Note**: Original author information and creation dates are embedded as text in PR descriptions and comments, since the Azure DevOps API does not support creating entities on behalf of other users. ## Learn More * [Azure DevOps Backup Contents](/azure-devops/backup-contents) - What data is in each backup * [Restoring a Backup](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/restoring-a-backup.md) - General restore workflow * [Bulk Restore](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/bulk-restore.md) - Restoring multiple repositories at once # Pricing How Cloudback pricing works for Azure DevOps repositories, including unit costs, what's included in backups, and where to subscribe. Cloudback uses a **per-repository pricing model** for Azure DevOps. You pay based on the number of repositories you protect, not the number of users in your organization. ## How Units Work for Azure DevOps Each Azure DevOps repository with backups enabled consumes **1 unit** from your subscription pool. | What You Protect | Units Consumed | | ----------------------------- | -------------- | | 1 Azure DevOps repository | 1 unit | | 10 Azure DevOps repositories | 10 units | | 100 Azure DevOps repositories | 100 units | Units are shared across all connected accounts and platforms. For full plan details, pricing tables, and billing cycle options, see [Pricing](/account-and-billing-management/pricing). ## What's Included Every Azure DevOps backup includes the full repository plus metadata: * Git repository (bare clone with all branches, tags, and refs) * Git LFS objects * Pull requests with full metadata * Review threads and comments * Commits and messages * Reviewers and vote statuses * Labels * Attachments * Work item references (links) For a complete breakdown, see [Azure DevOps Backup Contents](/azure-devops/backup-contents). ## How to Subscribe for Azure DevOps The recommended way to purchase Cloudback for Azure DevOps is through the **Azure Marketplace**: 1. Select your preferred plan on the [Cloudback page on Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/myrtlelabs-sas.cloudback) 2. Follow Azure instructions to complete the purchase 3. Cloudback will automatically activate for the selected account You can also install via the [Azure DevOps Marketplace (Visual Studio)](https://marketplace.visualstudio.com/items?itemName=MYRTLELABSSAS.cloudback-backup-azure-devops). For alternative payment methods (credit card, bank transfer, invoice), see [Payment Methods](/account-and-billing-management/payment-methods). ## Learn More * [Pricing](/account-and-billing-management/pricing) - Full plan comparison with pricing tables * [Subscription Management](/account-and-billing-management/subscription-management) - Manage subscriptions and account assignments # GitLab Cloudback for GitLab - setup, backup contents, restore, and pricing for GitLab project backups. Cloudback provides secure, automated backups for your GitLab projects, including repository content, issues, merge requests, labels, milestones, boards, and project metadata. ## Getting Started * [Installation Guide](/gitlab/installation-guide) - Step-by-step guide to connecting your GitLab account to Cloudback * [First Backup Walkthrough](/gitlab/first-backup-walkthrough) - Learn how to monitor and manage your first backup * [Restore](/gitlab/restore) - How to restore GitLab data from a backup ## Key Features for GitLab * **Repository backups**: Git repository content via bare clone (all branches, tags, and refs) * **Project Metadata**: Issues, merge requests, labels, milestones, boards, and more * **OAuth Integration**: Connect your GitLab account through GitLab's secure OAuth flow * **Cross-Platform Restore**: Restore GitLab projects to GitHub or vice versa ## What Gets Backed Up Cloudback backs up your GitLab projects, including repository content, issues, merge requests, labels, milestones, boards, and associated metadata. For a complete list of what's included, see [GitLab Backup Contents](/gitlab/backup-contents). ## Pricing GitLab backups use a per-project pricing model - each project consumes 1 unit. See [GitLab Pricing](/gitlab/pricing) for plans and details. # Installation Guide Step-by-step guide to connecting your GitLab account to Cloudback for automated backup of repositories, issues, merge requests, and project metadata. Cloudback provides automated backups for your GitLab projects, including repository content, issues, merge requests, labels, milestones, boards, and project metadata. This guide walks you through connecting your GitLab account to Cloudback. ## Overview of the Setup Process 1. **Sign in to Cloudback** with your existing GitLab account 2. **Add a GitLab account** via the Cloudback dashboard 3. **Authorize Cloudback** through GitLab's OAuth flow 4. **Verify configuration** and optionally customize backup settings ## Prerequisites * **A GitLab.com account** - You need access to the projects you want to back up * **An active subscription** - A Cloudback subscription covering your GitLab projects. Purchase via [GitHub Marketplace](https://github.com/marketplace/cloudback), [Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/myrtlelabs-sas.cloudback), or [contact support](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/contact-us.md) for invoiced billing > **Note**: GitLab does not have its own marketplace integration. Subscriptions are managed via existing payment methods and assigned to your GitLab account through the [Subscription Management](https://github.com/cloudback/docs-internal/blob/docs/account-and-billing-management/subscription-management.md) page. ## Step 1: Add a GitLab Account 1. Sign in to the [Cloudback Dashboard](https://app.cloudback.it) 2. In the left sidebar under **Dashboard**, click **Add Account** (the `+` icon) 3. Select **GitLab** from the platform options ## Step 2: Authorize Cloudback Clicking "GitLab" opens a popup window that redirects you to GitLab's OAuth consent page. * **Scope requested**: `read_api` (read-only access to the GitLab API) * **Purpose**: Allows Cloudback to discover your projects and download repository data and metadata for backup Click **Authorize** to grant access and complete the connection. After authorization, Cloudback automatically: 1. Retrieves your GitLab user profile 2. Discovers all groups you have access to 3. Creates account entries for your **personal namespace** and each **group** 4. Discovers projects within each namespace and creates backup definitions ## Step 3: Verify Your Projects After connecting, your GitLab projects appear in the dashboard under the **GitLab** section in the left sidebar. Cloudback creates a separate backup definition for each project it discovers. Both account types are supported: | Account Type | Description | Example | | ------------ | --------------------------------------- | --------------------- | | **Personal** | Projects in your personal namespace | `username/my-project` | | **Group** | Projects in GitLab groups you belong to | `my-org/team-project` | ## Step 4: Configure Settings Cloudback applies the settings from your account to each GitLab project. Customize settings by clicking on a project to open the **Project Details** page, then modifying the **Settings** section. ### Assign a Subscription Assign a subscription to your GitLab account: 1. Navigate to **Subscriptions** in the left sidebar 2. Click **View** on the subscription you want to use 3. In the **Account Assignments** section, select your GitLab account from the dropdown 4. Click **Assign** ## Setup Complete Cloudback is now configured to protect your GitLab projects. Here's what to expect: * **Backup Schedule**: Your first backups will commence according to the schedule you've set. * **Dashboard Access**: Access your Cloudback Dashboard anytime at . * **Service Status**: If you experience any issues, check our status page at . * **Support**: If you have any questions, don't hesitate to [contact support](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/contact-us.md). ## Learn More * [GitLab Backup Contents](/gitlab/backup-contents) - What data is included in each backup * [First Backup Walkthrough](/gitlab/first-backup-walkthrough) - Step-by-step guide to your first backup * [GitLab: Restoring Data](/gitlab/restore) - How to restore from a backup * [Cross-Platform Restore](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/cross-platform-restore.md) - GitHub ↔ GitLab bidirectional restore * [Subscription Management](https://github.com/cloudback/docs-internal/blob/docs/account-and-billing-management/subscription-management.md) - Assigning subscriptions # First Backup Walkthrough Walk through your first GitLab project backup with Cloudback, from triggering the backup to viewing results and downloading the archive. After connecting your GitLab account to Cloudback, this guide walks you through triggering your first backup and understanding the results. ## Prerequisites * Your GitLab account is [connected to Cloudback](/gitlab/installation-guide) * A [subscription is assigned](https://github.com/cloudback/docs-internal/blob/docs/account-and-billing-management/subscription-management.md) to the account * At least one GitLab project appears in the dashboard ## Triggering Your First Backup While Cloudback will automatically back up your projects on schedule, you can trigger a backup immediately: 1. Navigate to the **GitLab** section in the left sidebar 2. Select the checkbox next to the project you want to back up 3. Click the **Trigger** button in the toolbar Alternatively, from the project details page, click **Backup now**. ## What Happens During Backup A GitLab backup has: 1. **Repository clone** - Cloudback performs a bare Git clone of the repository, including all branches, tags, and refs. Git LFS objects are also fetched. 2. **Metadata download** - Issues, merge requests, labels, milestones, boards, members, and notes are downloaded via the GitLab API. ## Viewing Backup Results Once complete: 1. The **Backup** column shows **Succeeded** (green) or **Failed** (red) 2. The **Last Run** column shows elapsed time Click on the project to view detailed results on the **Project Details** page: **Overview Tab:** * **Settings** - Current schedule, storage, retention * **Statistics** - Backup time and size charts * **Last Backup** - Status, time, size, deduplication, storage, and collected metadata counts: * Issues, issue notes, merge requests, MR notes * Labels, milestones, boards * **Deduplication** - Savings over time **Backups Tab:** * Complete backup history with download and restore options ## Downloading Your Backup 1. On the **Backups** tab, click the **Download** icon 2. The archive is a password-protected ZIP file (AES-256). The password-protection can be disabled in settings if desired. 3. The password is emailed automatically (if password-protection is enabled). 4. Use [7-Zip](https://www.7-zip.org/) to extract (Windows built-in ZIP doesn't support AES) Inside the archive you'll find: * `repo/{ProjectName}.git/` - The bare Git repository * JSON metadata files (issues, MRs, labels, milestones, boards, members, notes) ## Dashboard Columns The GitLab dashboard shows: | Column | Description | | ------------- | ---------------------------------------- | | **Select** | Checkbox for bulk operations | | **Account** | GitLab account/group name | | **Project** | Project name (clickable for details) | | **Status** | Scheduled / Not scheduled / Restore only | | **Schedule** | Backup schedule name | | **Storage** | Storage location | | **Retention** | Retention policy | | **Backup** | Last backup status | | **Last Run** | Time since last backup | ## Next Steps * **Customize settings**: Change schedule, storage, or retention from the Project Details page or from the dashboard using bulk edit * **Set up notifications**: Get alerts for backup success/failure via Slack, Discord, or Teams ## Learn More * [GitLab Backup Contents](/gitlab/backup-contents) - Full details on what's backed up * [GitLab: Restoring Data](/gitlab/restore) - How to restore * [Cross-Platform Restore](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/cross-platform-restore.md) - GitHub ↔ GitLab migration * [Automated Daily Backups](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/automated-daily-backups.md) - Schedule configuration # Backup Contents Detailed breakdown of all GitLab project data included in Cloudback backups, including repository clone and structured metadata. Each Cloudback backup of a GitLab project creates an encrypted ZIP archive (unless password protection is disabled) containing a complete snapshot of your project. This page details everything that is included. ## Summary A GitLab backup includes **two main components**: | Component | Description | | -------------------- | ------------------------------------------------------------------------------------------------------------------ | | **Repository Clone** | Bare Git clone with all branches, tags, refs, and LFS objects | | **Metadata JSON** | Structured JSON files for project settings, issues, merge requests, labels, milestones, boards, members, and notes | ## Archive Structure ``` backup-archive-root/ ├── repo/ │ └── {ProjectName}.git/ # Bare git repository ├── project.json # Project metadata ├── issues.json # All issues ├── issue-notes.json # Comments on issues ├── issue-links.json # Issue relationships ├── merge-requests.json # All merge requests ├── merge-request-notes.json # Comments on merge requests ├── labels.json # Project labels ├── milestones.json # Project milestones ├── members.json # Project members └── boards.json # Issue boards with lists/columns ``` ## Component Details ### 1. Repository Clone The repository is cloned as a **bare Git repository** (`git clone --bare`) into the `repo/` directory. **What's included:** * All branches (including remote tracking branches) * All tags * All Git refs * **Git LFS objects** - Cloudback attempts `git lfs fetch --all` after cloning. If LFS fetch fails, the clone itself is still preserved (LFS failure is non-blocking). ### 2. Metadata JSON Files Cloudback downloads structured metadata via the GitLab REST API and saves it as JSON files: | File | Contents | | ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | **project.json** | Project settings: name, description, visibility, default branch, feature flags (issues, MRs, wiki, CI/CD), merge request settings, topics | | **issues.json** | All issues: title, description, state, labels, milestone, assignees, weight, time tracking (estimate + spent), due date, confidential flag | | **issue-notes.json** | All issue comments: body, author, timestamps, system/internal flags, diff note positions (for code-linked comments) | | **issue-links.json** | Issue relationships: relates\_to, blocks, is\_blocked\_by (deduplicated, same-project only) | | **merge-requests.json** | All merge requests: title, description, state, source/target branches, labels, milestone, assignees, diff refs | | **merge-request-notes.json** | All MR comments: body, author, timestamps, diff note positions (file path, line numbers for code review comments) | | **labels.json** | All project labels: name, color, description | | **milestones.json** | All milestones: title, description, state, start/due dates | | **members.json** | All project members: username, name, state, access level (Guest/Reporter/Developer/Maintainer/Owner) | | **boards.json** | Issue boards with their columns/lists: board name, label-based columns with position ordering | ## Backup Statistics During the backup process, Cloudback collects the following statistics: * Number of issues * Number of issue notes (comments) * Number of merge requests * Number of merge request notes * Number of labels * Number of milestones * Number of boards These statistics are displayed on the **Project Details** page in the Cloudback dashboard. ## Learn More * [GitLab: Getting Started](/gitlab/installation-guide) - Connect your account * [GitLab: Restoring Data](/gitlab/restore) - How to restore from a backup * [Cross-Platform Restore](/data-restoration/cross-platform-restore) - GitHub ↔ GitLab restore * [Password-Protected Archives](/security-and-compliance/password-protected-archives) - Encryption details * [Data Deduplication](/managing-backups/data-deduplication) - How deduplication works # Restore Learn how to restore GitLab project data from a Cloudback backup, including repository, issues, merge requests, labels, milestones, and boards. Cloudback can restore your GitLab project data from any backup archive. This includes the Git repository, metadata (issues, merge requests, labels, milestones), and board configurations. ## Overview Restoring a GitLab project involves: 1. **Authorizing** a restore OAuth token (with `api` write scope) 2. **Selecting** the target namespace (personal or group) 3. **Providing** a project name 4. **Executing** the restore - Cloudback creates the project, pushes the repository, and restores all metadata ## Prerequisites * A successful backup archive of a GitLab project * A **GitLab.com account** with access to the target namespace * You must have permission to create projects in the target namespace ## Step-by-Step Restore Process ### Step 1: Initiate Restore 1. Navigate to your GitLab project in the Cloudback dashboard 2. Open the **Backups** tab and find the backup to restore from 3. Click the **Restore** button ### Step 2: Authorize Restore Access If this is your first restore, Cloudback requests a separate OAuth token with write permissions: * **Scope requested**: `api` (full read-write access to the GitLab API) * **Purpose**: Grants Cloudback permission to create projects, push repositories, and create issues/MRs Click **Authorize** on the GitLab consent page. > **Why a separate token?** Backup only needs `read_api` scope, but restore needs `api` (full access) to create projects and entities. Keeping these separate follows the principle of least privilege. ### Step 3: Select Target Choose where to restore the project: | Target Type | Description | | ---------------------- | --------------------------------------------------------------------------- | | **Personal namespace** | Restores under your personal GitLab account (`username/project-name`) | | **Group** | Restores into a GitLab group you have access to (`group-name/project-name`) | ### Step 4: Execute Restore Click **Restore** to begin. The process runs in the background. ## What Gets Restored | Entity | Restored Fields | | -------------------- | ------------------------------------------------------------------------------------ | | **Repository** | All branches, tags, refs, LFS objects | | **Project Settings** | Visibility, features, merge settings, description, topics | | **Labels** | Name, color, description | | **Milestones** | Title, description, state, dates | | **Issues** | Title, description, state, labels, milestone, assignee, dates, time tracking, weight | | **Issue Comments** | Body, author, dates, system/internal flags | | **Issue Links** | Type (relates\_to, blocks, is\_blocked\_by) | | **Merge Requests** | Title, description, state, branches, labels, milestone, draft | | **MR Comments** | Body, author, diff positions | | **Boards** | Board lists with label-based columns | ## ID Mapping During restore, Cloudback maintains mappings between old and new IDs: * **Milestone IDs**: Old global ID → new global ID (used in issue/MR milestone references) * **Issue IIDs**: Old project-scoped IID → new IID * **MR IIDs**: Old project-scoped IID → new IID This ensures cross-references between entities are preserved correctly. ## Learn More * [GitLab Backup Contents](/gitlab/backup-contents) - What data is in each backup * [Cross-Platform Restore](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/cross-platform-restore.md) - GitHub ↔ GitLab bidirectional restore * [Restoring a Backup](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/restoring-a-backup.md) - General restore documentation # Pricing How Cloudback pricing works for GitLab projects, including unit costs, what's included in backups, and where to subscribe. Cloudback uses a **per-project pricing model** for GitLab. You pay based on the number of projects you protect, not the number of users in your group. ## How Units Work for GitLab Each GitLab project with backups enabled consumes **1 unit** from your subscription pool. | What You Protect | Units Consumed | | ------------------- | -------------- | | 1 GitLab project | 1 unit | | 10 GitLab projects | 10 units | | 100 GitLab projects | 100 units | Units are shared across all connected accounts and platforms. For full plan details, pricing tables, and billing cycle options, see [Pricing](/account-and-billing-management/pricing). ## What's Included Every GitLab backup includes the full repository plus metadata: * Git repository (bare clone with all branches, tags, and refs) * Git LFS objects * Project settings * Issues and issue notes/comments * Issue links (relates/blocks/is\_blocked\_by) * Merge requests and merge request notes * Labels * Milestones * Members with access levels * Boards with columns For a complete breakdown, see [GitLab Backup Contents](/gitlab/backup-contents). ## How to Subscribe for GitLab * **Credit Card**: Payments processed through [Paddle](https://paddle.com). See [Payment Methods](/account-and-billing-management/payment-methods) for details. * **Bank Transfer / Invoice**: Available for quarterly plans and enterprise customers - [contact us](/troubleshooting-and-support/contact-us). For all payment options, see [Payment Methods](/account-and-billing-management/payment-methods). ## Learn More * [Pricing](/account-and-billing-management/pricing) - Full plan comparison with pricing tables * [Subscription Management](/account-and-billing-management/subscription-management) - Manage subscriptions and account assignments # Linear Cloudback for Linear - setup, backup contents, restore, and pricing for Linear workspace backups. Cloudback provides secure, automated backups for your Linear workspace data, including issues, projects, documents, cycles, comments, labels, templates, and embedded files. ## Getting Started * [Installation Guide](/linear/installation-guide) - Step-by-step guide to connecting your Linear workspace to Cloudback * [First Backup Walkthrough](/linear/first-backup-walkthrough) - Learn how to monitor and manage your first backup * [Restore](/linear/restore) - How to restore Linear data from a backup ## Key Features for Linear * **Workspace backups**: Workspace data is included in every backup * **Multiple Workspaces**: Each workspace is connected independently - back up as many as you need under a single subscription * **OAuth Integration**: Connect your Linear workspace through Linear's secure OAuth flow * **Automated Scheduling**: Set daily or custom backup schedules for your workspace data * **Flexible Recovery**: Restore workspace data directly to Linear or download as secure archives ## What Gets Backed Up Cloudback backs up your Linear workspace data. For a complete list of what's included, see [Linear Backup Contents](/linear/backup-contents). ## Pricing Linear backups use a per-workspace pricing model based on the number of active, non-app workspace members, with progressive tiers (2 units for members 1-5, 4 units for members 6-25, 6 units for members 26+; minimum 2 units per workspace). See [Linear Pricing](/linear/pricing) for plans and worked examples. # Installation Guide Step-by-step guide to connecting your Linear workspace to Cloudback for automated backup of issues, projects, documents, and other workspace data. Cloudback provides automated backups for your Linear workspace data, including issues, projects, documents, cycles, comments, labels, templates, and embedded files. This guide walks you through connecting your Linear workspace to Cloudback. ## Overview of the Setup Process To start backing up your Linear workspace with Cloudback, you'll need to complete the following steps: 1. **Sign in to Cloudback** with your existing Linear account 2. **Add a Linear workspace** via the Cloudback dashboard 3. **Authorize Cloudback** through Linear's OAuth flow 4. **Verify configuration** and optionally customize backup settings ## Prerequisites Before you begin, ensure you have: * **A Linear workspace** - You must be an **admin** or **owner** of the Linear workspace you want to back up * **An active subscription** - A Cloudback subscription plan that covers the workspace. You can purchase a plan via [GitHub Marketplace](https://github.com/marketplace/cloudback), [Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/myrtlelabs-sas.cloudback), or by [contacting support](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/contact-us.md) for invoiced billing > **Note**: Unlike GitHub and Azure DevOps, Linear does not have a marketplace integration. Subscriptions are managed via existing payment methods and assigned to your Linear workspace through the [Subscription Management](https://github.com/cloudback/docs-internal/blob/docs/account-and-billing-management/subscription-management.md) page. ## Step 1: Add a Linear Workspace 1. Sign in to the [Cloudback Dashboard](https://app.cloudback.it) 2. In the left sidebar under **Dashboard**, click **Add Account** (the `+` icon) 3. Select **Linear** from the platform options ## Step 2: Authorize Cloudback Clicking "Linear" opens a popup window that guides you through two authorization steps. Both happen automatically in sequence - you only need to approve each one. ## Step 3: Workspace Connection After both authorizations complete, Cloudback will: 1. Retrieve your workspace information (name, URL, logo) 2. Verify that you have **admin** or **owner** access to the workspace 3. Create the workspace backup definition with default settings You'll see a success confirmation, and your Linear workspace will appear in the dashboard under the **Linear** section in the left sidebar. ## Step 4: Verify Configuration After connecting your workspace, Cloudback applies the settings from your account. You can customize these settings by clicking on your workspace in the dashboard to open the **Workspace Details** page, then modifying the **Settings** section. ### Assign a Subscription If you haven't already, assign a subscription to your Linear workspace: 1. Navigate to **Subscriptions** in the left sidebar 2. Click **View** on the subscription you want to use 3. In the **Account Assignments** section, select your Linear workspace from the dropdown 4. Click **Assign** Once connected and a subscription is assigned: * Your first backup will run according to the configured schedule (or you can trigger one manually by clicking **Backup now** on the workspace details page) * Each backup creates an encrypted ZIP archive containing all workspace data * You can monitor backup status, download archives, or restore data from the dashboard ## Multiple Workspaces Each Linear workspace must be connected independently. To back up additional workspaces, repeat Steps 1-4 for each one. Each workspace connection requires a separate OAuth authorization - you may have different accounts or roles across workspaces. All connected workspaces share units from the same subscription pool. See [Linear Pricing](/linear/pricing) for how units are calculated across multiple workspaces. ## Setup Complete Cloudback is now configured to protect your Linear workspace. Here's what to expect: * **Backup Schedule**: Your first backup will commence according to the schedule you've set. * **Dashboard Access**: Access your Cloudback Dashboard anytime at . * **Service Status**: If you experience any issues, check our status page at . * **Support**: If you have any questions, don't hesitate to [contact support](https://github.com/cloudback/docs-internal/blob/docs/troubleshooting-and-support/contact-us.md). ## Learn More * [Linear Backup Contents](/linear/backup-contents) - What data is included in each backup * [First Backup Walkthrough](/linear/first-backup-walkthrough) - Step-by-step guide to your first backup * [Subscription Management](https://github.com/cloudback/docs-internal/blob/docs/account-and-billing-management/subscription-management.md) - Assigning subscriptions to accounts * [Dashboard Overview](https://github.com/cloudback/docs-internal/blob/docs/dashboard/dashboard-overview.md) - Navigating the Cloudback dashboard # First Backup Walkthrough Walk through your first Linear workspace backup with Cloudback, from triggering the backup to viewing results and downloading the archive. After connecting your Linear workspace to Cloudback, this guide walks you through triggering your first backup and understanding the results. ## Prerequisites Before starting, ensure: * Your Linear workspace is [connected to Cloudback](/linear/installation-guide) * A [subscription is assigned](https://github.com/cloudback/docs-internal/blob/docs/account-and-billing-management/subscription-management.md) to the workspace * The workspace appears in the **Linear** dashboard ## Triggering Your First Backup While Cloudback will automatically back up your workspace on the configured schedule (daily by default), you can trigger a backup immediately: 1. Navigate to the **Linear** section in the left sidebar 2. Select the checkbox next to your workspace 3. Click the **Trigger** button in the toolbar Alternatively, you can trigger a backup from the workspace details page: 1. Click on your workspace name to open the **Workspace Details** page 2. Click the **Backup now** button in the top-right corner The backup process begins immediately. You'll see a progress indicator in the dashboard. ## Monitoring Backup Progress While the backup is running: * The **Backup** column in the dashboard shows **In Progress** with a blue indicator * On the Workspace Details page, a running status badge replaces the **Backup now** button ## Viewing Backup Results Once the backup completes: 1. The **Backup** column shows **Succeeded** (green) or **Failed** (red) 2. The **Last Run** column shows how long ago the backup completed (e.g., "2 minutes ago") ### Workspace Details Page Click on your workspace to view detailed results: **Overview Tab:** * **Settings** section shows your current schedule, storage, and retention policy * **Statistics** section shows backup time and size charts over the selected period * **Last Backup** section shows the most recent backup details including: * Status, start time, elapsed time, archive size * Deduplication status * Storage location * **Collected metadata** - a detailed breakdown showing counts for: * Teams, Projects, Issues, Comments * Cycles, Documents, Labels, Project Labels * Custom Views, Initiatives, Templates (issue/project/document) * Project Updates, Initiative Updates * Project Milestones, Users, Attachments * Embedded Files (successful + failed) * External Users **Backups Tab:** * Lists all backup archives with status, time, size, and storage * Click the **Information** icon to view details for any backup * Use the **Download** button to download the archive * Use the **Restore** button to start a restore operation **Restores Tab:** * Shows any restore operations (empty after your first backup) ## Downloading Your First Backup To download and inspect the backup archive: 1. On the **Workspace Details** page, click the **Backups** tab 2. Click the **Download** icon on your first backup 3. The archive is a password-protected ZIP file (AES-256). The password-protection can be disabled in settings if desired. 4. The password is emailed automatically (if password-protection is enabled). To extract the archive, use a tool that supports AES-256 encryption (e.g., [7-Zip](https://www.7-zip.org/)). Windows built-in ZIP handler does not support AES encryption. The archive contains JSON files organized in directories. See [Linear Backup Contents](/linear/backup-contents) for the full structure. ## Understanding the Dashboard Columns The Linear dashboard shows the following columns for your workspace: | Column | Description | | ------------- | ----------------------------------------------------- | | **Select** | Checkbox for bulk operations | | **Workspace** | Linear workspace name (clickable to open details) | | **Name** | Subject name within the workspace | | **Type** | Type of backup subject | | **Status** | Scheduled, Not scheduled, or Restore only | | **Schedule** | Backup schedule name (e.g., "Daily at 9 pm") | | **Storage** | Storage location (e.g., "Cloudback US") | | **Retention** | Retention policy (e.g., "Last 30 days") | | **Backup** | Last backup status (Succeeded / Failed / In Progress) | | **Last Run** | Time since last backup | ## Next Steps * **Customize settings**: Change backup schedule, storage, or retention from the Workspace Details page * **Set up notifications**: Configure instant notifications for backup success/failure via Slack, Discord, or Microsoft Teams * **Enable deduplication**: Reduce storage usage by enabling data deduplication on your storage * **Explore restore**: Learn how to [restore data from a backup](/linear/restore) ## Learn More * [Linear Backup Contents](/linear/backup-contents) - What's included in each backup * [Automated Daily Backups](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/automated-daily-backups.md) - Schedule configuration * [Instant Notifications](https://github.com/cloudback/docs-internal/blob/docs/managing-backups/instant-notifications.md) - Set up backup alerts * [Download Backups](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/download-backups.md) - Download and extract archives # Backup Contents Detailed breakdown of all Linear workspace data included in Cloudback backups, including issues, projects, documents, cycles, templates, and embedded files. Each Cloudback backup of a Linear workspace creates an encrypted ZIP archive containing a complete snapshot of your workspace data. This page details everything that is included. ## Summary A Linear backup includes **23 data categories** covering all core workspace entities: | Category | Storage Format | Description | | --------------------------- | ------------------------------ | ---------------------------------------------- | | Workspace | Single JSON file | Workspace metadata (name, URL, logo) | | Users | Single JSON file | All workspace members with profiles | | Teams | Individual JSON per team | Team settings, cycle config, members | | Issues | Individual JSON per issue | Full issue data with labels, assignees, states | | Comments | Individual JSON per comment | Issue/document/project comments with threads | | Projects | Individual JSON per project | Project details, members, external links | | Cycles | Individual JSON per cycle | Sprint/cycle data per team | | Documents | Individual JSON per document | Rich-text documents | | Initiatives | Individual JSON per initiative | Strategic initiatives with links | | Templates | Individual JSON per template | Issue, project, and document templates | | Custom Views | Individual JSON per view | Saved filters and views | | Workflow States | Single JSON file | All workflow states across teams | | Issue Labels | Single JSON file | Issue label hierarchy | | Project Labels | Single JSON file | Project-specific labels | | Project Statuses | Single JSON file | Available project status definitions | | Attachments | Single JSON file | Attachment metadata and URLs | | Issue Relations | Individual JSON per relation | Blocks/duplicates/relates-to links | | Project Updates | Individual JSON per update | Project status updates | | Initiative Updates | Individual JSON per update | Initiative status updates | | Project Milestones | Individual JSON per milestone | Project milestone targets | | Initiative-to-Project Links | Single JSON file | Initiative-project relationships | | External Users | Single JSON file | External/guest user profiles | | Embedded Files | Downloaded files + manifest | Images and attachments from content fields | ## Archive Structure ``` backup.zip ├── metadata.json # Backup version, workspace ID, statistics ├── workspace.json # Workspace metadata ├── users.json # All workspace users ├── workflow-states.json # All workflow states ├── labels.json # Issue labels ├── project-labels.json # Project labels ├── project-statuses.json # Project status definitions ├── attachments.json # Attachment metadata ├── initiative-to-projects.json # Initiative-project links ├── external-users.json # External/guest users ├── teams/ │ ├── {teamId}.json # Per-team data with settings │ └── ... ├── issues/ │ ├── {issueId}.json # Per-issue data │ ├── index.json # Sorted index of all issues │ └── ... ├── comments/ │ ├── {commentId}.json # Per-comment data │ └── ... ├── projects/ │ ├── {projectId}.json # Per-project data │ └── ... ├── cycles/ │ ├── {cycleId}.json # Per-cycle data │ └── ... ├── documents/ │ ├── {documentId}.json # Per-document data │ └── ... ├── views/ │ ├── {viewId}.json # Per-custom-view data │ └── ... ├── initiatives/ │ ├── {initiativeId}.json # Per-initiative data │ └── ... ├── templates/ │ ├── {templateId}.json # Per-template data │ └── ... ├── project-updates/ │ ├── {updateId}.json # Per-project-update data │ └── ... ├── initiative-updates/ │ ├── {updateId}.json # Per-initiative-update data │ └── ... ├── issue-relations/ │ ├── {relationId}.json # Per-issue-relation data │ └── ... ├── project-milestones/ │ ├── {milestoneId}.json # Per-milestone data │ └── ... └── files/ ├── manifest.json # File download manifest └── {hash-based-filename} # Downloaded embedded files ``` ## Backup Statistics Each backup includes a `metadata.json` file with detailed statistics: * Issue count, project count, team count * Document count, cycle count, comment count * Label count, project label count, user count * Attachment count, custom view count, initiative count * Template counts (issue, project, document separately) * Project update count, initiative update count * Issue relation count, project milestone count * External user count * Embedded file count (successful + failed + total size in bytes) These statistics are displayed on the **Workspace Details** page in the Cloudback dashboard. ## Learn More * [Linear: Getting Started](/linear/installation-guide) - Connect your workspace * [Linear: Restoring Data](/linear/restore) - How to restore from a backup * [Password-Protected Archives](/security-and-compliance/password-protected-archives) - Encryption details * [Data Deduplication](/managing-backups/data-deduplication) - How deduplication works # Restore Learn how to restore Linear workspace data from a Cloudback backup, including the authorization flow, empty workspace requirement, and supported entities. Cloudback can restore your Linear workspace data from any backup archive. This guide explains the restore process, requirements, and what gets restored. ## Overview Restoring a Linear workspace involves: 1. **Authorizing** a separate restore OAuth token (with write permissions) 2. **Preparing** the target workspace (must be empty or cleaned) 3. **Selecting** the target workspace 4. **Executing** the restore - Cloudback recreates all entities in dependency order ## Prerequisites * A successful backup archive of a Linear workspace * A **target Linear workspace** to restore into (can be the same workspace or a different one) * You must be an **admin or owner** of the target workspace > **Important**: The target workspace must be **empty** before restore can proceed. See [Step 3: Verify Workspace Status](#step-3-verify-workspace-status) below. ## Step-by-Step Restore Process ### Step 1: Initiate Restore 1. Navigate to your workspace in the Cloudback dashboard 2. Open the **Backups** tab and find the backup you want to restore from 3. Click the **Restore** button Alternatively, use the **Restore now** button on the workspace details page header. ### Step 2: Authorize Restore Access Cloudback requires a separate OAuth authorization for restore operations, because restoring data requires **write** permissions that are not granted during the initial backup setup. A popup window opens for Linear OAuth authorization: * **Scopes requested**: `read`, `write`, `issues:create`, `comments:create`, `initiative:write` * **Purpose**: Grants Cloudback permission to create issues, projects, comments, and other entities in the target workspace Click **Authorize** to proceed. ### Step 3: Verify Workspace Status After authorization, Cloudback checks whether the target workspace is empty. The UI verifies: * **No projects** exist * **No custom views** exist * **No more than one team** (the default team) Additionally, when the restore starts, Cloudback verifies that **no labels** exist in the workspace. If labels are present, the restore is rejected with an error. > **Why must the workspace be empty?** Restoring into a workspace with existing data could create conflicts - duplicate labels, conflicting issue numbers, and broken references. The empty workspace requirement ensures a clean restore without data corruption. ### Step 4: Confirm and Start The target workspace is already selected during the authorization step. Cloudback uses the workspace's default team to receive all team-specific data. Click **Start Restore** to begin. ### Step 5: Execute Restore Click **Restore** to begin. The restore process runs in the background: 1. **Embedded files** are uploaded first (images and attachments from content fields) 2. **Teams** are created with their settings and members 3. **Labels and project labels** are restored 4. **Projects** with external links and milestones 5. **Cycles** per team 6. **Initiatives** with project links and external links 7. **Issues** (first pass: most issues, sorted so parents are created before children) 8. **Project updates and initiative updates** 9. **Comments** (with threading and resolution support) 10. **Issues** (second pass: issues that reference comments) 11. **Issue relations** (blocks, duplicates, relates-to) 12. **Documents, attachments, custom views, and templates** The restore may take several minutes for large workspaces. ## What Gets Restored ### Fully Restored Entities | Entity | Details | | ---------------------- | ------------------------------------------------------------------------------------ | | **Teams** | Name, settings, cycle configuration, members | | **Issues** | Title, description, priority, assignee, labels, state, dates, parent-child hierarchy | | **Comments** | Body text, threading (parent/reply), resolution status | | **Projects** | Name, description, content, lead, members, external links, status | | **Cycles** | Name, dates, progress, team association | | **Documents** | Title, content, project/initiative/issue associations | | **Initiatives** | Name, description, content, owner, external links, project links | | **Templates** | Issue, project, and document templates with template data | | **Labels** | Issue labels and project labels with hierarchy | | **Custom Views** | Saved filters and views | | **Workflow States** | Mapped per team from backup to target workspace | | **Project Milestones** | Name, target date, project association | | **Issue Relations** | Blocks/blocked-by, duplicates, relates-to links | | **Project Updates** | Status updates with health indicators | | **Initiative Updates** | Status updates with health indicators | | **Attachments** | Metadata and references | | **Embedded Files** | Re-uploaded with URL rewriting across all content fields | ### User Mapping During restore, Cloudback maps users from the backup to the target workspace: * **Users are matched by email address** * If a user exists in the target workspace with the same email, their actions (assignee, creator, commenter) are attributed correctly * If a user does not exist in the target workspace, their actions are attributed to the Cloudback app identity ### Reference Rewriting Cloudback automatically rewrites internal references during restore: * **Issue identifiers**: e.g., `ENG-123` in the source becomes `CLOUD-45` in the target * **Linear URLs**: Links to issues, projects, and documents are updated to point to the new entities * **Embedded file URLs**: `uploads.linear.app` URLs are replaced with new upload URLs after re-uploading ## Known Limitations ### Cannot Rename Default Team Linear's API (`actor=application` OAuth) does not permit renaming teams. The default team in the target workspace retains its original name, even if the backup had a different team name. ## Learn More * [Linear Backup Contents](/linear/backup-contents) - What data is in each backup * [Restoring a Backup](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/restoring-a-backup.md) - General restore documentation * [Bulk Restore](https://github.com/cloudback/docs-internal/blob/docs/data-restoration/bulk-restore.md) - Restoring multiple items at once # Pricing How Cloudback pricing works for Linear workspaces, including the tiered per-member unit model, what's included in backups, and where to subscribe. Cloudback uses a **per-workspace pricing model** for Linear, with units calculated from the number of active workspace members. Pricing is tiered so that small teams stay inexpensive and large teams scale gradually. ## How Units Work for Linear Each Linear workspace with backups enabled consumes units based on the number of **active, non-app members** in the workspace. The tiers are progressive - each member is billed against the band they fall in: | Member position in workspace | Units per member | | ---------------------------- | ---------------- | | Members 1-5 | 2 units each | | Members 6-25 | 4 units each | | Members 26 and above | 6 units each | The minimum is **2 units per workspace**. App users (bots/integrations) and suspended members are excluded from the count. ### Examples | Workspace size | Units consumed | Calculation | | ------------------ | -------------- | ------------------------ | | 1 active member | 2 | 1 × 2 | | 5 active members | 10 | 5 × 2 | | 6 active members | 14 | 5 × 2 + 1 × 4 | | 10 active members | 30 | 5 × 2 + 5 × 4 | | 25 active members | 90 | 5 × 2 + 20 × 4 | | 26 active members | 96 | 5 × 2 + 20 × 4 + 1 × 6 | | 50 active members | 240 | 5 × 2 + 20 × 4 + 25 × 6 | | 100 active members | 540 | 5 × 2 + 20 × 4 + 75 × 6 | | 250 active members | 1,440 | 5 × 2 + 20 × 4 + 225 × 6 | If you back up multiple workspaces, units add up across all of them. Units are also shared across all connected accounts and platforms. The unit count is **recalculated automatically** after each successful backup (and on reconnect) using the current member count returned by the Linear API. ### No Free Plan for Linear Linear has **no free plan or free tier**. The free backup slot included with every connected account covers repositories only (GitHub, GitLab, and Azure DevOps) - it does not extend to Linear workspaces. Every Linear workspace is billed using the member tiers above. All paid plans include a **free trial**, so you can evaluate Linear backups before committing. For full plan details, pricing tables, and billing cycle options, see [Pricing](/account-and-billing-management/pricing). ## What's Included Every Linear backup includes workspace data: * Workspace metadata and settings * Users and external users * Teams * Issues and comments * Projects and project updates * Cycles * Documents * Initiatives and initiative updates * Templates (issue, project, document) * Custom views * Workflow states * Issue labels and project labels * Project statuses and milestones * Attachments and embedded files * Issue relations * Initiative-to-project links For a complete breakdown, see [Linear Backup Contents](/linear/backup-contents). ## How to Subscribe for Linear * **Credit Card (direct checkout)**: Buy a subscription directly from the **Subscriptions** page in the Cloudback dashboard, paid through [Paddle](https://paddle.com). See [Payment Methods](/account-and-billing-management/payment-methods) for details. * **Bank Transfer / Invoice**: Available for quarterly plans and enterprise customers - [contact us](/troubleshooting-and-support/contact-us). For all payment options, see [Payment Methods](/account-and-billing-management/payment-methods). ## Learn More * [Pricing](/account-and-billing-management/pricing) - Full plan comparison with pricing tables * [Subscription Management](/account-and-billing-management/subscription-management) - Manage subscriptions and account assignments # Managing Backups Guide to managing backups with Cloudback, including automated schedules, retention policies, and storage configuration. Learn how to configure and manage your backups across all supported platforms. ## Backup Features * [Automated Daily Backups](/managing-backups/automated-daily-backups) - Set up automatic scheduled backups * [On-Demand Manual Backups](/managing-backups/one-click-manual-backups) - Trigger backups on demand * [Setting Backup Schedules](/managing-backups/setting-backup-schedules) - Customize backup frequency ### Platform-Specific Backup Contents * [GitHub Backup Contents](/github/backup-contents) - What's included in GitHub backups * [Azure DevOps Backup Contents](/azure-devops/backup-contents) - What's included in Azure DevOps backups * [GitLab Backup Contents](/gitlab/backup-contents) - What's included in GitLab backups * [Linear Backup Contents](/linear/backup-contents) - What's included in Linear backups ## Storage & Retention * [Manage Backup Storage](/managing-backups/manage-backup-storage) - Configure where backups are stored * [Backup Retention Policy](/managing-backups/backup-retention-policy) - Control how long backups are kept * [Data Deduplication](/managing-backups/data-deduplication) - Optimize storage usage ## Security & Configuration * [Password-Protected Archives](/security-and-compliance/password-protected-archives) - Encrypt your backup archives * [Account Settings](/managing-backups/account-settings) - Organization and account configuration * [Bulk Operations](/managing-backups/bulk-operations) - Manage multiple repositories at once * [Archive Name Pattern](/managing-backups/archive-name-pattern) - Customize backup file names ## Notifications * [Email Notifications](/managing-backups/email-notifications) - Get notified about backup status * [Instant Notifications](/managing-backups/instant-notifications) - Real-time alerts # Automated Daily Backups Configure and manage Cloudback automated daily backups for GitHub repositories, including custom schedules, storage options, and retention policies. Cloudback's automated daily backup is a core feature designed to ensure your repositories and metadata are automatically backed up - without any manual intervention. ## Overview You can check if the repositories are automatically backed up by looking at the "Schedule" column in the repository list. If the column shows the schedule, the repository is being backed up automatically. If the column is empty, the repository is not being backed up automatically. Cloudback creates backups according to a schedule, saves them in a designated storage, and stores them according to your retention policy: * **Backup Schedule**: Set the time and frequency of backups. By default, backups are scheduled to run daily. The time of the backup is determined by the time zone you set during account configuration and can be changed in the account settings. * **Storage Configuration**: Choose where your backups are stored. Cloudback offers both Cloudback Managed Storages and Customer Managed Storages. By default, backups are stored in Cloudback Managed Storages. * **Retention Policy**: Define how long backups are stored. By default, backups are stored for 30 days. For details, see [Backup Retention Policy](/managing-backups/backup-retention-policy). If you prefer, you can customize the backup schedule, storage, and retention policy to better suit your needs. ## Custom Backup Schedules You have full control over when backups occur. Whether you need backups daily at a specific time or on a custom CRON schedule, you can adjust the timing through the user-friendly interface. Predefined options include daily schedules at any hour of the day. For hourly, weekly, monthly, or other frequencies, you can define a custom CRON expression. For example, if your repositories are more active during business hours, you might schedule backups for early mornings or late nights to minimize interference. You can change the backup schedule for individual repositories in the repository settings by selecting the desired schedule: ![Setting up backup schedule](/files/wBJKWqUn2pGDv2aPWxd2) You can also update the schedule for multiple repositories at once using [Bulk Operations](/managing-backups/bulk-operations). ## Backup Storage Options Backup Storage is where your backups are stored. Cloudback offers two types of storage options: * **Cloudback Managed Storages**: Cloudback provides storage for your backups. By default, backups are stored in Cloudback Managed Storage. Learn more about [Cloudback Managed Storages](/storage-configuration/cloudback-managed-storages). * **Customer Managed Storages**: You can use your own storage to store backups. You can configure your storage in the Storages page. Learn more about [Customer Managed Storages](/storage-configuration/customer-managed-storages). You can change the storage for individual repositories in the repository settings by selecting the desired storage: ![Set up backup storage](/files/h0AbgMJZccT9FKD4yVnS) You can also update storage for multiple repositories at once using [Bulk Operations](/managing-backups/bulk-operations). ## Retention Policy The Retention Policy gives you control over how long your backups are stored. With predefined retention options ranging from 30 to 360 days, you can select the right duration based on your needs, ensuring optimal storage use. You can modify retention policies for individual repositories by opening the repository settings and selecting the desired retention policy: ![Set up retention policy](/files/gi8smgFmzdNLMSEbg8rj) You can also update retention for multiple repositories at once using [Bulk Operations](/managing-backups/bulk-operations). ## Managing Subscription Limits As you set up automated backups, it’s important to manage the number of repositories included in your Cloudback plan. Under the Subscriptions menu, you’ll find all the necessary details: * **Total**: The total number of repositories your plan supports (purchased capacity). * **Scheduled**: How many of those repositories are currently scheduled for backup. * **Consumption**: Current usage relative to your plan capacity. This helps you track your repository usage and make informed decisions about whether you need to upgrade your plan or adjust your backups. ## Time Zone Configuration Cloudback's scheduling process is sensitive to the time zone you define. The time zone is set during the initial account configuration and affects all automated tasks. If your needs change, you can easily update the time zone through the `Account Settings` page, ensuring your backups run exactly when you expect. This is particularly useful when coordinating across multiple teams or regions, as the flexibility to adjust time zones makes Cloudback adaptable to global workflows. ## Learn More * [Setting Backup Schedules](/managing-backups/setting-backup-schedules) * [Cloudback Managed Storages](/storage-configuration/cloudback-managed-storages) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Backup Retention Policy](/managing-backups/backup-retention-policy) * [Backup Details](/dashboard/backup-details) # On-Demand Manual Backups Learn how to create on-demand manual backups of your repositories with Cloudback, perfect for pre-change snapshots or immediate backup needs. While Cloudback automatically backs up your repositories daily, you can also create manual backups at any time. Manual backups are useful in the following scenarios: * When testing a newly configured backup storage * When you need to download the latest version of your repository without waiting for automated backups * When you aim to secure a specific version of your repository, eg: * Before making significant changes to your repository * Before deleting a repository * Before transferring a repository to another user * Before migrating a repository to another platform ## Creating a manual backup Follow these steps to create a manual backup: 1. Go to the [Cloudback dashboard](https://app.cloudback.it). 2. Find the repository you want to back up. 3. Select the repository by checking the checkbox in the first column. 4. Click the **Trigger** button in the top toolbar. The backup will be queued immediately and starts as soon as a worker is available. Manual backups are prioritized over scheduled backups. You can monitor its progress in the dashboard. **Note:** If a backup is already in progress or queued for a repository, the manual trigger will be rejected. There is also a 1-minute cooldown between manual triggers per repository - repeated triggers within 1 minute will be rejected with an error indicating the last trigger time. ![Trigger repository backup manually](/files/jN57XD2GajxBOCKXZuN3) ### Backup Now from Repository Details As an alternative to the checkbox-and-trigger flow, you can trigger a backup directly from a repository's detail page: 1. Click on the repository name to open its details page. 2. Click the **Backup now** button in the repository header. This is the quickest way to trigger a backup for a single repository without returning to the main list. ### Bulk Manual Backups You can trigger backups for multiple repositories at once: 1. Select multiple repositories by checking their checkboxes. 2. The **Trigger** button in the top toolbar shows a count of selected items. 3. Click **Trigger** to queue all selected repositories for backup. Please be aware that [email notifications](/managing-backups/email-notifications) are not sent out for manual backups. This feature is exclusively available for automatic backups. ## Learn More * [Backup Details](/dashboard/backup-details) * [Email Notifications](/managing-backups/email-notifications) * [Backup Status Badge](/dashboard/backup-status-badge) # Setting Backup Schedules Create and apply custom backup schedules for your repositories in Cloudback using cron-based options for daily, weekly, or monthly backups. Cloudback provides built-in schedules for daily backups. However, you may also need to have a custom schedule for your backups, like weekly or monthly backups. In this case, you can set up a custom schedule for your backups. This page will guide you through the process of setting up a custom schedule for your backups and applying it to your repositories. ## Creating a Custom Schedule Follow these steps to create a new custom schedule for your backups: 1. Open the Cloudback dashboard and navigate to the `Schedules` page using the left menu. 2. Click on the `+ Add a new schedule` button to create a new schedule: ![Create a new schedule](/files/bJCoVvh2YNcLEgncQ6M7) 3. Enter the schedule name. It will be used to identify the schedule in the list of schedules when you choose a schedule for your repository. 4. All schedules are cron-based schedules. You can set up a schedule to run at a specific time or on specific days of the week or month by selecting the corresponding options in the `Hour`, `Day`, and `Month` tabs. For example, to run a backup every Monday at 12:00 AM, you would select the `Day` tab and check the `Monday` checkbox. The corresponding cron expression will be generated automatically based on your selections. 5. Click on the `Save` button to save the schedule. The schedule will be displayed in the list of schedules. ![Save a schedule](/files/4riATVq8YDbzRzNRk5eC) You can edit or delete a custom schedule by clicking on the `Edit` or `Delete` buttons next to the schedule in the list of schedules. Please note that you cannot delete a schedule that is currently in use by any repository. ### Custom Schedule Access You can configure the accounts who can access each custom schedule. To edit schedule access settings, go to the `Schedules` page, find the schedule you want to modify, and click on the `Edit Access` button. In the Edit Schedule Access page, you can manage access permissions for individual accounts: ![Edit Schedule Access](/files/N9npVPATSSpJnY2aaAK3) ## Applying a Custom Schedule to a Repository You can apply a custom schedule to a repository by opening repository details, selecting the custom schedule from the list of schedules, and clicking on the `Save` button. The repository will start using the custom schedule for its backups. ![Set up backup schedule](/files/GpkfIV1O1A8cQyyy8q2L) Also, you can apply a custom schedule to multiple repositories at once using the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Bulk Operations](/managing-backups/bulk-operations) # Manage Backup Storage Learn how to configure and manage storage options for your backups in Cloudback, including Cloudback Managed and Customer Managed Storage solutions. Cloudback allows you to set up a backup storage for your repositories. The backup storage defines where the backups should be stored. This page will guide you through the process of setting up a backup storage for your repositories. ## Setting Up a Backup Storage Follow these steps to set up a backup storage for your repositories: 1. Go to the [Cloudback Dashboard](https://app.cloudback.it/). 2. Open the repository details page for the repository you want to set up a backup storage for. 3. In the **Settings** section, locate the `Storage` combobox and choose the storage you want to save the backups to: ![Repository backup storage](/files/h0AbgMJZccT9FKD4yVnS) 4. Click the **Save** button to save the changes. You can update a storage for multiple repositories at once using the [Bulk Operations](/managing-backups/bulk-operations). ## Supported Storages Cloudback supports the following storages: * **Cloudback Managed Storages**: These are the storages managed by Cloudback. Learn more about [Cloudback Managed Storages](/storage-configuration/cloudback-managed-storages). * **Customer Managed Storages**: These are the storages managed by you, and you can set up your own storage for your backups. Learn more about [Customer Managed Storages](/storage-configuration/customer-managed-storages). When setting up a backup storage, you can choose from the list of Cloudback Managed Storages or set up your own Customer Managed Storage. Both types of storages are available in the Storage combobox. ## Learn More * [Cloudback Managed Storages](/storage-configuration/cloudback-managed-storages) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) # Backup Retention Policy Configure how long Cloudback keeps your repository backups with customizable retention policies, helping you manage storage efficiently. Cloudback allows you to set up a backup retention policy for your repositories. The retention policy defines how long the backups should be kept before they are automatically deleted. Retention policies apply to all supported platforms. ## How Retention Works A retention policy has two enforcement dimensions that both apply to every backup definition: * **Age limit**: backups older than the configured number of days are deleted. * **Count limit**: when the number of successful backups exceeds the configured maximum, the oldest backups are removed first. Both limits are checked independently. A backup is removed if it violates either limit. ### Deduplication protection Backups that serve as a deduplication parent (referenced by one or more newer backups) are **never deleted**, even if they exceed the configured limits. This ensures that backups referencing a parent archive always remain valid. ### Enforcement timing Retention is enforced **hourly** by a background maintenance job. Changing a retention policy does not delete backups immediately - the change takes effect at the next hourly enforcement pass. ## Available Retention Presets Cloudback includes the following built-in retention policies, available to all accounts: | Policy | Age Limit | Count Limit | | ------------- | --------- | ------------ | | Last 30 days | 30 days | 200 backups | | Last 90 days | 90 days | 270 backups | | Last 180 days | 180 days | 540 backups | | Last 360 days | 360 days | 1080 backups | The default policy for new accounts and new repositories is **Last 30 days**. ## Setting Up a Backup Retention Policy Follow these steps to set a retention policy for a repository: 1. Go to the [Cloudback Dashboard](https://app.cloudback.it/). 2. Open the repository details page for the repository you want to configure. 3. In the **Settings** section, locate the `Retention` combo box and choose the retention policy you want to apply to the repository: ![Backup retention policy](/files/duZOYJy3Vc18Cjh8bvWY) 4. Click the **Save** button to save the changes. You can update the retention policy for multiple repositories at once using [Bulk Operations](/managing-backups/bulk-operations). ## Custom Retention Policies If the built-in presets don't cover your use case, you can request a **custom retention policy** with specific age and count limits. Custom retention policies can't be created from the UI. To request one, [contact the Cloudback support team](/troubleshooting-and-support/contact-us) at with your desired age limit (in days) and count limit. Custom policies are usually set up within one business day. Once created, your custom retention policy will appear in the **Retention** dropdown alongside the built-in presets - both in the repository settings and in [Account Settings](/managing-backups/account-settings). The support team can also restrict a custom policy to specific platform accounts. ## Account-Level Default Retention The **Account Settings** page lets you configure a default retention policy that is applied automatically to all new repositories added to your account. Changing the account-level default does not affect repositories that already have a retention policy assigned - use [Bulk Operations](/managing-backups/bulk-operations) to update existing repositories. ## Learn More * [Account Settings](/managing-backups/account-settings) * [Bulk Operations](/managing-backups/bulk-operations) * [Contact Us](/troubleshooting-and-support/contact-us) # Account Settings Configure default backup settings for your repositories in Cloudback, including timezone, schedules, storage options, and repository naming patterns. The **Account Settings** page allows you to configure default backup settings for repositories linked to your connected accounts across all supported platforms. ## Default Configuration When you connect a new account or add new repositories, Cloudback applies these defaults: * **Schedule**: Daily automated backups * **Storage**: Cloudback Managed Storage * **Retention**: 30-day retention policy * **Notifications**: Daily email summary for failed backups You can customize all of these per account or per repository. ## How to Configure Account Settings To access and modify account settings, navigate to the `Account Settings` page from the sidebar. Use the account selector at the top of the page to switch between your connected platform accounts - each account is shown with its platform badge and avatar. Here, you can set the **default backup schedule, storage location, retention policy**, and other settings for all repositories associated with the selected account. The settings also affect new repositories and new linked accounts added in the future. ![Account Settings](/files/UykcJikRrjXWYXgblBuj) ## Available Settings All settings in the **Account Settings** page are applied to the selected account. The timezone is applied to all existing repositories and new ones. The other settings will be applied to all new repositories of the account selected above. If you want to apply settings to already existing repositories, use [Bulk Operations](/managing-backups/bulk-operations). You can configure the following settings: ### Timezone * Determines the timezone used for scheduling backups. * The selected timezone applies to all existing repositories and new ones added under the account. ### Default Schedule * Sets the default backup schedule for new repositories. * Options include predefined schedules such as **Daily at 1 PM**, and schedules created by the user. For more information, see [Backup Schedules](/managing-backups/setting-backup-schedules). ### Default Storage * Specifies the default storage location for backup archives for new repositories. * You can choose **Cloudback Managed Storage** or a **custom storage** created by the user. ### Default Retention Policy * Defines how long backup archives of new repositories are retained before being deleted. For more information, see [Backup Retention Policy](/managing-backups/backup-retention-policy). * Example: **Last 30 days**. ### Archived Repository Handling **GitHub only.** Determines how archived repositories are treated in Cloudback. * Options: * **Hide from dashboard and skip backup** (default). * **Display on dashboard and backup**. This setting is only available for GitHub accounts. Other platforms do not have this option. ### Auto-Enabling New Repositories New repositories are automatically enabled for backup across all supported platforms, as long as the subscription plan has available slots. If the plan limit has been reached, newly discovered items remain disabled until you upgrade or free up a slot. For Azure DevOps, GitLab, and Linear accounts, all newly discovered items are automatically enabled without pattern filtering. **GitHub** accounts additionally support **wildcard pattern filtering**, allowing you to control which new repositories are automatically enabled based on naming patterns. Repository name pattern accepts [wildcard](https://en.wikipedia.org/wiki/Wildcard_character) characters and a comma character to join multiple queries. Wildcard characters: * `*` - zero or more characters * `?` - exactly one character * `,` - specify multiple queries separated by a comma #### Examples: Considering the selected account has 4 repositories `awesome`, `awesome-repos`, `book` and `static-website-example`, the given patterns will match the following repositories: * `*` - matches all repositories * `awe*` - matches `awesome` and `awesome-repos` * `awe*,book` - matches `awesome`, `awesome-repos` and `book` * `*b*` - matches `book` and `static-website-example` ### Backup Encryption * Specifies the default encryption provider used when creating backup archives for new repositories. * The dropdown lists all encryption providers you have access to: * **Secure Random Key** (built-in) - Cloudback generates and manages a unique random password for each backup. You don't need to provide anything extra during restore or download. * **RSA Lockbox** (customer-managed) - You provide your own RSA public key. During restore or download, you'll need to paste your private key so Cloudback can decrypt the backup password. * Additional provider types (**External KMS**, **External Password API**) will be added in future releases. * To create a custom encryption key, see [Encryption Overview](/encryption-management/encryption-overview). * For details on how archive encryption works, see [Password-Protected Archives](/security-and-compliance/password-protected-archives). > **Note:** Changing the encryption provider only affects **new backups**. Existing backups retain the encryption provider that was active when they were created. ## Danger Zone The **Danger Zone** section at the bottom of the Account Settings page contains destructive actions. To remove a connected account from Cloudback: 1. Navigate to the **Account Settings** page for the account you want to remove 2. Scroll to the **Danger Zone** section 3. Click **Delete Cloudback Account** 4. Confirm the deletion in the confirmation dialog > **Warning**: Deleting an account is a **permanent, destructive operation**. This will permanently remove the account and all associated backup archives. This action cannot be undone. ## Learn More * [Cloudback Managed Storages](/storage-configuration/cloudback-managed-storages) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Backup Schedules](/managing-backups/setting-backup-schedules) * [Backup Retention Policy](/managing-backups/backup-retention-policy) * [User Roles](/dashboard/user-roles) * [Bulk Operations](/managing-backups/bulk-operations) # Bulk Operations Efficiently manage multiple repositories in Cloudback by applying backup settings in bulk, including schedules, storage options, and retention policies. Bulk operations allow you to perform actions on multiple repositories at once. This feature is useful when you need to manage many repositories efficiently. ## How to Perform Bulk Operations To perform bulk operations: 1. Open the **Dashboard** in Cloudback. 2. Use the search bar or filters to find the repositories you want to modify. 3. Select the repositories by checking the checkboxes next to them. 4. Click the **Edit** button in the toolbar to open the Bulk Operations window. The changes you make in the Bulk Operations window will be applied to all selected repositories. ![Bulk operations](/files/62dAd7waul3a6Z0Vcypd) ## Available Bulk Operations You can modify the following settings for multiple repositories at once: * `State` - Schedule / Not Scheduled. This setting allows you to enable or disable the automated daily backups for multiple repositories. * `Schedule` - Set a custom schedule for multiple repositories. You can choose from the predefined schedules or create a new one using [Backup Schedules](/managing-backups/setting-backup-schedules) page. * `Storage` - Set a storage for backup archives, could be `Cloudback` or a custom storage created by a user. * `Retention policy` - Backup archive retention policy - determines how long the backup archives are kept before they are deleted. Each selector defaults to **"Don't change"**, meaning only settings you explicitly modify will be applied. Selectors left at "Don't change" will not affect the selected repositories. ## Results and Error Reporting After applying bulk changes, Cloudback displays a results summary showing how many repositories were updated successfully. If any repositories could not be updated, a table lists each failure with the repository name and the associated error message. Bulk operations are processed per repository. If one repository fails (for example, due to an access control issue), the remaining repositories are still updated. Partial failures are possible and will be reported in the results screen. ## Learn More * [Cloudback Managed Storages](/storage-configuration/cloudback-managed-storages) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Backup Schedules](/managing-backups/setting-backup-schedules) # Data Deduplication Optimize your backup storage with Cloudback's data deduplication, reducing costs by eliminating duplicate archives while maintaining data integrity. With data deduplication, you can save a significant amount of cloud storage space and reduce operational costs. Cloudback offers a simple but efficient technique of data deduplication. ## How deduplication works Cloudback backup archives are deterministic. If nothing has changed in a repository or workspace, Cloudback creates the same archive before encrypting it. Once the archive is encrypted, the AES encryption makes it non-deterministic. Cloudback compares the checksum of a new deterministic backup with a previous deterministic backup before encrypting it. If the archives match, Cloudback doesn’t upload a new archive to storage, but instead stores a link to the previous archive. The retention policy is extended for the previous archive, it’s not deleted until there are valid linked backups. ## How to enable deduplication Deduplication is enabled by default for newly created customer managed storages. If you have older storages (created before May 2022), you may need to enable it manually. Data deduplication is a customer managed storage setting, and it’s configured separately for each storage. To change the deduplication setting for a storage, use the `Deduplication Type` combo box in the `New Storage` and `Edit Storage` pages: ![Data deduplication type](/files/ax9rgr95GvtPQsFoNxit) The following deduplication types are available: * **Only archive if changes have occurred - no duplicates**: Cloudback will not store a new archive if the checksum of a new backup matches the checksum of a previous backup. This is the default deduplication type. * **Always archive - duplicates allowed**: Cloudback will always store a new archive even if the checksum of a new backup matches the checksum of a previous backup. ## When deduplication occurs Deduplication occurs when certain conditions are met: * Deduplication is enabled for the storage while creating a storage or by editing an existing storage * The previous backup of a repository is stored in the same cloud storage * The checksum of a previous backup matches the checksum of a new backup ## Backup deduplication status The deduplication status of a backup is displayed in the `Backup details` window as the `Deduplicated` field: * `Yes` means that the backup is deduplicated * `No` means that the backup is not deduplicated ![Backup deduplication status](/files/3qnJWIzknv9wyFAAEsur) You can open the `Backup details` window by clicking on the `Information` icon which is displayed in the list of backups in the `Backups` tab on the `Repository details` page. ## Backup deduplication statistics The deduplication statistics are displayed in the `Deduplication over period` section of the `Repository details` page. The statistics are displayed for specific periods: `Last Week`, `Last Month`, `Last 3 Months`, `Last 6 Months`, and `Last Year`. ![Repository deduplication stats](/files/FgLebQyJo1dIbtkg6tf4) The following statistics are displayed for the selected period: * `Backups processed` - the total number of backups * `Backups deduplicated` - the number of backups that were deduplicated * `Backups size` - the total size of backups uploaded to storage * `Space saved` - the total size of saved space in storage Statistics charts are displayed for the selected period: * **Donut chart** shows the number of deduplicated and non-deduplicated backups * **Bar chart** shows the deduplication savings over the selected period. * the grey bars represent daily deduplication savings (deduplicated size per day) * the green bars represent the accumulated total deduplication savings over time ## Learn More * [Cloudback Managed Storages](/storage-configuration/cloudback-managed-storages) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Backup Schedules](/managing-backups/setting-backup-schedules) # Email Notifications Stay informed about your repository backup status with Cloudback's email notifications, which alert you to failed backups and provide troubleshooting guidance. Email notifications are a great way to keep track of your backup status. Cloudback emails you a notification in case a backup fails. Email notifications work across all supported platforms. Cloudback sends a daily notification at 22:00 UTC with all failed automatic backups in the last 24 hours. Once a backup has failed, the Cloudback support team will also be notified. If the problem is not related to storage, the team will start investigating as soon as possible and notify you of the results via email. ![Notification email](/files/Fu0OoP1N9YFPzXLz1CWP) Please note that email notifications are only enabled for automatic backups. Cloudback does not send email notifications for manual on-demand backups. ## Notification settings By default, all email notifications are sent to the email address associated with your account in Cloudback's identity system. However, the email address for failed backup notifications can be changed in the Notification Settings page: ![Account notification email](/files/PuEhJ4nWUim9etQ9RQ8H) To change the email address, enter the new email address and click on the `Save` button to save the changes. ## Why can a backup fail? A backup can fail for various reasons. The most common reasons are: 1. **Storage issue**: The storage is not available or the Cloudback application does not have the necessary permissions to write to the storage. 2. **Platform account issue**: The Cloudback application does not have the necessary permissions to access your data or the application is not installed. 3. **Cloudback issue**: There is an issue with the Cloudback application. 4. **Platform outage**: The platform is not available. ### 1. Storage issue The issue related to storage is the most frequent cause of backup failures. Usually, Cloudback loses access to your storage and is unable to upload an archive. Below are typical situations: * An `access token` or `shared signature` has expired * Storage configuration has been changed, but Cloudback config was not updated * Storage provider went offline To troubleshoot a storage issue, please verify your storage settings using the Storages page. Learn more about setting up and managing storage [here](/managing-backups/manage-backup-storage). ### 2. Platform account issue The platform integration may be suspended, uninstalled, or have insufficient permissions. Verify that: * The Cloudback application is still installed and authorized for your account * The repository or workspace is accessible and has not been deleted * Your platform account is not locked or suspended ### 3. Cloudback issue Sometimes the backup software itself can fail. This happens and the Cloudback support team is responsible for restoring the backup, analyzing the cause and making any necessary changes to prevent this from happening in the future. Please [contact us](/troubleshooting-and-support/contact-us) if you believe this is the case. ### 4. Platform outage The platform itself can go offline. Cloudback automatically retries failed backups for transient errors such as rate limits and timeouts. If all retry attempts fail, the backup is marked as failed. ## Learn More * [Instant Notifications](/managing-backups/instant-notifications) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) # Instant Notifications Receive real-time alerts about your backup status in Cloudback through Slack, Discord, or Microsoft Teams with customizable notification triggers and daily summaries. Instant notifications keep you informed about your backup status across all supported platforms. You can set up notifications to receive messages in one of four supported messaging apps: **Slack**, **Discord**, **Microsoft Teams (Office Connector)**, or **Microsoft Teams (Workflow)**. Notifications can be triggered for successful backups, failed backups, or both - and you can also enable a daily summary. Notifications are sent instantly after each backup completes. ![Instant notification example](/files/mpCW10x0xG2Ye53iik8g) ## Configuring Instant Notifications Instant messenger notifications are configured per account. The notification settings UI uses a two-column layout: **Triggers** on the left (what events to notify on) and **Destination** on the right (where to send notifications). To configure instant notifications: 1. Open the **Notification Settings** page from the left sidebar. 2. Choose the account you want to configure notifications for (accounts from all platforms are listed). 3. **Configure Triggers** - Select one or more notification triggers using the checkboxes. All are disabled by default: * **Backup success**: Send a notification when a backup completes successfully * **Backup failure**: Send a notification when a backup fails * **Daily summary**: Send an aggregated summary of all backup results once per day (see [Daily Summary](#daily-summary) below) 4. **Configure Destination** - Set up where notifications are delivered: * Select the messenger you want to use: **Slack**, **Discord**, **Microsoft Teams (Office Connector)**, or **Microsoft Teams (Workflow)** * Enter the **Webhook URL** for the selected messenger (a contextual help link appears below the URL field for each messenger type) * Click **Test** to verify the webhook is working. You should receive a test message in the selected messenger. * Click **Save** to save the changes. 5. Repeat for each account you want to configure. > **Note**: Enabling notifications for a large number of repositories may result in a high volume of messages. ![Set up instant notifications](/files/ljgYSqFMLZIHdPHh5BKu) ## Daily Summary The Daily Summary feature sends a single aggregated notification once per day containing backup statistics for all repositories/workspaces in the selected account. The summary includes: * Total number of backups * Number of successful backups * Number of failed backups When you enable the **Daily summary** checkbox, a time selector appears allowing you to choose the UTC hour (00:00-23:00) when the summary is sent. The default time is 22:00 UTC. ## Supported Messengers Cloudback supports four messenger types for instant notifications: ### Slack Use Slack to get instant notifications about your backups. * Messenger website: * Webhook setup guide: [Sending messages using Incoming Webhooks](https://docs.slack.dev/messaging/sending-messages-using-incoming-webhooks) ![Slack instant notification](/files/h6B6hGwdSFHrWYg7uKwD) ### Microsoft Teams (Office Connector) > **Deprecation Notice**: Microsoft has retired Office 365 Connectors for Microsoft Teams. Existing connectors may stop working. For new setups, use the **Microsoft Teams (Workflow)** option below instead. See [Microsoft's retirement announcement](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook) for details. The Office Connector webhook type uses the legacy MessageCard format for Microsoft Teams notifications. * Messenger website: * Webhook setup guide: [Add incoming webhook](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook) ![MS Teams instant notification](/files/YhV3SC6MIoNxxqW4kLxB) ### Microsoft Teams (Workflow) The Workflow webhook type uses the newer Adaptive Cards format for Microsoft Teams notifications. This is the recommended option for new setups. * Webhook setup guide: [Create incoming webhooks with Workflows for Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/platform/webhooks-and-connectors/how-to/add-incoming-webhook) ### Discord Discord can be used to receive instant notifications about your backups. * Messenger website: * Webhook setup guide: [Intro to Webhooks](https://support.discord.com/hc/en-us/articles/228383668-Intro-to-Webhooks) ![Discord instant notification](/files/lpnOicix2absrXaZoZDz) ## Learn More * [Email Notifications](/managing-backups/email-notifications) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) # Archive Name Pattern Customize your backup archive names in Cloudback using the Scriban templating engine with variables for dates, repository names, and unique identifiers. ## Introduction To enhance the organization and retrieval of backup archives, Cloudback introduces the **Archive Name Pattern** feature. This feature allows you to customize the naming conventions of your backup archives using the **templating engine**, giving you greater control over how your backups are stored and identified. ## Why Customize Archive Names? Customizing your archive names offers several benefits: * **Organization**: Tailor archive names to include specific details like dates, repository names, or account identifiers. * **Easier Retrieval**: Quickly locate the backups you need without sifting through generically named files. * **Consistency**: Establish a standardized naming convention that aligns with your workflow or organizational policies. ## Accessing the Archive Name Pattern Feature You can find the **Archive Name Pattern** option when adding a new storage or editing an existing one. ![Archive name pattern](/files/a8ozSivwcvFv4aNDfrnV) ## How It Works The **Archive Name Pattern** feature uses the **Scriban templating engine** to dynamically generate archive names based on a template you define. By incorporating variables and functions, you can create meaningful and consistent names that make managing your backups more intuitive. > **Note:** If the generated archive name is not unique and conflicts with an existing backup, Cloudback will overwrite the existing archive. ## Scriban Template Examples Below are some templates you can use or customize: ### Account and Repository Names with Date ``` {{ date.now | date.to_string "%Y-%m-%d" }}-{{ context.AccountName }}-{{ context.RepositoryName }} ``` In this example: * `{{ date.now | date.to_string "%Y-%m-%d" }}` inserts the current date in the `YYYY-MM-DD` format. * `{{ context.AccountName }}` inserts the name of your account associated with the backup. * `{{ context.RepositoryName }}` inserts the name of the repository being backed up. *Resulting archive name: `2023-10-05-MyAccount-MyRepository`* ### Including Time in Archive Name ``` {{ date.now | date.to_string "%Y-%m-%d-%H-%M-%S" }}-{{ context.RepositoryName }} ``` *Resulting name: `2023-10-05-14-30-00-MyRepository`* ### UUID ``` {{ math.uuid }} ``` *Resulting name: `f47ac10b-58cc-4372-a567-0e02b2c3d479`* ### Short UUID ``` {{ math.uuid | string.replace "-" "" }} ``` *Resulting name: `f47ac10b58cc4372a5670e02b2c3d479`* ## Scriban Template Variables and Functions The Scriban templating engine offers a range of variables and functions for customization: ### Date and Time Variables * `date.now`: Current date and time in UTC. ### Date Formatting Function * `date.to_string`: Formats a date/time value into a string. *Example:* `{{ date.now | date.to_string "%Y-%m-%d" }}` results in `2023-10-05`. The following table explains the format modifiers: | Format | Result | Description | | ------ | ---------------------------- | ----------------------------------------------------------------------------------------------------------- | | `"%a"` | `"Thu"` | Name of week day in short form of the time | | `"%A"` | `"Thursday"` | Week day in full form of the time | | `"%b"` | `"Sep"` | Month in short form of the time | | `"%B"` | `"September"` | Month in full form of the time | | `"%c"` | `"Thu Sep 12 22:49:27 2013"` | Date and time (%a %b %e %T %Y) | | `"%C"` | `"20"` | Century of the time | | `"%d"` | `"12"` | Day of the month of the time | | `"%D"` | `"09/12/13"` | Date (%m/%d/%y) | | `"%e"` | `"12"` | Day of the month, blank-padded ( 1..31) | | `"%F"` | `"2013-09-12"` | ISO 8601 date (%Y-%m-%d) | | `"%h"` | `"Sep"` | Alias for %b | | `"%H"` | `"22"` | Hour of the time in 24 hour clock format | | `"%I"` | `"10"` | Hour of the time in 12 hour clock format | | `"%j"` | `"255"` | Day of the year (001..366) (3 digits, left padded with zero) | | `"%k"` | `"22"` | Hour of the time in 24 hour clock format, blank-padded ( 0..23) | | `"%l"` | `"10"` | Hour of the time in 12 hour clock format, blank-padded ( 0..12) | | `"%L"` | `"000"` | Millisecond of the time (3 digits, left padded with zero) | | `"%m"` | `"09"` | Month of the time | | `"%M"` | `"49"` | Minutes of the time (2 digits, left padded with zero, e.g., 01, 02) | | `"%n"` | | Newline character (\n) | | `"%N"` | `"000000000"` | Nanoseconds of the time (9 digits, left padded with zero) | | `"%p"` | `"PM"` | Gives AM / PM of the time | | `"%P"` | `"pm"` | Gives am / pm of the time | | `"%r"` | `"10:49:27 PM"` | Long time in 12 hour clock format (%I:%M:%S %p) | | `"%R"` | `"22:49"` | Short time in 24 hour clock format (%H:%M) | | `"%s"` | | Number of seconds since 1970-01-01 00:00:00 +0000 | | `"%S"` | `"27"` | Seconds of the time | | `"%T"` | `"22:49:27"` | Long time in 24 hour clock format (%H:%M:%S) | | `"%u"` | `"4"` | Day of week of the time (from 1 for Monday to 7 for Sunday) | | `"%U"` | `"36"` | Week number of the current year, starting with the first Sunday as the first day of the first week (00..53) | | `"%v"` | `"12-SEP-2013"` | VMS date (%e-%b-%Y) (culture invariant) | | `"%V"` | `"37"` | Week number of the current year according to ISO 8601 (01..53) | | `"%W"` | `"36"` | Week number of the current year, starting with the first Monday as the first day of the first week (00..53) | | `"%w"` | `"4"` | Day of week of the time (from 0 for Sunday to 6 for Saturday) | | `"%x"` | `"09/12/13"` | Preferred representation for the date alone, no time | | `"%X"` | `"22:49:27"` | Preferred representation for the time alone, no date | | `"%y"` | `"13"` | Gives year without century of the time | | `"%Y"` | `"2013"` | Year of the time | ### Context Variables * `context.AccountName`: Name of the platform account associated with the backup (GitHub organization or user, Azure DevOps organization, GitLab group, or Linear workspace slug). * `context.RepositoryName`: Name of the repository being backed up. ### String Functions * `string.replace`: Replaces all occurrences of a string with a substring. *Example:* `{{ math.uuid | string.replace "-" "" }}` removes dashes from a UUID. ### Conditional Logic You can incorporate conditional statements: ``` {{ if context.AccountName == "Admin" }}AdminBackup{{ else }}UserBackup{{ end }} ``` *This will name the archive `AdminBackup` if the account name is "Admin", otherwise `UserBackup`.* ## Scriban Documentation For a complete list of variables and functions, refer to the [Scriban Documentation](https://scriban.github.io/docs/builtins). ## Best Practices When creating custom archive names, consider the following best practices: * **Keep Names Unique**: Ensure archive names are distinct to avoid conflicts and overwriting archives. * **Avoid Illegal Characters**: The name can only contain ASCII letters, digits, and the characters '.', '-', and '\_' (period, hyphen, and underscore). Any other characters in the generated name are automatically replaced with hyphens - they are not rejected. * **Do Not Include `.zip`**: Cloudback automatically appends the `.zip` extension to the evaluated archive name. You do not need to include it in your pattern. * **Consider Sorting**: Start archive names with dates or other sortable elements to improve organization. * **Test**: Use the **Test** feature to validate your templates before applying them. ## FAQ **Q: What happens if I don't specify an Archive Name Pattern?**\ **A:** Cloudback will default to its standard naming convention if no custom pattern is provided. The default naming scheme is "Short UUID" `{{ math.uuid | string.replace "-" "" }}`. **Q: Are there limitations on the length of the archive name?**\ **A:** Yes, most file systems and storage providers have a maximum file name length (often 255 characters). It's best to keep archive names concise. **Q: How do I troubleshoot if the archive name isn't generated correctly?**\ **A:** Use the **Test** button to preview the archive name. If there's an error, double-check your Scriban syntax and ensure all variables are correctly referenced. **Q: Is there a way to reset to the default naming convention?**\ **A:** Yes, simply clear the contents of the **Archive Name Pattern** field, and the system will revert to the default naming scheme. ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Data Deduplication](/managing-backups/data-deduplication) * [Backup Details](/dashboard/backup-details) # Data Restoration Learn how to restore your backups with Cloudback, including downloading archives and restoring to any supported platform. Cloudback provides flexible options for restoring your backed-up repositories: * [**Download Backups**](/data-restoration/download-backups): Download backup archives to your local machine * [**Restoring a Backup**](/data-restoration/restoring-a-backup): Restore your backups to any supported platform * [**Bulk Restore**](/data-restoration/bulk-restore): Restore multiple repositories at once * [**Cross-Platform Restore**](/data-restoration/cross-platform-restore): Restore backups across different platforms * [**GitHub: Restoring Data**](/github/restore): GitHub-specific restore guide including cross-account restore * [**Azure DevOps: Restoring Data**](/azure-devops/restore): Azure DevOps restore guide * [**Linear: Restoring Data**](/linear/restore): Linear restore guide * [**GitLab: Restoring Data**](/gitlab/restore): GitLab restore guide # Download Backups Learn how to download your backups from Cloudback to your local machine, including handling password-protected archives. Cloudback allows you to download backups of your repositories to your local machine. This page will guide you through the process of downloading backups of your repositories. ## Downloading a Backup To download a backup of your repository: 1. Open Cloudback Dashboard and navigate to the repository details page for the repository you want to download a backup for. 2. Open the `Backups` tab. 3. Locate the backup you want to download and click the `Download` icon to start the download. ![Download backup from backups list](/files/tKllKUPOjOZLPZF1Jn0G) ### Backup Download Dialog After clicking the `Download` icon, Cloudback verifies the backup archive is available. If the archive is accessible, a download dialog appears. The dialog behavior depends on the storage type and encryption configuration: **Instant download (Cloudback-managed and compatible storages):** Click `Download now` to start the download directly from the dialog. If the backup is [password-protected](/security-and-compliance/password-protected-archives), you will receive an email with the password after clicking `Download now`. ![Backup download dialog](/files/ouCdrAuTP2Ky9xPULSXf) **Custom encryption with RSA Lockbox:** If the backup is protected by an [RSA Lockbox](/encryption-management/rsa-lockbox) encryption key, the download dialog prompts you to paste your RSA private key (PEM format). Cloudback decrypts the archive password in memory and discards your private key immediately - it is never stored. Enter your private key and click `Download now`. **Customer-managed storages without instant download:** Some customer-managed storage providers do not support instant downloads. In this case, the dialog shows a `Send Password` button - click it to receive the archive password via email, then download the archive directly from your own storage solution. ![Email with backup archive password](/files/Dz9Tco1vThCK6cLJBpnq) ## What if the backup archive file is deleted? There are a few situations where a backup archive cannot be downloaded: * The archive file has been removed from the storage * The archive file has been moved to another location * The storage is not available or is not accessible In any of these cases, you will see an error: `Backup archive not found. Possible reasons: file moved/deleted or storage inaccessible.` ## Learn More * [GitHub Backup Contents](/github/backup-contents) * [Password-Protected Archives](/security-and-compliance/password-protected-archives) * [Encryption Overview](/encryption-management/encryption-overview) * [Archive Name Pattern](/managing-backups/archive-name-pattern) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) # Restoring a Backup Step-by-step guide to restoring your Cloudback backups to GitHub, Azure DevOps, Linear, or GitLab, including cross-platform restore between GitHub and GitLab. Cloudback allows you to restore your backups to any supported platform. You can also perform cross-platform restores between GitHub and GitLab. All restore operations - whether for a single item or multiple items - use the same **Restore Wizard**. The only difference is how you trigger it and how many items are selected. For restoring multiple items at once, see [Bulk Restore](/data-restoration/bulk-restore). ## Platform-Specific Restore Guides For detailed information about what gets restored, platform-specific requirements, and entity mapping for each platform, see: * [GitHub: Restoring Data](/github/restore) - restore application, cross-account restore, source restrictions, restored entities * [Azure DevOps: Restoring Data](/azure-devops/restore) - OAuth authorization, restored entities, limitations * [Linear: Restoring Data](/linear/restore) - empty workspace requirement, OAuth scopes, entity restore order, reference rewriting * [GitLab: Restoring Data](/gitlab/restore) - OAuth scopes, namespace selection, ID mapping, restored entities ## Initiating a Restore There are two ways to start the Restore Wizard: ### From the Repository Details Page Open the Cloudback Dashboard and navigate to the repository/workspace details page. Open the **Backups** tab, find the backup you want to restore, and click the **Restore** icon: ![Restore a backup from backups list](/files/tKllKUPOjOZLPZF1Jn0G) ### From the Dashboard Toolbar On the Cloudback Dashboard, select one or more items using the checkboxes, then click the **Restore** button in the toolbar. Selecting a single item starts a single restore; selecting multiple items starts a [Bulk Restore](/data-restoration/bulk-restore): ![Restore a backup from dashboard](/files/jN57XD2GajxBOCKXZuN3) ## Restore Permissions Backups require only read access, but restores need write access. Cloudback uses **separate integrations** for backup and restore, following the principle of least privilege. Write permissions are requested only when you initiate a restore: {% tabs %} {% tab title="GitHub" %} The [Cloudback Backup Application](https://github.com/apps/cloudback) has read-only access. For restores, you need to install the separate [Cloudback Restore Application](https://github.com/apps/cloudback-restore) which has read and write access. You can uninstall it after the restore is complete. See [GitHub: Restoring Data](/github/restore) for details. {% endtab %} {% tab title="Azure DevOps" %} If this is your first time restoring to an organization, you will be prompted to grant Cloudback write access via a separate OAuth authorization. You can revoke access after the restore is complete. See [Azure DevOps: Restoring Data](/azure-devops/restore) for details. {% endtab %} {% tab title="Linear" %} Linear restore requires a separate OAuth authorization with write permissions (scopes: `read`, `write`, `issues:create`, `comments:create`, `initiative:write`). A popup guides you through authorization when you initiate the restore. > **Important**: The target Linear workspace must be **empty** before restore can proceed - no projects, no custom views, no more than one team, and no labels. Create a new workspace at [linear.app/join](https://linear.app/join) before starting the restore. See [Linear: Restoring Data](/linear/restore) for details. > {% endtab %} {% tab title="GitLab" %} GitLab restore requires a separate OAuth authorization with `api` scope (full read-write access). You will be prompted to authorize when you initiate the restore. See [GitLab: Restoring Data](/gitlab/restore) for details. {% endtab %} {% endtabs %} ## Encrypted Backups If a backup is protected by an [RSA Lockbox](/encryption-management/rsa-lockbox) encryption key, the Restore Wizard includes an additional step that prompts you to paste your RSA private key. Cloudback decrypts the archive password in memory and discards your private key immediately. For bulk restores with multiple encryption providers, the wizard asks for each provider's private key once. Backups using the built-in **Secure Random Key** provider do not require extra input during restore. ## Restore Wizard The Restore Wizard guides you through the same steps regardless of whether you're restoring one item or many. The number of steps depends on whether you're restoring within the same platform or across platforms. ### Azure DevOps and Linear Restore The restore wizard has 3 steps: 1. **Select source**: Choose the backup(s) you want to restore. 2. **Select target**: Choose where to restore. 3. **Restoring**: Monitor the restoration progress. ### GitHub and GitLab Restore GitHub and GitLab restores always include a platform selection step, enabling cross-platform restore between the two. The restore wizard has 4 steps: 1. **Select source**: Choose the backup(s) you want to restore. 2. **Select platform**: Choose the target platform (GitHub or GitLab). 3. **Select target**: Choose the target account/namespace. 4. **Restoring**: Monitor the restoration progress. For details on cross-platform data conversion, see [Cross-Platform Restore](/data-restoration/cross-platform-restore). ### Step 1: Select Source Choose the backup you want to restore from the list of available backups. For bulk restores, you can change the backup snapshot for each item using the dropdown. Click **Next**: ![Select a backup](/files/ik2VmkE7YKAK9RaeTBDW) ### Step 2: Select Target Choose where to restore the backup: {% tabs %} {% tab title="GitHub" %} Enter the target GitHub account name and click **Start Restore**. The repository name and visibility are carried over from the backup automatically. {% endtab %} {% tab title="Azure DevOps" %} Enter the target organization name and project name, then click **Start Restore**. > **Note**: A new repository will be created in the target project. You cannot restore to an existing repository. > {% endtab %} {% tab title="Linear" %} Follow the guided steps to authorize the Cloudback Restore app in the target workspace via OAuth. Cloudback verifies the workspace is empty before proceeding. If the workspace has existing data, you will need to create a new empty workspace first. There is no manual team selection - Cloudback uses the workspace's existing team automatically. {% endtab %} {% tab title="GitLab" %} Select the target namespace (personal account or group) by clicking on it from the list of connected GitLab accounts. The project name is carried over from the backup automatically. {% endtab %} {% endtabs %} ![Select repository for restore](/files/WBu0g2g4vGf1qBGzLXnH) ### Step 3: Restoring The restore process starts and you can monitor the progress. You can wait for completion or return to the dashboard - the restore continues in the background. Once complete, you will see a notification with the restore status. {% tabs %} {% tab title="GitHub" %} The restoration includes source code (via `git push --mirror`), branches, tags, and backed-up metadata: issues (with issue types and sub-issues), issue comments, milestones, labels, collaborators, commit comments, unmerged pull requests, projects (legacy and ProjectV2), releases (with assets), webhooks, and repository settings (description, homepage, merge methods, topics). > **Note**: Merged pull requests are skipped during restore. Wiki pages are not restored. > {% endtab %} {% tab title="Azure DevOps" %} The restoration includes source code (via `git push --mirror`), pull requests with review threads and comments, labels, and attachments. See [Azure DevOps: Restoring Data](/azure-devops/restore) for details and limitations. {% endtab %} {% tab title="Linear" %} The restoration includes teams, labels, projects (with milestones and external links), cycles, initiatives, issues (with parent-child hierarchy), comments (with threading), documents, attachments, custom views, templates, issue relations, project/initiative updates, and embedded files (re-uploaded with URL rewriting). See [Linear: Restoring Data](/linear/restore) for the full entity list and restore order. {% endtab %} {% tab title="GitLab" %} The restoration includes the Git repository (via `git push --mirror`), project settings, labels, milestones, issues (with time tracking), issue comments, issue links, merge requests, MR comments, and boards. See [GitLab: Restoring Data](/gitlab/restore) for details. {% endtab %} {% endtabs %} ## Viewing the Restored Repository Once complete, view the restored repository by opening the repository details page, clicking the **Restores** tab, and clicking the repository link: ![Open restored repository from restores list](/files/yBv61iN8y0RhvDQP9vq6) ## Learn More * [Bulk Restore](/data-restoration/bulk-restore) * [GitHub: Restoring Data](/github/restore) * [Azure DevOps: Restoring Data](/azure-devops/restore) * [Linear: Restoring Data](/linear/restore) * [GitLab: Restoring Data](/gitlab/restore) * [Cross-Platform Restore](/data-restoration/cross-platform-restore) * [Encryption Overview](/encryption-management/encryption-overview) * [Download Backups](/data-restoration/download-backups) # Bulk Restore Restore multiple items from backup in just a few clicks using Cloudback's Bulk Restore feature, with cross-platform support for GitHub and GitLab. The **Bulk Restore** feature allows you to restore multiple repositories or workspaces at once, making disaster recovery and migration faster and easier. This guide walks you through the bulk restore process for all supported platforms. Cross-platform restore between GitHub and GitLab is also supported. ## Overview Bulk Restore simplifies the process of restoring multiple items from backup in just a few clicks. The feature uses a step-by-step wizard to guide you through selecting and restoring backups. To restore a single item, use the [Restoring a Backup](/data-restoration/restoring-a-backup) guide instead. > **Important**: All selected items must be from the **same platform**. If you select items from multiple platforms, the operation will be blocked with an error message asking you to select from a single platform. For Linear, all selected items must also be from the same workspace. ## When to Use Bulk Restore * Restoring several repositories after data loss or corruption * Migrating repositories to a new account or organization * Migrating repositories from several accounts to a single account * Cross-platform migration between GitHub and GitLab * Testing recovery scenarios in staging or QA environments ## How to Perform a Bulk Restore ### Same-Platform Restore #### Step 1: Select Source 1. Go to the **Dashboard** in Cloudback. 2. Use the checkboxes to select the repositories/workspaces you want to restore. 3. Click the **Restore** button in the toolbar. Only items with existing backups will be available for restoration. ![Trigger restore button](/files/jN57XD2GajxBOCKXZuN3) In the Bulk Restore wizard, review the list of selected items and their available backup dates. By default, the latest backup for each item is selected. You can change the backup snapshot for each item using the dropdown. Click **Next** to continue. ![Review selected backups](/files/IPonBJHTNOCnxyKv1EL5) #### Step 2: Select Target Enter the target location where the items will be restored. The target selection varies by platform - see the platform tabs in [Restoring a Backup](/data-restoration/restoring-a-backup#step-2-select-target) for details on each platform's target options. #### Step 3: Restoration Progress You will see a progress dashboard showing each item's restore status: * **Succeeded** - Restore completed successfully * **In progress** - Restore currently running * **Queued** - Restore is waiting to start * **Failed** - Restore encountered an error You can safely close the progress window at any time; the restore operations continue in the background. Each restore is available for review in the **Restores** tab of the repository/workspace details page. ### Cross-Platform Restore For restoring between GitHub and GitLab, the wizard adds an additional platform selection step: 1. **Select Source**: Choose backups to restore (same as above) 2. **Select Platform**: Choose the target platform (GitHub or GitLab) 3. **Select Target**: Choose the target account/namespace 4. **Restoring**: Monitor progress For details on how data is converted between platforms, see [Cross-Platform Restore](/data-restoration/cross-platform-restore). ## Troubleshooting **Restore failed?** Click on the failed item in the progress list to view error details and recommended actions. **Not all repositories listed?** Ensure you have the correct account selected and that backups exist for the desired items. **Need to restore to different accounts or projects?** All selected items are restored to a single target location. For restoring to different accounts or projects, perform separate bulk restores. **Want to restore a single repository?** Use the [Restoring a Backup](/data-restoration/restoring-a-backup) guide for individual restores. ## Learn More * [Restoring a Backup](/data-restoration/restoring-a-backup) * [GitHub: Restoring Data](/github/restore) * [Cross-Platform Restore](/data-restoration/cross-platform-restore) * [Repository Details](/dashboard/repository-details) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) # Cross-Platform Restore Restore data between GitHub and GitLab with Cloudback's cross-platform restore feature, using the entity conversion system for bidirectional migration. Cloudback supports **bidirectional cross-platform restore** between GitHub and GitLab. You can restore a GitHub backup into a GitLab project, or a GitLab backup into a GitHub repository - with automatic data format conversion. ## Supported Entities | Entity | GitHub → GitLab | GitLab → GitHub | Notes | | ---------------------------------- | :-------------: | :-------------: | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Repository (Git)** | ✓ | ✓ | All branches, tags, refs pushed via `git push --mirror` | | **Issues** | ✓ | ✓ | Title, body, state, dates, assignee | | **Labels** | ✓ | ✓ | Name, color, description | | **Milestones** | ✓ | ✓ | Title, description, state, dates | | **Issue Comments** | ✓ | ✓ | Body, author, dates | | **Pull Requests / Merge Requests** | ✓ | ✓ | Title, body, state, branches, draft status | | **PR/MR Comments** | Partial | - | GitHub→GitLab: PR comments are included in the issue comments file and may be restored as issue notes. GitLab→GitHub: MR notes are extracted but not written to the GitHub output. | | **Boards** | ✓ | ✓ | Column structure and issue assignments | | **Time Tracking** | - | Appended\* | GitLab-specific; appended to issue body on GitHub | | **Weight** | - | Appended\* | GitLab-specific; appended to issue body on GitHub | | **Health Status** | - | Appended\* | GitLab-specific; appended to issue body on GitHub | | **Confidential Flag** | - | Appended\* | GitLab-specific; appended to issue body on GitHub | *\* GitLab-specific fields that have no GitHub equivalent are preserved by appending them as a metadata block at the end of the issue body.* ## GitLab-Specific Fields in GitHub When restoring GitLab data to GitHub, fields without a direct equivalent are appended to the issue body as a formatted metadata block: ```markdown [Original issue body] --- **Weight:** 5 | **Health Status:** On Track | **Start Date:** 2024-01-01 | **Due Date:** 2024-12-31 | **Confidential:** Yes | **Time Estimate:** 3600s | **Time Spent:** 1800s ``` This ensures no data is lost, even when the target platform doesn't support the field natively. ## How to Perform a Cross-Platform Restore ### GitHub → GitLab 1. Navigate to a **GitHub repository** in the Cloudback dashboard 2. Open the **Backups** tab and select a backup 3. Click **Restore** 4. In the restore wizard, select **GitLab** as the target platform 5. Select the target namespace (personal account or group) from the list of connected accounts - clicking on the namespace starts the restore immediately 6. If no GitLab account is connected, click **Connect New GitLab Account** to authorize via OAuth first ### GitLab → GitHub 1. Navigate to a **GitLab project** in the Cloudback dashboard 2. Open the **Backups** tab and select a backup 3. Click **Restore** 4. In the restore wizard, select **GitHub** as the target platform 5. Enter the target GitHub account name 6. Click **Start Restore** - you will be guided through installing the GitHub restore app if needed ## Learn More * [GitLab: Getting Started](/gitlab/installation-guide) - Connect your GitLab account * [GitLab: Backup Contents](/gitlab/backup-contents) - What data is in GitLab backups * [GitLab: Restoring Data](/gitlab/restore) - Same-platform GitLab restore * [Restoring a Backup](/data-restoration/restoring-a-backup) - General restore documentation * [GitHub Backup Contents](/github/backup-contents) - What data is in GitHub backups # Automation Discover Cloudback's automation tools and APIs for programmatically managing repository backups and integrating with your existing workflows. Cloudback provides automation tools for programmatic management of your backup configurations, enabling integration with CI/CD pipelines and infrastructure-as-code workflows. ## Automation Tools * [Terraform Provider](/automation/terraform-provider) - Manage backup definitions using Terraform * [Operations API](/automation/operations-api) - RESTful API for programmatic backup management * [MCP Server](/automation/mcp-server) - Manage backups from AI assistants via the Model Context Protocol # Terraform Provider Explore the Cloudback Terraform Provider, an Infrastructure as Code (IaC) tool that enables automated management of backup configurations through Terraform. The Cloudback Terraform Provider (`terraform-provider-cloudback`) is an Infrastructure as Code (IaC) tool that enables automated management of Cloudback backup configurations through [Terraform](https://www.terraform.io/). ## Overview This provider allows users to manage backup definitions for all supported platforms using Cloudback's [Operations API](/automation/operations-api) through Terraform configurations. It provides a smooth integration between Terraform and the Cloudback platform. ## Features * Automated backup definition configuration for repositories * Infrastructure as Code approach to backup management * Multi-platform support * Support for Terraform-based workflow automation ## Prerequisites Before you begin, ensure that you have the following: * **Terraform Installed**: Version 1.0 or later is recommended. * **Cloudback Account**: An active account with appropriate permissions to create and manage backup resources. * **API Key**: Your API key for Cloudback's API. You can create one at the [API Keys](https://app.cloudback.it/apikeys) page in the Cloudback dashboard. * **Network Access**: Ensure that your environment can reach Cloudback's endpoints: `https://app.cloudback.it/ops/` ## Usage ### Provider Configuration ```hcl terraform { required_providers { cloudback = { source = "cloudback/cloudback" } } } provider "cloudback" { api_key = "your-api-key" # Replace with your API key, see https://app.cloudback.it/apikeys } ``` **Note**: You can provide your API key either directly in the configuration or through the `CLOUDBACK_API_KEY` environment variable: ```bash export CLOUDBACK_API_KEY="your-api-key" ``` ### Resource: Backup Definition Backup definitions are the primary resources managed by Cloudback. They represent the configuration for a specific backup subject (repository, project, or workspace). #### GitHub Example ```hcl resource "cloudback_backup_definition" "github_demo" { platform = "GitHub" account = "cloudback" subject_name = "demo-repository" subject_type = "Repository" settings = { enabled = true schedule = "Daily at 9 pm" storage = "Cloudback EU" retention = "Last 30 days" } } ``` #### Azure DevOps Repository Example ```hcl resource "cloudback_backup_definition" "azure_devops_repo" { platform = "AzureDevOps" account = "my-organization" subject_name = "my-project/demo-repository" subject_type = "Repository" settings = { enabled = true schedule = "Daily at 9 pm" storage = "Cloudback EU" retention = "Last 30 days" } } ``` #### Azure DevOps Project Example ```hcl resource "cloudback_backup_definition" "azure_devops_project" { platform = "AzureDevOps" account = "my-organization" subject_name = "my-project" subject_type = "Project" settings = { enabled = true schedule = "Daily at 9 pm" storage = "Cloudback EU" retention = "Last 30 days" } } ``` #### GitLab Example ```hcl resource "cloudback_backup_definition" "gitlab_demo" { platform = "GitLab" account = "my-group" subject_name = "my-project" subject_type = "Project" settings = { enabled = true schedule = "Daily at 9 pm" storage = "Cloudback EU" retention = "Last 30 days" } } ``` #### Linear Example ```hcl resource "cloudback_backup_definition" "linear_demo" { platform = "Linear" account = "my-workspace" subject_name = "my-workspace" subject_type = "Workspace" settings = { enabled = true schedule = "Daily at 9 pm" storage = "Cloudback EU" retention = "Last 30 days" } } ``` ### Attributes | Attribute | Type | Required | Description | | -------------- | ------ | -------- | ----------------------------------------------------------------- | | `platform` | string | Yes | The platform. Values: `GitHub`, `AzureDevOps`, `GitLab`, `Linear` | | `account` | string | Yes | The account or organization name | | `subject_name` | string | Yes | The backup subject name (see format below) | | `subject_type` | string | Yes | The backup subject type: `Repository`, `Project`, or `Workspace` | | `settings` | object | Yes | The backup configuration settings | #### Subject Name Format | Platform | Subject Type | Format | Example | | ------------ | ------------ | ------------------------------ | ---------------------- | | GitHub | Repository | `repository-name` | `demo-repository` | | Azure DevOps | Repository | `project-name/repository-name` | `my-project/demo-repo` | | Azure DevOps | Project | `project-name` | `my-project` | | GitLab | Project | `project-name` | `my-project` | | Linear | Workspace | `workspace-name` | `my-workspace` | #### Settings Object | Attribute | Type | Required | Description | | ----------- | ------ | -------- | ---------------------------------------------------------------------------------- | | `enabled` | bool | No | Whether automated backup is enabled | | `schedule` | string | No | Backup schedule name ([see list](https://app.cloudback.it/schedules)) | | `storage` | string | No | Storage location name ([see list](https://app.cloudback.it/storages)) | | `retention` | string | No | Retention policy: `Last 30 days`, `Last 90 days`, `Last 180 days`, `Last 360 days` | ### Backwards Compatibility The `repository` attribute is still supported as an alias for `subject_name` with `subject_type` defaulting to `Repository`. However, using `subject_name` and `subject_type` is recommended for clarity, especially when working with Azure DevOps projects. ```hcl # Legacy format (still supported for repositories) resource "cloudback_backup_definition" "legacy_example" { platform = "GitHub" account = "cloudback" repository = "demo-repository" # Alias for subject_name with subject_type="Repository" settings = { enabled = true } } ``` ## Documentation For detailed documentation and examples, visit the [official repository](https://github.com/cloudback/terraform-provider-cloudback). ## References * [GitHub Repository](https://github.com/cloudback/terraform-provider-cloudback) * [Terraform Registry](https://registry.terraform.io/providers/cloudback/cloudback) * [Cloudback Operations API](/automation/operations-api) * [GitHub Installation Guide](/github/installation-guide) * [Azure DevOps Installation Guide](/azure-devops/installation-guide) * [Linear Installation Guide](/linear/installation-guide) * [GitLab Installation Guide](/gitlab/installation-guide) * [Terraform Documentation](https://developer.hashicorp.com/terraform/docs) # Operations API Learn how to manage Cloudback backup definitions programmatically using the Operations API for automated backup configuration across supported platforms. ## Overview The Cloudback Operations API allows users to manage backup definitions programmatically. It provides a RESTful interface to update backup definitions for repositories across all supported platforms. ## Features * Automated backup definition configuration for repositories * Programmatic management of backup configurations * Multi-platform support ## Prerequisites Before you begin, ensure that you have the following: * **Cloudback Account**: An active account with appropriate permissions to create and manage backup resources. * **API Key**: Your API key for Cloudback's API. You can create one at the [API Keys](https://app.cloudback.it/apikeys) page in the Cloudback dashboard. * **Network Access**: Ensure that your environment can reach Cloudback's endpoints: `https://app.cloudback.it/ops/` ## API Reference ### Get Backup Definition Retrieve the current backup configuration for a repository. **Endpoint:** `POST /ops/definition/get` #### GitHub Example ```http POST https://app.cloudback.it/ops/definition/get Content-Type: application/json X-API-Key: your-api-key { "platform": "GitHub", "account": "cloudback", "subjectName": "demo-repository", "subjectType": "Repository" } ``` #### Azure DevOps Repository Example ```http POST https://app.cloudback.it/ops/definition/get Content-Type: application/json X-API-Key: your-api-key { "platform": "AzureDevOps", "account": "my-organization", "subjectName": "my-project/demo-repository", "subjectType": "Repository" } ``` #### Azure DevOps Project Example ```http POST https://app.cloudback.it/ops/definition/get Content-Type: application/json X-API-Key: your-api-key { "platform": "AzureDevOps", "account": "my-organization", "subjectName": "my-project", "subjectType": "Project" } ``` #### GitLab Example ```http POST https://app.cloudback.it/ops/definition/get Content-Type: application/json X-API-Key: your-api-key { "platform": "GitLab", "account": "my-group", "subjectName": "my-project", "subjectType": "Project" } ``` #### Linear Example ```http POST https://app.cloudback.it/ops/definition/get Content-Type: application/json X-API-Key: your-api-key { "platform": "Linear", "account": "my-workspace-key", "subjectName": "my-workspace", "subjectType": "Workspace" } ``` #### Response ```json HTTP/1.1 200 OK { "platform": "GitHub", "account": "cloudback", "backupSubjectName": "demo-repository", "backupSubjectType": "Repository", "settings": { "enabled": true, "schedule": "Daily at 9 pm", "storage": "Cloudback EU", "retention": "Last 30 days" } } ``` ### Update Backup Definition Update the backup configuration for a repository. **Endpoint:** `POST /ops/definition/update` #### GitHub Example ```http POST https://app.cloudback.it/ops/definition/update Content-Type: application/json X-API-Key: your-api-key { "platform": "GitHub", "account": "cloudback", "subjectName": "demo-repository", "subjectType": "Repository", "settings": { "enabled": true, "schedule": "Daily at 9 pm", "storage": "Cloudback EU", "retention": "Last 30 days" } } ``` #### Azure DevOps Example ```http POST https://app.cloudback.it/ops/definition/update Content-Type: application/json X-API-Key: your-api-key { "platform": "AzureDevOps", "account": "my-organization", "subjectName": "my-project/demo-repository", "subjectType": "Repository", "settings": { "enabled": true, "schedule": "Daily at 9 pm", "storage": "Cloudback EU", "retention": "Last 30 days" } } ``` #### GitLab Example ```http POST https://app.cloudback.it/ops/definition/update Content-Type: application/json X-API-Key: your-api-key { "platform": "GitLab", "account": "my-group", "subjectName": "my-project", "subjectType": "Project", "settings": { "enabled": true, "schedule": "Daily at 9 pm", "storage": "Cloudback EU", "retention": "Last 30 days" } } ``` #### Linear Example ```http POST https://app.cloudback.it/ops/definition/update Content-Type: application/json X-API-Key: your-api-key { "platform": "Linear", "account": "my-workspace-key", "subjectName": "my-workspace", "subjectType": "Workspace", "settings": { "enabled": true, "schedule": "Daily at 9 pm", "storage": "Cloudback EU", "retention": "Last 30 days" } } ``` #### Response ```json HTTP/1.1 200 OK { "platform": "GitHub", "account": "cloudback", "backupSubjectName": "demo-repository", "backupSubjectType": "Repository", "settings": { "enabled": true, "schedule": "Daily at 9 pm", "storage": "Cloudback EU", "retention": "Last 30 days" } } ``` ## Request Data Model | Field | Type | Required | Description | | ------------- | ------ | -------- | --------------------------------------------------------------------------------- | | `platform` | string | Yes | The platform. Values: `GitHub`, `AzureDevOps`, `GitLab`, `Linear` | | `account` | string | Yes | The account or organization name | | `subjectName` | string | Yes | The name of the backup subject (see below) | | `subjectType` | string | Yes | The type of backup subject: `Repository`, `Project`, or `Workspace` (Linear only) | | `settings` | object | Yes\* | The backup configuration settings (\*required for update) | ### Subject Name Format The `subjectName` format varies by platform: | Platform | Subject Type | Format | Example | | ------------ | ------------ | ------------------------------ | ---------------------- | | GitHub | Repository | `repository-name` | `demo-repository` | | Azure DevOps | Repository | `project-name/repository-name` | `my-project/demo-repo` | | Azure DevOps | Project | `project-name` | `my-project` | | GitLab | Project | `project-name` | `my-project` | | Linear | Workspace | `workspace-name` | `my-workspace` | ### Settings Object | Field | Type | Required | Description | | ----------- | ------- | -------- | ---------------------------------------------------------------------------------- | | `enabled` | boolean | No | Whether automated backup is enabled | | `schedule` | string | No | Backup schedule name (see [schedules](https://app.cloudback.it/schedules)) | | `storage` | string | No | Storage location name (see [storages](https://app.cloudback.it/storages)) | | `retention` | string | No | Retention policy: `Last 30 days`, `Last 90 days`, `Last 180 days`, `Last 360 days` | ## Response Data Model | Field | Type | Description | | ------------------- | ------ | --------------------------------------------------------------- | | `platform` | string | The platform (`GitHub`, `AzureDevOps`, `GitLab`, or `Linear`) | | `account` | string | The account or organization name | | `backupSubjectName` | string | The name of the backup subject | | `backupSubjectType` | string | The type: `Repository`, `Project`, or `Workspace` (Linear only) | | `settings` | object | The current backup configuration | ## Error Responses | Status Code | Description | | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | | 400 Bad Request | Invalid request format or parameters | | 401 Unauthorized | API key is missing or invalid | | 402 Payment Required | Plan limit exceeded | | 404 Not Found | Reserved for repository not found cases; in practice, account not found and definition not found errors are currently returned as `400 Bad Request` | | 422 Unprocessable Entity | Validation error (e.g., schedule not found) | ### Error Response Body For most errors (400, 404, 422), the response body contains the error message as a plain JSON string. The 401 Unauthorized response has an empty body. ```json "Account not found" ``` For 402 Payment Required, the response uses the [RFC 7807](https://datatracker.ietf.org/doc/html/rfc7807) Problem Details format: ```json { "type": "https://httpstatuses.org/402", "title": "Plan Limit Exceeded", "status": 402, "detail": "The plan limit has been exceeded for this account" } ``` ## Backwards Compatibility For backwards compatibility, the `repository` field is still accepted in requests as an alias for `subjectName`. If both are provided, `subjectName` takes precedence. If `subjectType` is not provided, it defaults to `Repository`. ```http # Legacy format (still supported) { "platform": "GitHub", "account": "cloudback", "repository": "demo-repository" } # Equivalent modern format { "platform": "GitHub", "account": "cloudback", "subjectName": "demo-repository", "subjectType": "Repository" } ``` ## Platform-Specific Notes ### GitHub * `account`: GitHub username or organization name * `subjectName`: Repository name * `subjectType`: Always `Repository` ### Azure DevOps * `account`: Azure DevOps organization name * `subjectName`: For repositories use `project/repository` format; for projects use just the project name * `subjectType`: Use `Repository` for repository backups, `Project` for project-level backups * Ensure the Azure DevOps organization has Cloudback authorized ### GitLab * `account`: GitLab group name or personal namespace * `subjectName`: Project name * `subjectType`: Always `Project` ### Linear * `account`: Linear workspace key (the short identifier for the workspace) * `subjectName`: Linear workspace name * `subjectType`: Always `Workspace` * Each Linear workspace is backed up as a single unit; the `Workspace` subject type is unique to Linear ## References * [MCP Server](/automation/mcp-server) * [Terraform Provider](/automation/terraform-provider) * [GitHub Installation Guide](/github/installation-guide) * [Azure DevOps Installation Guide](/azure-devops/installation-guide) * [Linear Installation Guide](/linear/installation-guide) * [GitLab Installation Guide](/gitlab/installation-guide) # MCP Server Manage Cloudback backup definitions, storages, schedules, and retention policies from AI assistants like Claude Code, Claude Desktop, Cursor, and VS Code. Want to manage Cloudback from your AI chat? Connect the Cloudback MCP server to Claude Code, Claude Desktop, Cursor, VS Code, or any other MCP-compatible client and change schedules, storages, and retention policies just by asking. ![Cloudback MCP Server in Visual Studio Code](/files/0EOiF2bYv49weAizUKa3) ## Quick setup You need Docker installed and an MCP-compatible client. You can connect multiple accounts across different platforms in a single setup — each account uses its own API key. ### 1. Create API keys Open the [API Keys page](https://app.cloudback.it/apikeys) and create an Operations API key for **each account** you want the assistant to manage. You can configure as many accounts as you like — one key per account. ### 2. Create `appsettings.json` Save this file anywhere on your machine (for example, at `~/cloudback-mcp/appsettings.json`). You'll point the container at it in the next step. ```json { "OpsApi": { "BaseUrl": "https://app.cloudback.it/", "Account": { "1": "GitHub::your-org::your-api-key", "2": "GitLab::your-group::your-api-key" } } } ``` Add one entry per account you want to expose. Each entry's value is `Platform::Account::ApiKey`, and the keys (`1`, `2`, ...) just need to be unique. Supported platforms (case-insensitive): `GitHub`, `AzureDevOps`, `GitLab`, `Linear`. ### 3. Register the server with your MCP client In VS Code, open (or create) `.vscode/mcp.json` in your workspace — or your user-level `mcp.json` — and paste: ```json { "servers": { "cloudback-ops": { "command": "docker", "args": [ "run", "-i", "--rm", "-v", "/absolute/path/to/appsettings.json:/app/appsettings.json:ro", "myrtlelabs/cloudback-mcp:latest" ], "type": "stdio" } } } ``` Replace `/absolute/path/to/appsettings.json` with the full path to the file you created in step 2. The same `docker run` invocation works with Claude Code, Claude Desktop, Cursor, and any other stdio MCP client — check your client's docs for where to put its MCP config. Reload the client and you're done. ## Typical prompts Once connected, ask things like: * *"List my Cloudback accounts."* * *"What backup definitions are enabled in my GitHub account?"* * *"Switch every repo with `prod` in the name to daily backups at 3 AM UTC."* * *"Create a new schedule that runs at 2 AM every day and make it the default."* * *"Change the retention policy to `Keep 30 days` for all GitLab definitions using the `S3-main` storage."* * *"Show me which storages are configured for my Linear workspace and delete the old `S3-test` one."* * *"Update my account defaults: timezone `Europe/Berlin`, default schedule `Daily at 2 AM`."* ## Troubleshooting * **`No accounts configured`** — the `appsettings.json` mount is wrong. Double-check the host path after `-v` and that it maps to `/app/appsettings.json` inside the container. * **`No API key configured for platform '...' and account '...'`** — the platform/account the assistant tried to use isn't in your `appsettings.json`. Ask it to list configured accounts first; lookup is case-insensitive but typos still fail. * **Client shows a protocol error, or nothing happens** — the MCP client must use the stdio transport. Don't wrap or redirect stdout; server logs go to stderr. ## References * [Operations API](/automation/operations-api) — the underlying HTTP API the server wraps * [Terraform Provider](/automation/terraform-provider) * [Cloudback API Keys](https://app.cloudback.it/apikeys) * [`myrtlelabs/cloudback-mcp` on Docker Hub](https://hub.docker.com/r/myrtlelabs/cloudback-mcp) # Dashboard Overview of the Cloudback dashboard interface for managing backups, monitoring status, and accessing backup details. The Cloudback dashboard provides a centralized interface to manage and monitor all your backups across all your connected accounts. ## Dashboard Pages * [Dashboard Overview](/dashboard/dashboard-overview) - Navigate the main dashboard interface * [Repository Details](/dashboard/repository-details) - View and manage individual repository settings * [Backup Details](/dashboard/backup-details) - Examine backup contents and metadata * [Backup Status Badge](/dashboard/backup-status-badge) - Add backup status badges to your repositories * [User Roles](/dashboard/user-roles) - Manage user access and permissions # Dashboard Overview Explore the Cloudback Dashboard - your central hub for viewing repositories, triggering backups, and monitoring backup status. Cloudback Dashboard is the central place where you can view your repositories, trigger backups, and view backup status. The dashboard provides an overview of all your repositories across all connected accounts. The dashboard is available for all authenticated users at the following URL: . To access the dashboard from other application pages, click on the Dashboard link in the left sidebar. ## About the Dashboard Cloudback displays only the repositories it has access to. If you want to back up a repository that is not listed in the dashboard, you need to connect the appropriate account: * **GitHub**: Install the Cloudback application from the [GitHub Marketplace](https://github.com/apps/cloudback/installations/select_target) or by clicking on Manage GitHub Installations in the user menu in the top right corner of the dashboard. * **Azure DevOps**: Connect your organization from the [Microsoft Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/myrtlelabs-sas.cloudback). * **Linear**: Click **Add Account** in the left sidebar and select **Linear** to connect your workspace via OAuth. * **GitLab**: Click **Add Account** in the left sidebar and select **GitLab** to connect your account via OAuth. If the Cloudback application is already installed but a repository is not visible on the Dashboard, you need to grant access to the repository using the installation management page (GitHub) or verify your account permissions (other platforms). Please note that to automatically back up a repository, a subscription plan must be active for the account where the repository is located. ## Dashboard Layout The dashboard displays your repositories, projects, or workspaces in a table format, allowing you to quickly view and manage them. Each platform has its own dashboard view accessible from the left sidebar. ![Dashboard table view](/files/x2t8FvQf7OFpSpf7W7uw) Each row in the table contains the following information: 1. **Select**: Checkbox to select the item. You can select multiple items to perform bulk operations such as triggering backups, modifying backup schedules, etc. Learn more about [Bulk Operations](/managing-backups/bulk-operations). 2. **Account**: The account or organization name. 3. **Repository** (GitHub) / **Project** (GitLab) / **Name** (Azure DevOps, Linear): The repository, project, or workspace name (clickable to view details). 4. **Type** (Azure DevOps and Linear): Shows the item type (e.g., "Project", "Repository", "Workspace"). 5. **State**: Badge showing "Scheduled", "Not scheduled", "Restore only", or "Not accessible". 6. **Schedule**: The backup schedule name (e.g., "Daily at 9 pm"). 7. **Storage**: The storage where backups are stored. 8. **Retention**: How long backups are kept. 9. **Backup**: Status of the last backup attempt (e.g., "Succeeded", "Failed", "In Progress"). 10. **Last Run**: Time since the last successful backup (e.g., "2 hours ago") or "-" if no backup has run yet. ## Toolbar Features The toolbar above the table provides: * **Search bar**: Find items by name * **Filter toggle**: Show/hide filter panel * **Reset**: Clear all filters and search * **Export CSV**: Export the current filtered view as a CSV file * **Trigger**: Trigger backups for selected items * **Restore**: Start bulk restore for selected items * **Edit**: Modify settings for selected items ## Platform Switching Use the left navigation menu to switch between platforms. Click on your platform in the sidebar to view items from that platform. Each platform displays all items from connected accounts. The dashboard updates in real-time - when backups or restores complete, the status updates automatically without needing to refresh the page. ## Search and Filter Click the **filter icon** in the toolbar to filter by various criteria. **Common filters (all platforms):** * **Account**: Filter by organization or account name * **Schedule**: Filter by backup schedule * **Storage**: Filter by storage location * **Status**: Filter by backup status (Scheduled, Not scheduled, Restore only) **Azure DevOps additional filters:** * **Type**: Filter by type (Project or Repository) * **Project**: Filter by Azure DevOps project name ## Platform Differences ### GitHub GitHub backups are repository-based. Each row represents a single repository. * **Repository column**: Shows the repository name (e.g., `my-repository`) * **Additional info**: Shows whether the repository is Private or Public ### Azure DevOps Azure DevOps supports backing up both projects and individual repositories. Each row represents either a project or a repository. * **Type column**: Shows "Project" or "Repository" * **Name column**: * For projects: Shows the project name (e.g., `my-project`) * For repositories: Shows the project and repository name (e.g., `my-project/my-repository`) ### GitLab GitLab backups are project-based. Each row represents a single GitLab project. * **Project column**: Shows the project name with avatar * **Account types**: Personal namespace or group ### Linear Linear backups are workspace-based. Each row represents an entire Linear workspace. * **Workspace column**: Shows the workspace name with logo * **Name column**: Shows the backup definition name * **Type column**: Shows the item type (e.g., "Workspace") * **Scope**: Each backup covers the entire workspace (issues, projects, documents, cycles, etc.) ## Learn More * [Repository Details](/dashboard/repository-details) * [Backup Details](/dashboard/backup-details) * [User Roles](/dashboard/user-roles) * [Bulk Operations](/managing-backups/bulk-operations) # Repository Details View and manage detailed information about your repository backups in Cloudback, including settings, statistics, backup history, and restore options. Works across all supported platforms. Repository details page shows the details of a repository. It shows the repository owner, name, and different settings associated with the repository like backup schedule, backup storage, and backup retention policy. This is the place where you can manage the repository settings, view the backup statistics, or start the download or restore of the backup. ## Page Overview The repository details page consists of the header and three tabs: Overview, Backups, and Restores. The header shows the repository owner and name. Also, it gives quick access to the backup and restore actions. The `Backup now` button allows you to start a manual backup for the repository. The `Restore now` button allows you to restore the repository to the selected destination based on the backup of your choice. ![Repository details page](/files/pLboLc1bVGq2sXSPa8v8) ### Overview Tab The overview tab shows the repository settings like the backup schedule, backup storage, and backup retention policy. It also shows the backup statistics like the backup time and the size of the backup. The overview tab also shows the backup status badge, which indicates the status of the last backup. The overview tab consists of the following sections: #### Settings This section displays the repository settings like the backup schedule, backup storage, and backup retention policy. You can change each setting by choosing the appropriate option from the dropdown and clicking the `Save` button. Please note that the button appears only when you change the setting. Also, you can enable or disable the repository automatic backup by toggling the `Scheduled` switch and clicking the `Save` button. The `Get badge URL` button allows you to get the backup status badge, which you can use to embed the badge in your website. You can learn more about the backup status badge [here](/dashboard/backup-status-badge). The Settings section also shows the **Next backup** countdown, which indicates how long until the next scheduled backup will run for this repository. Although the backup schedule, backup storage, and backup retention policy are set at the repository level, you can override these settings for multiple repositories using the bulk operations. You can learn more about the bulk operations [here](/managing-backups/bulk-operations). #### Statistics Statistics section shows the backup statistics like the backup time and the size of the backup. Both charts show the data for a selected period. You can change the period by choosing the appropriate option from the dropdown. The first chart shows the backup time for the selected period. Each bar on the chart represents backup time, and the horizontal axis represents the date. The second chart shows the size of the backup for the selected period. Each bar on the chart represents the size of the backup, and the horizontal axis represents the backup date. #### Last backup This section contains information about the last backup, if there are any. It shows the general backup information like its status, time, archive size, deduplication status, storage, and link to the repository. Also, it shows the statistics of the metadata collected in the backup. The metadata items shown depend on the platform. See [Backup Details](/dashboard/backup-details#metadata-by-platform) for the full list of metadata items per platform. The `Download` button allows you to download the backup archive. The `Restore` button allows you to restore the repository to the selected destination based on the backup. #### Deduplication over period The deduplication over period section shows the deduplication statistics for the selected period. You can learn more about how the deduplication works and the deduplication statistics [here](/managing-backups/data-deduplication). ### Backups Tab Backups tab shows the table of backups for the repository. Each backup is a separate row displaying Status, Start time, Backup size, Deduplicated, and Storage. You can view the backup information by clicking the `Information` icon, download the backup archive by clicking the `Download` button, and restore the repository to the selected destination based on the backup by clicking the `Restore` button. You can learn more about the data restoration [here](/data-restoration/restoring-a-backup) and backup download [here](/data-restoration/download-backups). ![Repository backups](/files/tKllKUPOjOZLPZF1Jn0G) ### Restores Tab The restores tab shows the table of restores for the repository. Each restore is a separate row displaying Status, Start time, Restore to, and Restored from backup. You can view the restore information by clicking the `Information` icon. ![Repository restores](/files/yBv61iN8y0RhvDQP9vq6) ## Learn More * [Dashboard Overview](/dashboard/dashboard-overview) * [Backup Details](/dashboard/backup-details) * [Backup status badge](/dashboard/backup-status-badge) # Backup Details View backup details in Cloudback, including status, archive size, deduplication info, and platform-specific metadata statistics. You can view the details of a backup to see the data that was collected during the backup process. To view the details of a backup, open the **Repository Details** page, open the `Backups` tab and click on the `Information` icon next to the backup you want to view. The details include the repository name, the date and time of the backup, the size of the backup, and collected metadata statistics. The **Download** and **Restore** buttons are also available from this view when the backup succeeded. ![Backup details window](/files/3qnJWIzknv9wyFAAEsur) ## Metadata by Platform The metadata items shown in the backup details depend on the platform the backup was collected from: ### GitHub Projects, Pull requests, Releases, Issue types, Issues, Comments, Labels, Milestones. ### Azure DevOps Pull requests, Threads, Attachments, Labels. ### GitLab Merge requests, Releases, Issues, Issue Notes, MR Notes, Labels, Milestones. ### Linear Teams, Projects, Project Milestones, Project Updates, Cycles, Issues, Comments, Labels, Project Labels, Documents, Attachments, Views, Initiatives, Initiative Updates, Issue Templates, Project Templates, Users, Embedded Files, External Users. ## Learn More * [GitHub Backup Contents](/github/backup-contents) * [Azure DevOps Backup Contents](/azure-devops/backup-contents) * [GitLab Backup Contents](/gitlab/backup-contents) * [Linear Backup Contents](/linear/backup-contents) * [Dashboard Overview](/dashboard/dashboard-overview) * [Password-Protected Archives](/security-and-compliance/password-protected-archives) * [Repository Details](/dashboard/repository-details) # Backup Status Badge Display your repository backup status with Cloudback's embeddable status badge, providing visual confirmation of backup health on your repository page. Backup Status Badge is a feature that allows you to display the backup status of your repositories on your repository page. The badge will show the last backup status for the repository. This feature is useful for repository owners to keep track of the backup status of their repositories. ## About Backup Status Badge The badge represents the status of the latest backup created by Cloudback. The badge can be embedded into any web page. You can find a sample usage in the Cloudback's Terraform Provider repository home page: ## How to get the Backup Status Badge To get the Backup Status Badge for your repository, follow these steps: * Go to the Cloudback Dashboard * Open the repository details page for the repository you want to get the badge for * In the `Settings` section, click on the `Get badge URL` button: ![Get backup status badge](/files/sz0aT3N0ggjigw4VHbsT) After you clicked on the `Get badge URL` button, you will see a modal with the badge URL. You can copy the URL and use it to embed the badge into your web page. There are two options available, you can copy the image URL or the Markdown code: ![Backup status badge dialog](/files/PseLgqekthjvmmypnHmA) ## Badge URL Formats Cloudback supports two badge URL formats: * **Multi-platform (current)**: `/badge/{platform}/{accountIdentifier}/{subjectType}/{subjectName}` - works for all supported platforms. * **Legacy GitHub-only**: `/badge/{owner}/{repositoryName}` - supported for backwards compatibility. ## Badge Status Values The badge reflects the status of the latest backup. The following statuses are possible: | Status | Color | Description | | ----------- | ----- | ----------------------------------------------- | | succeeded | green | The last backup completed successfully | | failed | red | The last backup failed | | in progress | green | A backup is currently running | | scheduled | green | A backup is queued and waiting to run | | deleted | grey | The repository or backup definition was deleted | | unknown | grey | Status could not be determined | ## Learn More * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) # User Roles Manage user access to account settings and repositories in Cloudback. Only Global Admins can assign roles and control user permissions. The **User Roles** page allows you to manage user access to account settings and repositories across all your connected platform accounts. This page provides full control over who can access what resources and what level of permissions they have. Only users with the **Global Admin** role can access the User Roles page and assign roles to other users. ## Accessing User Roles To access the User Roles page, navigate to the left sidebar and click on `User Roles`. ![User Roles Page](/files/58sSdbHXgWujrHttQRUB) ## Page Overview The User Roles page displays all users and their assigned roles across your organization accounts. The interface provides filtering capabilities and shows detailed information about user permissions for each account. ### Filters The page includes filtering options to help you manage large numbers of users and accounts: * **Account**: Filter by account name to view users associated with specific platform accounts * **User**: Filter by username to find specific users quickly * **Role**: Filter by role type (All roles, Global Admin, Admin, No Access) ### User Roles Table The main table displays the following information: * **Account**: The platform account/organization name where the user has access, along with a platform badge * **User**: The username and avatar of the user * **Role**: The assigned role for that specific account The table shows user permissions on a per-account basis, meaning a single user can have different roles across different accounts. ## Available Roles ### Global Admin Users with the **Global Admin** role have full access to: * User role management capabilities * Full control over backup configurations, like enabling/disabling automated backups, changing backup schedules, storages and retention policies Global Admins are identified with a key icon (🔑) next to their role in the interface. > **Note:** You cannot change your own role. Your current user is shown as fixed "Global Admin" text rather than a dropdown. Other users - including other Global Admins - can have their roles changed via the dropdown. > **Note:** New users added to Cloudback receive the **Global Admin** role by default. Review and adjust roles promptly to ensure only intended users have administrative access. ### Admin Users with the **Admin** role have full control over backup configurations, like enabling/disabling automated backups, changing backup schedules, storages and retention policies. **Admin** users have the ability to manage backups but do not have access to user role management capabilities. ### No Access Users with **No Access** have no permissions to view or manage repositories and settings for that specific account. This role effectively removes access while keeping the user in the system. ## Managing User Roles ### Viewing Current Roles The interface displays current role assignments in a clear tabular format. You can see: * Which users have access to which accounts * What level of access each user has * Users who may have different roles across multiple accounts ### Modifying Roles To change a user's role: 1. Locate the user in the table 2. Click on the role dropdown for the specific account 3. Select the new role from the available options 4. Click "Save Changes" to apply the new role ## Learn More * [Account Settings](/managing-backups/account-settings) * [Dashboard Overview](/dashboard/dashboard-overview) # Storage Configuration Configure where your backups are stored with Cloudback, including managed cloud storage options and custom storage configurations. Cloudback offers flexible storage options for your backups, from fully managed cloud storage to bring-your-own storage solutions. ## Storage Options * [Cloudback Managed Storages](/storage-configuration/cloudback-managed-storages) - Use Cloudback's secure managed storage * [Customer Managed Storages](/storage-configuration/customer-managed-storages) - Configure your own storage providers * [Replicating Backups](/storage-configuration/replicating-backups) - Set up redundant backup storage across multiple locations # Cloudback Managed Storages Use Cloudback's pre-configured storage options located in multiple global regions (US, EU, UK, Australia, Singapore) for storing your backups. Cloudback provides a set of managed storages accessible to all clients. To adhere to data residency regulations, these storage facilities are located in various regions. Clients can freely select the storage option nearest to their location without incurring extra fees. By default, all backups are stored in the **Cloudback US** storage. ## The List of Cloudback-Managed Storages ![Cloudback managed storages](/files/KtT958K5CcSu3sfmNuvm) | Storage name | Region | | ------------------- | ----------------------- | | Cloudback US | USA East, N. Virginia | | Cloudback EU | EU Central, Amsterdam | | Cloudback UK | EU West, London | | Cloudback Sydney | Asia, Australia, Sydney | | Cloudback Singapore | Asia, Singapore | ## Cloudback Managed Storage Properties All Cloudback-managed storages share the following characteristics: * **Password protection**: Always enabled. Every backup archive stored in a Cloudback-managed storage is encrypted with a unique, system-generated AES-256 password. This cannot be disabled for managed storages. * **Deduplication**: Always enabled. Cloudback deduplicates backup data across all managed storages to minimize redundant storage usage. * **Underlying provider**: Cloudback-managed storages are hosted on [Wasabi](https://wasabi.com/) S3-compatible object storage. Wasabi is not an AWS S3 service - it is a separate, S3-compatible provider. ## How to Change the Storage The storage for a particular repository can be changed in the [Repository Details](/dashboard/repository-details) page. To change storage for multiple repositories at once, use [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [GitHub Backup Contents](/github/backup-contents) * [Data Deduplication](/managing-backups/data-deduplication) # Customer Managed Storages Configure your own storage solutions for your backups with Cloudback, supporting Azure, AWS, Google Cloud, OneDrive, and other providers. Cloudback allows you to store backup archives in your own storage, ensuring no copies are retained by Cloudback. Essentially, Cloudback creates a backup of your repository, transfers the archive to your designated storage, and then permanently deletes the archive from Cloudback's servers. This process guarantees that there are no copies of data on Cloudback servers. Also, Cloudback offers its managed storages named according to the storage geographic region: `Cloudback US`, `Cloudback EU`, `Cloudback UK`, `Cloudback Sydney`, and `Cloudback Singapore`. ## Storages list You can find the list of all storages in the `Storages` page. The list contains all storages that you have created in Cloudback. You can see the storage name and the storage provider for each storage. You can use the `Edit` button to change the storage settings or the `Delete` button to remove the storage from Cloudback. Please note that you can't delete the storage if it is used by any repository. ![Storages list](/files/kmIGJhB6FbT1QZGI7Sru) ## Add a new storage The `Storages` page displays all registered storage options, including both built-in and customer-managed storages. To add your own storage, click on the `Add a new storage` button. It initiates a storage setup wizard to assist you through the registration process. ![New Storage page](/files/qDuAjj4jJzzyZesc4qRg) ## Storage configuration You can create multiple custom storages in Cloudback and use them for storing backups of different repositories from different connected accounts. You can also use the same storage for storing backups of multiple repositories. Each storage has a set of settings that you can configure: * **Storage name** - a name of the storage that will be displayed in the Cloudback dashboard. Try using a descriptive name that will help you to identify the storage later. * **Storage provider** - a storage provider that you want to use for storing backups. Currently, Cloudback supports a variety of storage providers, you can check the full list [below](#supported-storages). * **Deduplication type** - a deduplication type that you want to use for storing backups. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation. * **Archive type** - an archive type that you want to use for storing backups, allowing you to enable or disable the password protection for your backups. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation. * **Archive name pattern** - a pattern that will be used to name the archives stored in the storage. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation. ![Storage settings](/files/a8ozSivwcvFv4aNDfrnV) ## Storage access You can configure the accounts who can access each storage. To edit storage access settings, go to the `Storages` page, find the storage you want to modify, and click on the `Edit Access` button. In the Edit Storage Access page, you can manage access permissions for individual accounts. ![Storage access settings](/files/DtQM5qQ0a3CTMgW2kwfd) ## How to change the storage You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Supported storages Cloudback supports a variety of storage providers. Please follow the link below to find additional details about a particular storage: * [Cloudback Managed Storage](/storage-configuration/cloudback-managed-storages) * [Microsoft Azure Blob Storage](/supported-storages/microsoft-azure-blob-container) * [Microsoft OneDrive Personal](/supported-storages/microsoft-onedrive-personal) * [Microsoft OneDrive For Business](/supported-storages/microsoft-onedrive-business) * [Amazon S3 Bucket via Access Point](/supported-storages/amazon-s3-bucket-via-access-point) * [Amazon S3 Bucket via Access Key](/supported-storages/amazon-s3-bucket-via-access-key) * [Amazon S3 Bucket via AssumeRole](/supported-storages/amazon-s3-bucket-via-assume-role) * [Amazon S3 Glacier](/supported-storages/amazon-s3-glacier) * [Google Cloud Storage Bucket](/supported-storages/google-cloud-storage-bucket) * [Alibaba Cloud Object Storage Service](/supported-storages/alibaba-cloud-object-storage-service) * [OpenStack Swift Container via S3 API](/supported-storages/openstack-swift-storage) * [Wasabi Bucket (S3 API)](/supported-storages/wasabi-customer-managed-storage) ## Looking for additional storage options? Responding to user requests, Cloudback has integrated support for [OpenStack Swift](https://github.com/cloudback/issue-tracker/issues/6) and [Microsoft OneDrive](https://github.com/cloudback/issue-tracker/issues/7). If you need support for another storage solution, please [contact us](/troubleshooting-and-support/contact-us) or [submit a feature request](https://github.com/cloudback/issue-tracker/issues/new?template=feature_request.md). Cloudback is open to considering the implementation of new storage options based on user needs. ## What Does Cloudback Upload to Storage? Cloudback uploads ZIP archives (password-protected by default, configurable per storage). When password protection is enabled, the encryption password is securely stored on Cloudback's servers, safeguarded by multiple layers of security. In the unlikely event of unauthorized access to the storage, the intruder would only find encrypted archives, rendering them unable to access the contents of the archive. You can configure the archive type for each storage in the [storage settings](#storage-configuration). ## Learn More * [Cloudback Managed Storages](/storage-configuration/cloudback-managed-storages) * [GitHub Backup Contents](/github/backup-contents) * [Data Deduplication](/managing-backups/data-deduplication) # Replicating Backups Enhance data redundancy by replicating your GitHub repository backups across multiple storage locations with Cloudback's composite storage feature. Cloudback allows you to use composite storage to replicate your backups across multiple destinations, enhancing your data redundancy and disaster recovery capabilities. This article guides you through the process of setting up and managing replicated backups with Cloudback. ## What is a Composite Storage? Composite storage combines two storages: primary and secondary. Think of primary storage as the main location for your data, while secondary storage acts as a backup copy. In simpler terms, Cloudback duplicates your backup archive and stores it in both locations. This strategy distributes your data across different sites, effectively increasing data redundancy and helping you meet compliance regulations. ## Benefits of Replicating Backups Replicating backups offers several advantages: * **Eliminate single points of failure**: Storing backups across diverse locations ensures data remains accessible even if a single storage provider encounters issues. * **Rapid disaster recovery:** Replicated backups allow for swift restoration from an unaffected location, minimizing downtime and ensuring business continuity. * **Compliance Adherence**: It supports compliance with laws requiring multiple backup copies, ensuring legal and regulatory standards are met. ## Setting Up Replicated Backups There are only three steps: 1. Create a [customer managed storage](/storage-configuration/customer-managed-storages) for each of the primary and secondary destinations. 2. Create a **composite storage** and set primary and secondary targets. 3. Configure repositories to use a newly created composite storage via the [Bulk Operations](/managing-backups/bulk-operations) menu. ### Constraints When configuring composite storage, the following rules apply: * **Secondary cannot be a Cloudback managed storage**: The secondary storage must be a customer-managed storage. Cloudback-managed storages (US, EU, UK, Sydney, Singapore) cannot be used as the secondary destination. * **Primary and secondary must differ**: You cannot set the same storage as both primary and secondary. * **Circular reference protection**: If you nest composite storages within each other, Cloudback will detect and reject circular references (e.g., Storage A → Storage B → Storage A). ![Composite storage](/files/dCHdXPdRdjP1dU5sN7gJ) ## How it works * **Automatic Replication**: During a backup process, Cloudback automatically copies an archive to both a primary and secondary destination. * **All or None**: If any of the underlying storages fails during a backup process - the entire backup is marked as failed and appropriate notification is sent. * **Restore takes first available:** During a restore process, Cloudback probes storages from primary to secondary and picks the first available. * **Composite storage settings win**: The "Deduplication type" and "Archive type" settings configured for the individual underlying storage will be disregarded when using a composite storage. Instead, the deduplication and archive behavior will be determined by the settings applied to the composite storage itself. * **Nesting capability**: It is possible to embed one composite storage within another, enabling you to create a desired number of copies of a backup. ## Conclusion Replicating backups with composite storage is a flexible way to ensure data redundancy. Its straightforward setup process provides an accessible option for IT professionals at any skill level, making it a cost-effective choice. The system's adaptability allows for configuring an unlimited number of backup storages, either per repository or for the entire account, ensuring strong data protection. ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Cloudback Managed Storages](/storage-configuration/cloudback-managed-storages) # Supported Storages Explore the various cloud storage providers supported by Cloudback for backups, including AWS, Azure, Google Cloud, and more. Cloudback supports many cloud storage providers for customer-managed backup storage. Choose the provider that best fits your infrastructure and compliance requirements. ## Cloud Storage Providers * [Alibaba Cloud Object Storage Service](/supported-storages/alibaba-cloud-object-storage-service) * [Amazon S3 Bucket via Access Key](/supported-storages/amazon-s3-bucket-via-access-key) * [Amazon S3 Bucket via Access Point](/supported-storages/amazon-s3-bucket-via-access-point) * [Amazon S3 Bucket via AssumeRole](/supported-storages/amazon-s3-bucket-via-assume-role) * [Amazon S3 Glacier](/supported-storages/amazon-s3-glacier) * [Amazon S3 Object Tagging](/supported-storages/amazon-s3-object-tagging) * [Google Cloud Storage Bucket](/supported-storages/google-cloud-storage-bucket) * [Microsoft Azure Blob Container](/supported-storages/microsoft-azure-blob-container) * [Microsoft OneDrive Business](/supported-storages/microsoft-onedrive-business) * [Microsoft OneDrive Personal](/supported-storages/microsoft-onedrive-personal) * [OpenStack Swift](/supported-storages/openstack-swift-storage) * [Wasabi Customer Managed Storage](/supported-storages/wasabi-customer-managed-storage) # Alibaba Cloud Object Storage Service Configure Alibaba Cloud Object Storage Service (OSS) as a secure, cost-effective storage solution for your repository backups in Cloudback. This guide provides information on how to set up Alibaba Cloud Object Storage Service (OSS) as a storage for your backups in Cloudback. ## About Alibaba Cloud Object Storage Service Alibaba Cloud Object Storage Service (OSS) is an encrypted, secure, cost-effective, and easy-to-use object storage service that enables you to store, back up, and archive large amounts of data in the cloud, with a guaranteed durability of 99.9999999999% (12 9’s). RESTful APIs allow storage and access to OSS anywhere on the Internet. You can elastically scale the capacity and processing capability and choose from a variety of storage types to optimize the storage cost. ## Set up Alibaba Cloud OSS Storage in Cloudback To set up Alibaba Cloud Object Storage Service (OSS) as a storage for your backups, follow the steps below. ### Create a new Alibaba storage * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future * Select `Alibaba` from a Storage Provider dropdown: ![Alibaba Cloud Storage settings](/files/EgOKkfRvnjkhyk3bAypV) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Create Alibaba Cloud OSS Bucket Follow the `Step 1` on the `New Storage` page to create a new Alibaba Cloud OSS Bucket. To integrate Alibaba Cloud OSS with Cloudback, you need to create a new bucket in the Alibaba Cloud OSS console. If you already have a bucket, you can skip this step. For more details about creating a bucket, please refer to the [Alibaba Cloud documentation](https://www.alibabacloud.com/help/en/oss/user-guide/create-a-bucket-4). Alternatively, you can follow the link on the `Step 1` field on the `New Storage` page. ### Grant Cloudback access to the bucket On the `Step 2`, you need to grant Cloudback access to the bucket. Cloudback needs access to the bucket to store backups of your repositories. To grant Cloudback access to the bucket, you need to create a new RAM user and assign the necessary permissions to the user. Follow the steps below to create a new RAM user and grant the necessary permissions: * Copy Cloudback RAM account ID from `Step 2` * Grant Cloudback access to the bucket: * On the Buckets page, click the name of your bucket to configure bucket policies * In the left-side navigation pane, click `Files`, then click `Authorize` * On the GUI tab, click `Authorize` * In the Authorize panel, add the RAM user ID to the `Other accounts` field, set `Any Operation` in the `Authorized Operation` field, and click `OK` You can learn more about granting access to the bucket in the [Alibaba Cloud documentation](https://www.alibabacloud.com/help/en/oss/user-guide/use-bucket-policy-to-grant-permission-to-access-oss/). ![Authorize Cloudback account](/files/lu7r90hLni9i5bkXhFUv) ### Save Bucket Domain Name in storage settings The `Step 3` requires you to save the bucket domain name in the storage settings. To have access to the bucket, Cloudback needs to know the bucket domain name. Type your [Bucket Domain Name](https://www.alibabacloud.com/help/en/oss/user-guide/oss-domain-names) to the `Step 3` field on the `New Storage` dialog * Sample input: `your-bucket-name.oss-me-east-1.aliyuncs.com` ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # Amazon S3 Bucket via Access Key Set up Amazon S3 Bucket with Access Key authentication as a storage solution for your backups in Cloudback, with detailed permission requirements. ## About Amazon S3 Bucket Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance. This means customers of all sizes and industries can use it to store and protect any amount of data for a range of use cases, such as data lakes, websites, mobile applications, backup and restore, archive, enterprise applications, IoT devices, and big data analytics. ## Required permissions * **s3:PutObject** - required, for backup archive upload to Amazon S3 bucket * **s3:GetObject** - optional, for backup restore and instant download from Amazon S3 bucket * **s3:DeleteObject** - optional, for retention policy, automatic removal of outdated backups from Amazon S3 bucket * **s3:GetBucketLocation** - optional, required to automatically determine the `Service Endpoint URL` * **s3:PutObjectRetention** - optional, required for the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) header `x-amz-object-lock-mode` * **s3:PutObjectLegalHold** - optional, required for the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) header `x-amz-object-lock-legal-hold` * **s3:PutObjectTagging** - optional, required for the [S3 Object Tagging](/supported-storages/amazon-s3-object-tagging) header `x-amz-tagging` ## Set up Amazon S3 Bucket Access Key as a customer managed storage To set up Amazon S3 Bucket Access Key as a storage for your backups, follow the steps below. ### Create a new Amazon S3 Access Key storage * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future. * Select `Amazon S3 AccessKey` from a Storage Provider dropdown: ![Amazon S3 AccessKey storage settings](/files/nwa6bPdp0omAZ0bmr168) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Create Amazon S3 Bucket To upload backups to Amazon S3 Bucket, you need to create a bucket. You can skip this step if you already have a bucket. You can find more information on how to create a bucket in the [Amazon S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket). Cloudback needs the ARN of the bucket to access it. To find the ARN, click on the name of your bucket in the S3 console and open the `Properties` tab. Copy the ARN and paste it in the `Step 1` field on the Cloudback site. ### Create AWS Access Key Cloudback accesses your Amazon S3 bucket using an AWS Access Key. You need to create a new Access Key in the AWS Management Console. You can find more information on how to create an Access Key in the [Amazon S3 documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). Type its id and secret to `Step 2` fields on the New Storage page. ### Provide the Service Endpoint URL (Optional) The service endpoint URL can be used to access the Amazon S3 bucket. If you don't provide the service endpoint URL, Cloudback will try to determine it automatically using the `s3:GetBucketLocation` permission. In general, the service endpoint URL can be used for every S3-compatible storage. Insert the service endpoint URL in the `Step 3` field on the New Storage page. You can learn more about the service endpoint URL in the [Amazon S3 documentation](https://docs.aws.amazon.com/general/latest/gr/rande.html). ### Provide additional HTTP headers (Optional) In the `Step 4` field you can provide additional HTTP headers to be used when uploading backups to the Amazon S3 bucket. The headers can be used to set the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) or [S3 Object Tagging](/supported-storages/amazon-s3-object-tagging) headers. ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # Amazon S3 Bucket via Access Point Configure Amazon S3 Bucket with Access Point for your backups in Cloudback, providing enhanced security through policy-based access control. ## About Amazon S3 Bucket Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance. This means customers of all sizes and industries can use it to store and protect any amount of data for a range of use cases, such as data lakes, websites, mobile applications, backup and restore, archive, enterprise applications, IoT devices, and big data analytics. ## Required permissions * **s3:PutObject** - required, for backup archive upload to Amazon S3 bucket * **s3:GetObject** - optional, for backup restore and instant download from Amazon S3 bucket * **s3:DeleteObject** - optional, for retention policy, automatic removal of outdated backups from Amazon S3 bucket * **s3:PutObjectRetention** - optional, required for the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) header `x-amz-object-lock-mode` * **s3:PutObjectLegalHold** - optional, required for the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) header `x-amz-object-lock-legal-hold` * **s3:PutObjectTagging** - optional, required for the [S3 Object Tagging](/supported-storages/amazon-s3-object-tagging) header `x-amz-tagging` ## Set up Amazon S3 Bucket as a customer managed storage To set up Amazon S3 Bucket Access Point as a storage for your backups, follow the steps below. ### Create a new Amazon S3 Access Point storage * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future. * Select `Amazon S3 AccessPoint` from a Storage Provider dropdown: ![Amazon S3 AccessPoint storage settings](/files/cTKPywT75w88wTDT3GQN) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Create Amazon S3 Bucket To upload backups to Amazon S3 Bucket, you need to create a bucket. You can skip this step if you already have a bucket. You can find more information on how to create a bucket in the [Amazon S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html). Cloudback needs the ARN of the bucket to access it. To find the ARN, click on the name of your bucket in the S3 console and open the `Properties` tab. Copy the ARN and paste it in the `Step 1` field on the Cloudback site. ### Apply bucket policy After you type a bucket ARN in the `Step 1` field, Cloudback will generate a bucket policy for you. The generated policy document is available in the `Step 2` field. You need to apply this policy to the bucket to allow Cloudback to access it. For more information on how to apply the bucket policy, please refer to the corresponding [Amazon S3 documentation page](https://docs.aws.amazon.com/AmazonS3/latest/userguide/add-bucket-policy.html). ### Create Amazon S3 Access Point Cloudback accesses your Amazon S3 bucket using an Amazon S3 Access Point. You need to create a new Access Point in the AWS Management Console, and then paste the Access Point ARN in the `Step 3` field. You can find more information on how to create an Access Point in the [Amazon S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-access-points.html). ### Apply access point policy After you type an Access Point ARN in the `Step 3` field, Cloudback will generate an access point policy for you. The generated policy document is available in the `Step 4` field. You need to apply this policy to the access point to allow Cloudback to access it. For more information on how to apply the access point policy, please refer to the corresponding [Amazon S3 documentation page](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points-manage.html#edit-access-point-policy). ![Setting up Amazon S3 AccessPoint storage](/files/cTKPywT75w88wTDT3GQN) ### Provide additional HTTP headers (Optional) In the `Step 5` field, you can provide additional HTTP headers to be used when uploading backups to the Amazon S3 bucket. The headers can be used to set the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) or [S3 Object Tagging](/supported-storages/amazon-s3-object-tagging) headers. ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # Amazon S3 Bucket via AssumeRole Configure an Amazon S3 Bucket via IAM AssumeRole for your backups in Cloudback, granting access through temporary credentials instead of long-lived access keys. ## About Amazon S3 Bucket Amazon Simple Storage Service (Amazon S3) is an object storage service that offers industry-leading scalability, data availability, security, and performance. This means customers of all sizes and industries can use it to store and protect any amount of data for a range of use cases, such as data lakes, websites, mobile applications, backup and restore, archive, enterprise applications, IoT devices, and big data analytics. With the AssumeRole option, Cloudback accesses the bucket through an IAM Role in your own AWS account instead of a long-lived access key. Before each storage operation Cloudback assumes that role and receives temporary credentials, protected by an External ID that guards against the [confused deputy problem](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html). ## Required permissions * **s3:PutObject** - required, for backup archive upload to Amazon S3 bucket * **s3:ListBucket** - required, so that a missing backup archive is reported as not found rather than access denied * **s3:GetObject** - optional, for backup restore and instant download from Amazon S3 bucket * **s3:DeleteObject** - optional, for retention policy, automatic removal of outdated backups from Amazon S3 bucket * **s3:GetBucketLocation** - optional, required to automatically determine the region of the bucket * **s3:PutObjectRetention** - optional, required for the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) header `x-amz-object-lock-mode` * **s3:PutObjectLegalHold** - optional, required for the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) header `x-amz-object-lock-legal-hold` * **s3:PutObjectTagging** - optional, required for the [S3 Object Tagging](/supported-storages/amazon-s3-object-tagging) header `x-amz-tagging` ## Set up Amazon S3 Bucket AssumeRole as a customer managed storage To set up Amazon S3 Bucket AssumeRole as a storage for your backups, follow the steps below. ### Create a new Amazon S3 AssumeRole storage * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future. * Select `Amazon S3 AssumeRole` from a Storage Provider dropdown: ![Amazon S3 AssumeRole storage settings](/files/6qFP5ADmtTX3davH7LRz) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Create an IAM Role Cloudback accesses your Amazon S3 bucket by assuming an IAM Role in your AWS account. Create a role with the `Custom trust policy` role type and paste its ARN in the `Step 1` field on the Cloudback site. You can find more information on how to create a role in the [AWS IAM documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html). ### Choose an External ID Type a unique External ID in the `Step 2` field. Cloudback places this value in the trust policy generated in the `Step 5` field and sends it with every request to assume the role. ### Create Amazon S3 Bucket To upload backups to Amazon S3 Bucket, you need to create a bucket. You can skip this step if you already have a bucket. You can find more information on how to create a bucket in the [Amazon S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html#creating-bucket). Cloudback needs the ARN of the bucket to access it. To find the ARN, click on the name of your bucket in the S3 console and open the `Properties` tab. Copy the ARN and paste it in the `Step 3` field on the Cloudback site. ### Apply the permissions policy After you type a bucket ARN in the `Step 3` field, Cloudback will generate a permissions policy for you. The generated policy document is available in the `Step 4` field. You need to [create an IAM policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) from it and [attach it](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) to your role to allow Cloudback to access the bucket. ### Apply the trust policy After you type an External ID in the `Step 2` field, Cloudback will generate a trust policy for you. The generated policy document is available in the `Step 5` field. You need to [apply this policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-trust-policy.html) to the trust relationship of your role to allow Cloudback to assume it. ### Provide the AWS Region (Optional) In the `Step 6` field, you can provide the AWS Region of the bucket. If you don't provide the region, Cloudback will try to determine it automatically using the `s3:GetBucketLocation` permission. ### Provide additional HTTP headers (Optional) In the `Step 7` field you can provide additional HTTP headers to be used when uploading backups to the Amazon S3 bucket. The headers can be used to set the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) or [S3 Object Tagging](/supported-storages/amazon-s3-object-tagging) headers. ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # Amazon S3 Glacier Use Amazon S3 Glacier as a low-cost, long-term storage solution for your backups in Cloudback, with comprehensive security and compliance capabilities. ## About Amazon S3 Glacier Amazon S3 Glacier and S3 Glacier Deep Archive are secure, durable, and extremely low-cost Amazon S3 cloud storage classes for data archiving and long-term backup. They are designed to deliver 99.999999999% durability, and provide comprehensive security and compliance capabilities that can help meet even the most stringent regulatory requirements. ## Required permissions The following permissions are required to use Amazon S3 Glacier as a storage for your backups: * glacier:UploadArchive * glacier:DeleteArchive * glacier:InitiateJob * glacier:GetJobOutput * glacier:InitiateMultipartUpload * glacier:CompleteMultipartUpload * glacier:AbortMultipartUpload * glacier:UploadMultipartPart * glacier:DescribeJob ## Set up Amazon S3 Glacier as a customer managed storage To set up Amazon S3 Glacier as a storage for your backups, follow the steps below. ### Create a new Amazon S3 Glacier storage * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future. * Select `Amazon S3 Glacier` from a Storage Provider dropdown: ![Amazon S3 Glacier storage settings](/files/JEaEFaHDB7eJSvMsq8X6) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Create a new Amazon S3 Glacier Vault To upload backups to Amazon S3 Glacier, you need to have a vault. You can find more information on how to create a vault in the [Amazon S3 Glacier documentation](https://docs.aws.amazon.com/amazonglacier/latest/dev/getting-started-create-vault.html). After creating a vault, you need to provide the Vault ARN in the `Step 1` field. If you already have a vault, you can just provide the ARN of the existing vault. ### Apply vault access policy After you type a vault ARN in the `Step 1` field, Cloudback will generate a vault access policy for you. The generated policy document is available in the `Step 2` field. You need to apply this policy to the vault to allow Cloudback to access it. For more information on how to apply the vault access policy, please refer to the corresponding [Amazon S3 Glacier documentation page](https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-access-policy.html). ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # Amazon S3 Object Tagging Categorize and organize your repository backups in Amazon S3 using object tagging with Cloudback, supporting custom tags and repository-specific variables. [Amazon S3 Object Tagging](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-tagging.html) is a feature provided by Amazon Web Services in their Simple Storage Service. It's designed to help you categorize your storage. Cloudback supports S3 Object Tagging feature using custom HTTP headers for the [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) API call. ## Getting Started ### HTTP headers for S3 Object Tagging **x-amz-tagging**: The tag-set for the object. * The tag-set must be encoded as URL Query parameters. (For example, "Key1=Value1"). > **Important:** `s3:PutObjectTagging` permission is required. You should grant the permission at a bucket level and at an access point level if applicable. Example: ``` x-amz-tagging: Key1=Value1&Key2=Value2 ``` ### Built-in variables You can use the following variables in the `x-amz-tagging` header: * `{{ context.RepositoryName }}`: The name of the repository that is being backed up. * `{{ context.AccountName }}`: The name of the owner account of the repository that is being backed up. Example: ``` x-amz-tagging: RepositoryName={{ context.RepositoryName }}&AccountName={{ context.AccountName }} ``` ### Configure your storage in the Storage page You can add a header using the [Storages Page](/storage-configuration/customer-managed-storages). Click on the `Add a new storage` or `Edit Storage` button. Fill in the required details for the storage and you will see the `Additional HTTP headers` section. Add the `x-amz-tagging` header with the value you need. ![Custom HTTP headers](/files/nwa6bPdp0omAZ0bmr168) Additional HTTP headers are supported for all S3 compatible storages: * Amazon S3 Bucket: Access Point * Amazon S3 Bucket: Access Key * OpenStack Swift Container: S3 API * Wasabi S3 Bucket: Access Key ## Learn More * External Article: [Categorizing your storage using tags](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-tagging.html) * External Article: [PutObject Request Syntax](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html#API_PutObject_RequestSyntax) * [Amazon S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) # Google Cloud Storage Bucket Set up Google Cloud Storage Bucket as a reliable, scalable storage solution for your repository backups in Cloudback with simple role-based access control. ## About Google Cloud Storage Bucket Cloud Storage allows world-wide storage and retrieval of any amount of data at any time. You can use Cloud Storage for a range of scenarios including serving website content, storing data for archival and disaster recovery, or distributing large data objects to users via direct download. ## Set up Google Cloud Storage Bucket To set up Google Cloud Storage as a storage for your backups, follow the steps below. ### Create a new Google Cloud storage * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future. * Select `Google Cloud` from a Storage Provider dropdown: ![Google Cloud storage settings](/files/UlmTwfBnjgWH6qFQViLI) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Create a new Google Cloud Storage Bucket To upload backups to Google Cloud Storage, you need to have a bucket. You can find more information on how to create a bucket in the [Google Cloud Storage documentation](https://cloud.google.com/storage/docs/creating-buckets). If you already have a bucket, you can skip this step. ### Grant Storage Object Admin role To upload backups to Google Cloud Storage, you need to grant the `Storage Object Admin` role to the service account that Cloudback uses to access the bucket. Copy the service account from the `Step 2` field and grant the `Storage Object Admin` role to this service account. ### Provide the bucket name After granting the `Storage Object Admin` role, you need to provide the bucket name in the `Step 3` field. Bucket name is required so Cloudback can upload backups to the correct bucket. ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # Microsoft Azure Blob Container Configure Microsoft Azure Blob Container as a secure, scalable storage solution for your repository backups in Cloudback using Shared Access Signatures. One of the ways to back up a [GitHub repository](/managing-backups/automated-daily-backups) using customer managed storage is to use your own Azure Container. Azure Blob Storage is Microsoft's object storage solution for the cloud. Blob storage is optimized for storing massive amounts of unstructured data, therefore it can be used as a storage for GitHub repository backups created by Cloudback. This page describes how to set up your own Azure Blob Container as a customer managed storage for Cloudback backups of your GitHub repositories. To be able to use your Azure Blob Container as customer managed storage, you need to have an existing Azure storage or create a new one. Also, you should create a new shared access signature for that storage. ## About Microsoft Azure Blob Containers Azure Blob storage is Microsoft's object storage solution for the cloud that is optimized for storing massive amounts of unstructured data. Unstructured data is data that doesn't adhere to a particular data model or definition, such as text or binary data. Azure Storage is a Microsoft-managed service that provides highly available, secure, durable, and scalable cloud storage. ## Set up Microsoft Azure Blob Container as a customer managed storage To set up Microsoft Azure Blob Container as a storage for your backups, follow the steps below. ### Create a new Microsoft Azure Blob Container * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future. * Select `Microsoft Azure Blob Containers` from a Storage Provider dropdown: ![Microsoft Azure Blob Containers storage settings](/files/yuXzmygr4nRaugWwJHML) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Create new Azure Storage Container To upload backups to Azure Blob Storage, you need to have a container. You can find more information on how to create a container in the [Azure Blob Storage documentation](https://learn.microsoft.com/en-us/azure/storage/blobs/blob-containers-portal). If you already have a container, you can skip this step. ### Create new Shared Access Signature The Shared Access Signature (SAS) is a URI that grants restricted access rights to Azure Storage resources. You can create a new SAS in the Azure Portal using the instructions provided in the [Azure documentation](https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview). When creating a new SAS, make sure to grant the following permissions: * **Create** and **Read** * **Write** - this permission is required by Azure for multipart uploads of large archives * **Delete** - this permission is required by Cloudback to delete old backups by retention policy. Grant this permission for the retention policy to work correctly. ![Microsoft Azure Blob Container SAS](/files/2QXfKI2ucrc243XzKjPM) ### Provide Blob SAS URL In the `Step 3` field, provide the Blob SAS URL of the SAS created in the previous step. Use a **Container SAS** (generated from your storage account's container settings), which grants scoped access to the specific container where backups will be stored. The SAS URL is required so Cloudback can upload backups to the correct container. ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # Microsoft OneDrive Business Store your repository backups in Microsoft OneDrive for Business with Cloudback, providing smooth integration with your existing Microsoft 365 environment. ## About Microsoft OneDrive OneDrive is the cloud storage service that Microsoft offers to store all your files securely in one place, which you can then access from virtually anywhere. ## Set up Microsoft OneDrive Business To set up Microsoft OneDrive Business as a storage for your backups, follow the steps below. ### Create a new OneDrive Business storage * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future. * Select `OneDrive Business` from a Storage Provider dropdown: ![OneDrive Business storage settings](/files/jPrKfzPORbWe0Hx00cEM) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Check your OneDrive Business account Ensure you have access to the OneDrive Business account you want to use for storing backups. If you don't have an account, you can create one on the [Microsoft OneDrive website](https://www.microsoft.com/en-us/microsoft-365/onedrive/onedrive-for-business). ### Grant permissions to Cloudback application On the `Step 2`, click on the `Grant permissions` button to grant the necessary permissions to the Cloudback application. This will allow Cloudback to access your OneDrive Business account and upload backups to it. ### Provide the OneDrive Business folder name After granting the necessary permissions, you need to provide the folder name in the `Step 3` by clicking on the `Open file picker` button. Folder name is required so Cloudback can upload backups to the correct folder in your OneDrive Business account. ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # Microsoft OneDrive Personal Use your personal Microsoft OneDrive account to store repository backups with Cloudback, utilizing the secure OneDrive App Folder for private storage. ## About Microsoft OneDrive OneDrive is the cloud storage service that Microsoft offers to store all your files securely in one place, which you can then access from virtually anywhere. ## Set up Microsoft OneDrive Personal To set up Microsoft OneDrive Personal as a storage for your backups, follow the steps below. ### Create a new OneDrive Personal storage * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future. * Select `OneDrive Personal` from a Storage Provider dropdown: ![OneDrive Personal storage settings](/files/HsycwgbD4zRyyUGz04Zf) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Check your OneDrive Personal account Ensure you have access to the OneDrive Personal account you want to use for storing backups. If you don't have an account, you can create one on the [Microsoft OneDrive website](https://www.microsoft.com/en-us/microsoft-365/onedrive/online-cloud-storage). You can find instructions on how to create a new account in the [Microsoft OneDrive documentation](https://support.microsoft.com/en-us/office/video-sign-in-or-create-an-account-for-onedrive-personal-6c63b4e3-c92f-4f52-80e2-237c798cec1e). ### Allow access to OneDrive App Folder To upload backups to OneDrive Personal, you need to allow access to the OneDrive App Folder. The App Folder is a dedicated, special folder for your app. It's a private folder that only your app can access. You can find more information on how to allow access to the OneDrive App Folder in the [Microsoft OneDrive documentation](https://learn.microsoft.com/en-us/onedrive/developer/rest-api/concepts/special-folders-appfolder?view=odsp-graph-online). Click on the `Grant permission` button to grant Cloudback access to the OneDrive App Folder. ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # OpenStack Swift Configure OpenStack Swift as a storage solution for your repository backups in Cloudback using the S3-compatible API for smooth integration. ## About OpenStack Swift The [OpenStack Object Store project](https://wiki.openstack.org/wiki/Swift), known as Swift, offers cloud storage software so that you can store and retrieve lots of data with a simple API. It's built for scale and optimized for durability, availability, and concurrency across the entire data set. Swift is ideal for storing unstructured data that can grow without bound. Cloudback supports OpenStack Swift via S3 API. You can check out the General compatibility statement in the [OpenStack Swift documentation](https://docs.openstack.org/swift/latest/s3_compat.html). ## Set up OpenStack Swift Container as a customer managed storage To set up OpenStack Swift as a storage for your backups, follow the steps below. ### Create a new OpenStack Swift storage * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future. * Select `Swift S3` from a Storage Provider dropdown: ![OpenStack Swift storage settings](/files/QRbnFbduLxhcW5B2Kj5X) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Provide OpenStack Swift Server URL In the `Step 1`, provide the OpenStack Swift Server URL. The URL is used to connect to the OpenStack Swift storage. ### Enter container name In the `Step 2`, provide the container name. The container is used to store backups in the OpenStack Swift storage. You can find more information on how to create a container in the [OpenStack Swift documentation](https://docs.openstack.org/newton/user-guide/cli-swift-create-containers.html). ### Provide OpenStack Access Key ID and Access Key Secret In the `Step 3`, provide the Access Key ID and Access Key Secret of [EC2 credentials](https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/ec2-credentials-v3.html). These credentials are used to authenticate Cloudback with OpenStack Swift. You can learn more about how to configure the storage in the [OpenStack Swift documentation](https://docs.openstack.org/mitaka/config-reference/object-storage/configure-s3.html). ### Provide additional HTTP headers (Optional) In the `Step 4` field you can provide additional HTTP headers to be used when uploading backups to the container. The headers can be used to set the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) or [S3 Object Tagging](/supported-storages/amazon-s3-object-tagging) headers. > **Note:** S3 Object Lock support depends on the OpenStack Swift implementation and may not be available in all deployments. Please verify that your OpenStack Swift provider supports S3 Object Lock before enabling this feature. ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # Wasabi Customer Managed Storage Configure Wasabi as a cost-effective, high-performance storage solution for your repository backups in Cloudback, with S3-compatible API and no egress fees. ## About Wasabi [Wasabi](https://wasabi.com/) is a public cloud object storage service that is 1/5th the price of Amazon S3 and faster than the competition with no fees for egress or API requests. Wasabi provides 11 x 9s of data durability, high system availability, and support for immutable storage buckets. Wasabi is fully compatible with the Amazon S3 API with support for hundreds of S3-compatible storage applications and has been certified for compliance with enterprise security and privacy standards. ## Set up Wasabi Bucket as a customer managed storage To set up Wasabi Bucket as a storage for your backups, follow the steps below. ### Create a new Wasabi storage * Open the [Cloudback Dashboard](https://app.cloudback.it/) * Navigate to the `Storages` page by clicking on the `Storages` link in the left-side navigation pane * Click on the `Add a new storage` button: ![Add new storage](/files/kmIGJhB6FbT1QZGI7Sru) * Type a storage name in the `Storage name` field. Use a name that will help you identify this storage in the future. * Select `Wasabi S3` from a Storage Provider dropdown: ![Wasabi S3 storage settings](/files/SuNx7VlUJyf7qH3k3FNa) ### Set up storage settings Choose the settings for the storage: * **Deduplication type** - enable or disable data deduplication. For more details, please refer to the [Deduplication](/managing-backups/data-deduplication) documentation * **Archive type** - enable or disable archive password protection. For more details, please refer to the [Password-Protected Archives](/security-and-compliance/password-protected-archives) documentation * **Archive name pattern** - configure the archive name pattern, which is used to generate the name of the backup archive. For more details, please refer to the [Archive Name Pattern](/managing-backups/archive-name-pattern) documentation ### Provide Wasabi Bucket ARN To upload backups to Wasabi, you need to have a bucket. You can find more information on how to create a bucket in the [Wasabi documentation](https://docs.wasabi.com/docs/creating-a-bucket). You can use existing bucket if you already have one. In the `Step 1`, provide the Bucket Region and Bucket ARN. Buckets from different regions have different [service URLs](https://docs.wasabi.com/docs/what-are-the-service-urls-for-wasabi-s-different-storage-regions), so it is important to select the correct region so that Cloudback can upload backups to your bucket. ### Provide Wasabi Access Key ID and Access Key Secret In the `Step 2`, provide the Access Key ID and Access Key Secret. These credentials are used to authenticate Cloudback with Wasabi. You can find more information on how to create Access Key in the [Wasabi documentation](https://docs.wasabi.com/docs/creating-a-user-account-and-access-key#assigning-an-access-key). ### Provide additional HTTP headers (Optional) In the `Step 3` field you can provide additional HTTP headers to be used when uploading backups to the bucket. The headers can be used to set the [S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) or [S3 Object Tagging](/supported-storages/amazon-s3-object-tagging) headers. ### Save storage Click on `Save` button to save the new storage. You can also use a `Test` button to check if the storage is configured correctly. After saving the storage, you can use it for storing backups of your repositories. All storage settings can be changed later in the `Storages` page. To edit the storage settings, click on the `Edit` button next to the storage you want to edit. ## Change the storage for a repository You can change the storage for a particular repository in the [Repository Details](/dashboard/repository-details) page. Also, you can assign it to multiple repositories through the [Bulk Operations](/managing-backups/bulk-operations). ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Dashboard Overview](/dashboard/dashboard-overview) * [Repository Details](/dashboard/repository-details) * [Bulk Operations](/managing-backups/bulk-operations) * [Replicating Backups](/storage-configuration/replicating-backups) # Encryption Management Learn how Cloudback encrypts backup archives and how to manage your own encryption keys for full control over backup security. Cloudback encrypts every backup archive with a unique password. You can use the built-in encryption (Cloudback manages everything) or bring your own encryption keys for full control. ## Pages * [Encryption Overview](/encryption-management/encryption-overview) - Built-in vs customer-managed encryption modes, choosing the right mode, and FAQs * [RSA Lockbox: Setup and Usage](/encryption-management/rsa-lockbox) - Create an RSA Lockbox encryption provider, assign it to accounts, restore and download encrypted backups, and rotate keys * [Customer-Held RSA Lockbox: Setup and Usage](/encryption-management/customer-held-rsa-lockbox) - RSA Lockbox variant where the encrypted password is stored as a `.lockbox` sidecar in your own backup storage # Encryption Overview Overview of Cloudback encryption modes - built-in and customer-managed - and how to choose the right one for your organization. Every Cloudback backup is a password-protected ZIP archive. The password is generated automatically for each backup and is never reused. What differs between encryption modes is **who controls that password** and how it is stored. Cloudback offers a built-in encryption mode and a growing family of customer-managed encryption key (CMEK) providers: | Mode | Who holds the key | Restore experience | Status | | -------------------------------- | --------------------------------------------------------------------------- | --------------------------------------------------------------- | --------- | | **Built-in (Cloudback-managed)** | Cloudback | Transparent - just click Restore or Download | Available | | **RSA Lockbox** | You (RSA key pair); ciphertext in Cloudback database | Paste your RSA private key each time | Available | | **Customer-Held RSA Lockbox** | You (RSA key pair); ciphertext as `.lockbox` sidecar in your backup storage | Paste your RSA private key each time | Available | | **External KMS** | Your KMS (AWS KMS, Azure Key Vault, GCP KMS, etc.) | Transparent - Cloudback calls your KMS at restore time | Planned | | **External Password API** | Your custom API | Transparent - Cloudback calls your API to retrieve the password | Planned | ## Built-in encryption (default) Every account starts with built-in encryption enabled. In this mode: * Cloudback generates a unique random password for each backup. * The password is stored in the Cloudback database, encrypted at rest. * When you restore or download a backup, Cloudback retrieves the password automatically. No action is required on your part. This mode is suitable for most users. It provides strong encryption with zero friction. ## CMEK providers ### RSA Lockbox RSA Lockbox puts you in full control of backup encryption. You provide your own RSA public key, and Cloudback uses it to encrypt each backup's password. The encrypted password (ciphertext) is stored in the database, but **only you can decrypt it** with your private key. Key properties: * Cloudback never stores or persists your private key. * If Cloudback's database were compromised, the attacker could not decrypt your backups without your private key. * You are responsible for safeguarding your private key. If you lose it, the backups protected by that key **cannot be recovered**. For a detailed walkthrough, see [RSA Lockbox: Setup and Usage](/encryption-management/rsa-lockbox). ### Customer-Held RSA Lockbox Customer-Held RSA Lockbox is a variant of RSA Lockbox where the encrypted password is stored as a `.lockbox` file beside the backup archive in your own backup storage, instead of in the Cloudback database. You supply an RSA public key, and Cloudback encrypts each backup's password with it. Only you can decrypt the archive password using your private key. Cloudback never stores your private key. This gives you control over both the private key and the encrypted password location. If Cloudback were compromised, your archives stay protected without your private key and the matching `.lockbox` sidecar file. For a detailed walkthrough, see [Customer-Held RSA Lockbox: Setup and Usage](/encryption-management/customer-held-rsa-lockbox). ### External KMS (planned) External KMS lets you delegate password encryption to your own key management service (e.g., AWS KMS, Azure Key Vault, or GCP Cloud KMS). On each backup, Cloudback sends the generated password to your KMS for encryption and stores only the ciphertext. At restore time, Cloudback calls your KMS to decrypt - no manual key input is required. This mode combines full customer control with a frictionless restore experience, and is ideal for organizations that already centralize key management. ### External Password API (planned) External Password API lets you bring your own password service. You configure a custom API endpoint, and Cloudback calls it to retrieve the password for a given backup. This gives you complete flexibility over how passwords are generated, stored, and rotated on your side. This mode is suited for teams with specialized security infrastructure or compliance requirements that go beyond standard KMS workflows. ## How encryption mode applies Encryption is configured **per account**, not per repository. You set the encryption mode in **Account Settings** under **Backup Encryption**. Once changed, all future backups for that account use the selected provider. Existing backups are not affected - they retain whatever encryption was active when they were created. You can create multiple CMEK providers (e.g., separate RSA Lockbox encryption providers for different teams) and share them across accounts using access controls. ## Choosing the right mode | Consideration | Built-in | RSA Lockbox | External KMS (planned) | External Password API (planned) | | ------------------- | ---------------------------- | ---------------------------------------- | ------------------------------- | ------------------------------------ | | Setup effort | None | Generate RSA key pair, upload public key | Configure KMS access | Deploy and configure your API | | Restore workflow | One-click | Paste private key each time | One-click (Cloudback calls KMS) | One-click (Cloudback calls your API) | | Key management | Cloudback handles everything | You manage your RSA private key | Managed by your KMS | Managed by your API | | Compliance (CMEK) | May not satisfy | Yes | Yes | Yes | | Risk if key is lost | None | Backups unrecoverable | Depends on your KMS policies | Depends on your API | ## Frequently asked questions **Can I switch between modes?** Yes. Changing the encryption mode in Account Settings affects only future backups. Existing backups remain accessible using whatever encryption was active when they were created. **What happens to existing backups when I switch providers?** Nothing. They stay encrypted with the previous provider and can still be restored normally. Only new backups use the newly selected provider. **Can I use different encryption for different repositories?** No. Encryption is set at the account level. All repositories under an account share the same encryption provider. **What RSA key sizes are supported?** RSA keys must be at least 2048 bits. Cloudback uses RSA-OAEP with SHA-256 for encryption. **When will External KMS and External Password API be available?** Both are on the roadmap. Check our changelog or contact support for the latest timeline. ## Learn More * [RSA Lockbox: Setup and Usage](/encryption-management/rsa-lockbox) - step-by-step setup, usage, and key rotation * [Password-Protected Archives](/security-and-compliance/password-protected-archives) - AES-256 ZIP encryption details * [Account Settings](/managing-backups/account-settings) - configuring the default encryption provider per account * [Audit Log](/security-and-compliance/audit-log) - tracking encryption provider operations # RSA Lockbox: Setup and Usage How to generate an RSA key pair, create an RSA Lockbox encryption provider in Cloudback, assign it to accounts, and rotate keys. RSA Lockbox is a customer-managed encryption key (CMEK) mode in Cloudback. You supply an RSA public key, and Cloudback encrypts each backup's password with it. Only you can decrypt those passwords using your private key. ## Prerequisites * An RSA key pair (minimum 2048 bits) in PEM format. * If you don't have one, see [Generating an RSA key pair](#generating-an-rsa-key-pair) below. ## How it works 1. **You provide your RSA public key.** The private key never leaves your infrastructure. 2. **For each backup,** Cloudback generates a unique random ZIP password and encrypts it with your public key using RSA-OAEP with SHA-256. Only the ciphertext is stored. 3. **To restore or download,** you paste your private key into a dialog. Cloudback decrypts the password in memory and never persists the private key. This gives you full control over backup encryption: even if Cloudback were compromised, your archives stay protected without your private key. ## Setting up RSA Lockbox ### Step 1: Create an encryption provider 1. Go to **Account Settings**. 2. Open the **Encryption Providers** section and click **Add Encryption Provider**. 3. Select **RSA Lockbox** as the type. 4. Enter a name for the provider (e.g., "Production RSA Key"). 5. Paste your RSA **public key** in PEM format into the text area. It should look like: ``` -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A... -----END PUBLIC KEY----- ``` 6. Click **Save**. Cloudback validates that the key is a valid RSA key of at least 2048 bits before accepting it. ![New Encryption Provider form](/files/T81EKrHjOWaGp0wieec2) ### Step 2: Set provider access 1. In the encryption provider's settings, open the **Access** panel. 2. Check the accounts that should use this provider. 3. Click **Save**. A single provider can be made available to multiple accounts. ![Encryption Provider Access Editor](/files/fTuhcRCXHlKmvcgver9k) ### Step 3: Select the provider for backups 1. Go to **Account Settings** for the target account. 2. Under **Backup Encryption**, select your new RSA Lockbox provider from the dropdown. 3. Click **Save**. All future backups for this account will now use the selected provider. Existing backups are not affected. ![Account Settings - Backup Encryption dropdown](/files/8VR2LHC5NNWlDs09c3lu) ## Restoring or downloading a backup When you restore or download a backup that was encrypted with RSA Lockbox, Cloudback will prompt you for your private key: 1. Click **Restore** or **Download** on the backup. 2. A dialog appears asking for your RSA private key. 3. Paste the private key in PEM format: ``` -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEA... -----END RSA PRIVATE KEY----- ``` Both PKCS#1 (`BEGIN RSA PRIVATE KEY`) and PKCS#8 (`BEGIN PRIVATE KEY`) formats are accepted. 4. Click **Submit**. Cloudback decrypts the backup password in memory and proceeds with the operation. The private key is used only for the duration of the request and is never stored. ## Rotating your RSA key If you need to replace your RSA key pair (e.g., for periodic rotation or after a suspected compromise), update the public key on the RSA Lockbox provider. Cloudback supports re-encrypting existing backup passwords with the new public key. ### Steps 1. Open the encryption provider you want to update. 2. Replace the public key with your new public key. 3. Click **Save**. 4. If there are existing backups encrypted with the old key, Cloudback will open a **Re-encryption** dialog: * **Phase 1:** Choose whether to re-encrypt existing passwords, skip re-encryption, or cancel. * **Phase 2:** If you chose to re-encrypt, paste the **old private key** so Cloudback can decrypt the existing passwords. * **Phase 3:** Cloudback re-encrypts all passwords with the new public key. Progress is shown during the operation. 5. Once complete, existing backup passwords have been re-encrypted with the new public key, and future backups use it too. ### What happens if you skip re-encryption? * The public key on the provider is updated. Future backups use the new public key. * Existing backups remain encrypted with the old key. You will need the **old private key** to restore or download them. * This means you must retain both the old and new private keys. ### Re-encryption details * Passwords are re-encrypted in batches, within a single database transaction. * If any row fails to decrypt (e.g., wrong private key), the entire operation rolls back and no changes are made. * The old private key is held in server memory only for the duration of the re-encryption request. ## Deleting an encryption provider You can delete a custom encryption provider only if there are **no active backups** protected by it. If backups still reference the provider, the delete button is disabled. To delete a provider that has active backups: 1. Delete or let the retention policy expire the backups protected by that provider. 2. Once no backups reference the provider, it can be deleted. ## Generating an RSA key pair If you don't already have an RSA key pair, you can generate one with OpenSSL: ```bash # Generate a 4096-bit RSA private key openssl genpkey -algorithm RSA -out private-key.pem -pkeyopt rsa_keygen_bits:4096 # Extract the public key openssl rsa -pubout -in private-key.pem -out public-key.pem ``` Upload the contents of `public-key.pem` to Cloudback. Store `private-key.pem` securely - you will need it every time you restore or download a backup. **Important:** If you lose your private key, any backups encrypted with the corresponding public key **cannot be recovered**. Store your private key in a secure location such as a hardware security module (HSM), a secrets manager, or an encrypted vault. ## Security considerations * **RSA-OAEP with SHA-256** is used for all encryption operations. This is the recommended padding scheme for RSA encryption. * **Minimum key size is 2048 bits.** We recommend 4096 bits for long-term protection. * **Cloudback never stores your private key.** It exists in server memory only during restore, download, or re-encryption requests, and is discarded immediately after. * **Key fingerprints** (first 16 hex characters of the SHA-256 hash of the public key) are recorded in the audit log for traceability, allowing you to verify which key was used without exposing the full key. ## Learn More * [Encryption Overview](/encryption-management/encryption-overview) - overview of all encryption modes * [Password-Protected Archives](/security-and-compliance/password-protected-archives) - AES-256 ZIP encryption details * [Account Settings](/managing-backups/account-settings) - configuring default settings per account * [Audit Log](/security-and-compliance/audit-log) - tracking all account activities # Customer-Held RSA Lockbox: Setup and Usage How to set up Customer-Held RSA Lockbox in Cloudback, where the encrypted backup password is stored as a .lockbox sidecar in your own backup storage, and how to restore using your private key. Customer-Held RSA Lockbox is a customer-managed encryption key (CMEK) mode in Cloudback. You supply an RSA public key, and Cloudback encrypts each backup's password with it. The encrypted password is stored as a `.lockbox` file beside the backup archive in your own backup storage. Only you can decrypt the archive password using your private key. Cloudback never stores your private key. ## Prerequisites * An RSA key pair (minimum 2048 bits) in PEM format. * Backup storage connected to the Cloudback account where you will select this provider. * If you don't have an RSA key pair, see [Generating an RSA key pair](#generating-an-rsa-key-pair) below. ## How it works 1. **You provide your RSA public key.** The private key never leaves your infrastructure. 2. **For each backup,** Cloudback generates a unique random ZIP password and encrypts it with your public key using RSA-OAEP with SHA-256. 3. **Cloudback stores the encrypted password in your backup storage** as a `.lockbox` sidecar file beside the archive. For example, `repo-2026-05-19.zip` has a sidecar file named `repo-2026-05-19.zip.lockbox`. 4. **To restore or download,** you paste the private key that matches the backup. Cloudback downloads the `.lockbox` file, decrypts the password in memory, and never persists the private key. This gives you control over both the private key and the encrypted password location. If Cloudback were compromised, your archives stay protected without your private key and the matching `.lockbox` sidecar file. ## Setting up Customer-Held RSA Lockbox ### Step 1: Create an encryption provider 1. Go to **Encryption** in the left navigation. 2. Click **Add Encryption Provider**. 3. Enter a name for the provider (e.g., "Production Customer-Held RSA Key"). 4. Under **Provider Type**, select **Customer-Held RSA Lockbox**. 5. Paste your RSA **public key** in PEM format into the text area. It should look like: ``` -----BEGIN PUBLIC KEY----- MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A... -----END PUBLIC KEY----- ``` 6. Click **Save**. Cloudback validates that the key is a valid RSA key of at least 2048 bits before accepting it. ### Step 2: Set provider access 1. Return to **Encryption**. 2. In the provider row, click **Edit Access**. 3. Check the accounts that should be allowed to use this provider. 4. Click **Save**. A single provider can be made available to multiple accounts. ### Step 3: Select the provider for backups 1. Go to **Account Settings** for the target account. 2. Under **Backup Encryption**, select your new Customer-Held RSA Lockbox provider from the dropdown. 3. Click **Save**. All future backups for this account will now use the selected provider. Existing backups are not affected. ## Restoring or downloading a backup When you restore or download a backup that was encrypted with Customer-Held RSA Lockbox, Cloudback will prompt you for the private key that matches that backup: 1. Click **Restore** or **Download** on the backup. 2. A dialog appears asking for your RSA private key. 3. Paste the private key in PEM format: ``` -----BEGIN RSA PRIVATE KEY----- MIIEowIBAAKCAQEA... -----END RSA PRIVATE KEY----- ``` Both PKCS#1 (`BEGIN RSA PRIVATE KEY`) and PKCS#8 (`BEGIN PRIVATE KEY`) formats are accepted. 4. Click **Submit**. Cloudback downloads the backup's `.lockbox` sidecar file, decrypts the archive password in memory, and proceeds with the operation. The private key is used only for the duration of the request and is never stored. The `.lockbox` sidecar file must still exist in backup storage for restore or download to work. ## Decrypting a lockbox file manually If you have downloaded a backup archive and its `.lockbox` sidecar file, you can decrypt the archive password outside Cloudback with OpenSSL. You need the private key that matches the public key used when the backup was created. ```bash zip_file=./fba309fa6224413ebc6baa65dd1530b1.zip lockbox_file="${zip_file}.lockbox" private_key_file=./private.key base64 -d -i "$lockbox_file" \ | openssl pkeyutl -decrypt \ -inkey "$private_key_file" \ -pkeyopt rsa_padding_mode:oaep \ -pkeyopt rsa_oaep_md:sha256 ``` The decrypted output is the ZIP archive password. Treat it as a secret, and avoid saving it in shell history, logs, or shared terminal output. ## Extracting password-protected archive Use the script below to decrypt the ZIP password and extract the archive contents. ```bash set -euo pipefail zip_file=./fba309fa6224413ebc6baa65dd1530b1.zip lockbox_file="${zip_file}.lockbox" private_key_file=./private.key output_dir="${zip_file}.extracted" zip_password="$( base64 -d -i "$lockbox_file" \ | openssl pkeyutl -decrypt \ -inkey "$private_key_file" \ -pkeyopt rsa_padding_mode:oaep \ -pkeyopt rsa_oaep_md:sha256 )" mkdir -p "$output_dir" # Extract password-protected outer ZIP 7z x "$zip_file" \ -p"$zip_password" \ -o"$output_dir" \ -y unset zip_password # Find and extract the inner ZIP without a password inner_zip="$(find "$output_dir" -maxdepth 1 -type f -iname '*.zip' -print -quit)" if [ -z "$inner_zip" ]; then echo "No inner ZIP found" >&2 exit 1 fi 7z x "$inner_zip" \ -o"$output_dir" \ -y ``` ## Rotating your RSA key If you need to replace your RSA key pair (e.g., for periodic rotation or after a suspected compromise), update the public key on the Customer-Held RSA Lockbox provider. Customer-Held RSA Lockbox does **not** re-encrypt existing `.lockbox` files. Changing the public key affects future backups only. ### Steps 1. Generate a new RSA key pair. 2. Open the encryption provider you want to update. 3. Replace the public key with your new public key. 4. Click **Save**. Future backups use the new public key. Existing backups remain encrypted with the old public key and still require the old private key. ### What happens to existing backups? * Existing `.lockbox` files are not changed. * Existing backups require the private key that matched the public key active when those backups were created. * You must retain old private keys until all backups encrypted with those keys have been deleted or expired by retention. ## Deleting an encryption provider You can delete a custom encryption provider only if there are **no active backups** protected by it. If backups still reference the provider, the delete button is disabled. To delete a provider that has active backups: 1. Delete or let the retention policy expire the backups protected by that provider. 2. Once no backups reference the provider, it can be deleted. Deleting a backup also deletes its `.lockbox` sidecar file from backup storage. ## Generating an RSA key pair If you don't already have an RSA key pair, you can generate one with OpenSSL: ```bash # Generate a 4096-bit RSA private key openssl genpkey -algorithm RSA -out private-key.pem -pkeyopt rsa_keygen_bits:4096 # Extract the public key openssl rsa -pubout -in private-key.pem -out public-key.pem ``` Upload the contents of `public-key.pem` to Cloudback. Store `private-key.pem` securely - you will need it every time you restore or download a backup encrypted with this key. **Important:** If you lose your private key, any backups encrypted with the corresponding public key **cannot be recovered**. If the matching `.lockbox` file is deleted or moved from backup storage, that backup also cannot be restored or downloaded. ## Security considerations * **RSA-OAEP with SHA-256** is used for all encryption operations. * **Minimum key size is 2048 bits.** We recommend 4096 bits for long-term protection. * **Cloudback never stores your private key.** It exists in server memory only during restore or download requests, and is discarded immediately after. * **Encrypted passwords are stored in your backup storage.** Each backup has a `.lockbox` sidecar file beside the archive it unlocks. * **Existing `.lockbox` files are not re-encrypted during key rotation.** Keep old private keys for old backups. * **Cloudback does not log plain archive passwords, private keys, or decrypted secrets.** * **Key fingerprints** (first 16 hex characters of the SHA-256 hash of the public key) are recorded in the audit log for traceability, allowing you to verify which key was used without exposing the full key. ## Learn More * [Encryption Overview](/encryption-management/encryption-overview) - overview of all encryption modes * [RSA Lockbox: Setup and Usage](/encryption-management/rsa-lockbox) - database-stored RSA Lockbox variant * [Password-Protected Archives](/security-and-compliance/password-protected-archives) - AES-256 ZIP encryption details * [Account Settings](/managing-backups/account-settings) - configuring default settings per account * [Audit Log](/security-and-compliance/audit-log) - tracking all account activities # Account and Billing Management Manage your Cloudback pricing, payment methods, subscriptions, and billing information. Manage your Cloudback subscription, payment methods, and organization settings. ## Payment & Billing * [Pricing](/account-and-billing-management/pricing) - Plans, pricing tables, billing cycles, and pay-as-you-go options * [Payment Methods](/account-and-billing-management/payment-methods) - Available payment options including GitHub Marketplace, Azure Marketplace, credit card, and bank transfer * [Subscription Management](/account-and-billing-management/subscription-management) - Manage subscriptions, assign to accounts, and view account coverage ## Enterprise Options * [Invoiced Customers](/account-and-billing-management/invoiced-customers) - Enterprise billing and invoicing options # Pricing Cloudback pricing plans, billing cycles, and pay-as-you-go options. Per-unit pricing across all supported platforms - all features included on every plan. Cloudback charges **per repository, not per user**. All plans include every feature - there are no feature gates or enterprise-only restrictions. ## How Units Work Each backup consumes units from your subscription pool. Units are shared across all connected accounts and platforms. | Platform | Unit Cost | | ------------ | -------------------------------------------------------------------------------------------------------------------------------- | | GitHub | 1 unit per repository | | Azure DevOps | 1 unit per repository | | GitLab | 1 unit per project | | Linear | Tiered per active workspace member: 2 units for members 1-5, 4 units for members 6-25, 6 units for members 26+ (minimum 2 units) | For platform-specific details, see: [GitHub](/github/pricing) | [Azure DevOps](/azure-devops/pricing) | [GitLab](/gitlab/pricing) | [Linear](/linear/pricing) ## Fixed Plans Fixed plans include a set number of units. Monthly fixed plans include a **free first month**. | Plan | Included Units | Monthly | Annual | 2-Year | 3-Year | | -------------- | ------------------------------------------------- | ------- | ------ | ------- | ------- | | **Free** | 1 repository per connected account (100 MB limit) | $0 | - | - | - | | **Basic** | 10 | $10 | $114 | $216 | $306 | | **Team** | 100 | $75 | $855 | $1,620 | $2,295 | | **Enterprise** | 1,000 | $500 | $5,700 | $10,800 | $15,300 | You can purchase multiple units of each plan to increase coverage (e.g., 2x Basic = 20 units). ## Pay-as-you-go Plans Pay-as-you-go (metered) plans include the same base units as fixed plans, plus the ability to add repositories beyond the included amount at a per-unit rate. Billing adjusts automatically based on usage. | Plan | Included Units | Additional Units | Monthly | Annual | 2-Year | 3-Year | | ---------------------------- | -------------- | ---------------- | ------- | ------ | ------- | ------- | | **Basic Pay-as-you-go** | 10 | $1.00/unit | $10 | $114 | $216 | $306 | | **Team Pay-as-you-go** | 100 | $0.75/unit | $75 | $855 | $1,620 | $2,295 | | **Enterprise Pay-as-you-go** | 1,000 | $0.50/unit | $500 | $5,700 | $10,800 | $15,300 | Cloudback supports up to 10,000 repositories per account. Need more? [Contact us](/troubleshooting-and-support/contact-us). ## Free Plan Every connected account gets 1 free backup slot independently - no subscription assignment required. This allows you to back up one repository or project per account at no cost. The free slot covers repositories only. Linear has no free plan - every Linear workspace is billed using the member tiers above. See [Linear Pricing](/linear/pricing). ## How to Subscribe All paid plans include a **free trial** so you can test the service before committing. * **Credit Card (direct checkout)**: Buy a subscription with a credit card directly from the **Subscriptions** page in the Cloudback dashboard, paid through [Paddle](https://paddle.com). See [Payment Methods](/account-and-billing-management/payment-methods) for details. * **GitHub Marketplace**: Purchase from the [GitHub Marketplace listing](https://github.com/marketplace/cloudback) - billing through your GitHub account. * **Azure Marketplace**: Purchase from the [Microsoft Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/myrtlelabs-sas.cloudback) - billing through your Azure account. * **Azure DevOps Marketplace**: Install via the [Visual Studio Marketplace](https://marketplace.visualstudio.com/items?itemName=MYRTLELABSSAS.cloudback-backup-azure-devops). * **Coupa Supplier Portal**: Procurement-friendly purchasing via [Coupa](https://supplier.coupahost.com/suppliers/public/myrtlelabs-sas-GmZw0) - [contact us](/troubleshooting-and-support/contact-us) to coordinate. * **Bank Transfer / Invoice**: Available for quarterly plans and enterprise customers - [contact us](/troubleshooting-and-support/contact-us). After purchase, you can assign your subscription to multiple accounts across all platforms. See [Subscription Management](/account-and-billing-management/subscription-management) for details. ## Learn More * [Subscription Management](/account-and-billing-management/subscription-management) - Manage subscriptions and account assignments * [Payment Methods](/account-and-billing-management/payment-methods) - All supported payment options * [Invoiced Customers](/account-and-billing-management/invoiced-customers) - Enterprise billing options # Payment Methods Explore Cloudback's flexible payment options including direct credit-card checkout via Paddle, GitHub Marketplace, Azure Marketplace, bank transfer, and Coupa Supplier Portal. Cloudback offers a variety of payment methods to purchase a subscription. You can choose the one that best fits your billing and procurement process. This document provides an overview of the available payment methods. > **Tip**: After purchasing a subscription, you can assign it to multiple accounts across all supported platforms. This allows you to manage backups for your entire infrastructure under a single subscription. See [Subscription Management](/account-and-billing-management/subscription-management) for details. The **Subscriptions** page in the Cloudback dashboard has a **Ways to add a subscription** section at the top, which lists every available purchase route: * **Paddle checkout** - buy directly from Cloudback with a credit card * **GitHub Marketplace** - use existing GitHub billing * **Azure Marketplace** - use existing Microsoft Azure billing * **Coupa Supplier Portal** - use Coupa-based procurement For invoice or bank transfer, contact the support team - these options are arranged off-platform. ## Direct Credit-Card Checkout (Paddle) You can purchase a Cloudback subscription directly from the **Subscriptions** page in the dashboard with a credit card. Payments are processed through [Paddle](https://paddle.com). Follow these steps to purchase a plan directly: 1. Log in to the [Cloudback Dashboard](https://app.cloudback.it) and open the **Subscriptions** page from the main navigation. 2. In the **Ways to add a subscription** section at the top of the page, click **Paddle checkout**. 3. In the plan-selection dialog, choose your billing cycle (**Monthly** or **Annual**) and select a plan (**Basic**, **Team**, or **Enterprise**). 4. Click **Continue to Checkout** and complete the payment through Paddle's secure checkout. 5. Once the checkout completes, the Subscriptions page automatically refreshes and your new subscription appears in the table. ## GitHub Marketplace Payments GitHub Marketplace is a platform that allows you to find, purchase, and install tools that extend your workflow. Cloudback offers a range of plans designed to fit different team sizes and needs. Every plan includes a free trial, so you can test the service before committing. Follow these steps to purchase a plan: * Select your preferred plan on the [Cloudback page on the GitHub Marketplace](https://github.com/marketplace/cloudback). * Follow GitHub instructions to complete the purchase. * Cloudback will automatically activate for the selected account. * After purchase, you can assign additional accounts (including Azure DevOps organizations and Linear workspaces) to share the subscription. ## Azure Marketplace Payments Azure Marketplace is an online store that offers applications and services for use on Azure. Cloudback offers a range of plans, all with flexible pay-as-you-go options. Just like with GitHub Marketplace, every plan includes a free trial. Follow these steps to purchase a plan: * Select your preferred plan on the [Cloudback page on the Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/myrtlelabs-sas.cloudback?tab=Overview). * Follow Azure instructions to complete the purchase. * Purchased plans will be activated automatically. * After purchase, you can assign additional accounts (including GitHub organizations and Linear workspaces) to share the subscription. ## Bank Transfer Payments Bank transfer payments are available starting from quarterly plans. This method is suitable for users who prefer to pay in advance for a longer period. Follow these steps to purchase a plan: * To start the process, contact the support team at . * The team will guide you through the purchase process. ## Coupa Supplier Portal Coupa's Supplier Portal connects purchasing organizations with suppliers, providing tools to get paid faster and manage procurement at scale. Follow these steps to purchase a plan: * To start the process, visit our [supplier's page](https://supplier.coupahost.com/suppliers/public/myrtlelabs-sas-GmZw0) on Coupa Supplier Portal. * Contact the support team at . * The team will guide you through the purchase process. ## Learn More * [Subscription Management](/account-and-billing-management/subscription-management) - Assign subscriptions to multiple accounts * [Invoiced Customers](/account-and-billing-management/invoiced-customers) - Enterprise billing options # Subscription Management Learn how to manage your Cloudback subscriptions, assign them to different accounts, and view account coverage across all supported platforms. The Subscriptions page in Cloudback provides a centralized view of all your subscriptions and allows you to manage how they are assigned to your connected accounts. ## Accessing the Subscriptions Page 1. Log in to the [Cloudback Dashboard](https://app.cloudback.it) 2. Click on **Subscriptions** in the main navigation ## How Units Work Subscriptions are measured in **units**. Each subscription provides a pool of units, and each backup definition consumes units from that pool when enabled. ### Units per Platform | Platform | Unit Cost | Example | | ------------ | -------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- | | GitHub | 1 unit per repository | 10 repos = 10 units | | Azure DevOps | 1 unit per repository | 10 repos = 10 units | | GitLab | 1 unit per project | 10 projects = 10 units | | Linear | Tiered per active workspace member: 2 units for members 1-5, 4 units for members 6-25, 6 units for members 26+ (minimum 2 units) | Workspace with 10 active members = 30 units | For Linear, the unit count is recalculated automatically after each backup and on reconnect, based on the current count of active, non-app workspace members. See [Linear Pricing](/linear/pricing) for the full tier breakdown and worked examples. ### How Subscription Capacity Works Your subscription's total units are shared across all assigned accounts. For example, a 100-unit subscription assigned to two accounts allows a combined total of 100 enabled backups (assuming 1 unit each). * **Total**: The number of units purchased with your subscription * **Scheduled**: The number of units currently consumed by enabled backup definitions * **Available**: Total minus Scheduled - the remaining capacity When you enable a backup, Cloudback checks whether enough units are available. If not, the backup cannot be enabled. ### Fixed vs Metered Plans * **Fixed plans**: Have a hard unit limit. You cannot enable more backups than your purchased units allow. If your subscription is downgraded or an account is unassigned, Cloudback may automatically disable backup definitions that exceed the new limit. * **Metered plans**: Scale automatically with usage. There is no hard cap - billing adjusts based on the number of enabled backups. ### Free Plan Every connected account gets 1 free backup slot independently - no subscription assignment required. This allows you to back up one repository per account at no cost. The free slot does not apply to Linear - Linear has no free plan, and every workspace consumes units based on its active member count. ## Purchasing a Subscription The Subscriptions page has a **Ways to add a subscription** section at the top of the page, listing every available purchase route as a card: | Card | What it does | | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | **Paddle checkout** | Opens a plan-selection dialog, then launches Paddle's secure checkout so you can pay by credit card. | | **GitHub Marketplace** | Opens the Cloudback listing on the GitHub Marketplace in a new tab so you can purchase with existing GitHub billing. | | **Azure Marketplace** | Opens the Cloudback listing on the Azure Marketplace in a new tab so you can purchase with existing Microsoft Azure billing. | | **Coupa Supplier Portal** | Opens Cloudback's Coupa supplier page for procurement teams that use Coupa. | For invoice or bank transfer, use the **contact us** link in the section description - these payment methods are arranged off-platform. ### Paddle Direct Checkout Flow 1. Click **Paddle checkout** in the **Ways to add a subscription** section. 2. In the "Choose your plan" dialog, pick a billing cycle (**Monthly** or **Annual**) and select a plan tier (**Basic** - 10 units, **Team** - 100 units, or **Enterprise** - 1,000 units). 3. Click **Continue to Checkout** and complete the payment through Paddle's secure checkout. 4. The Subscriptions page automatically refreshes once the purchase finishes, and your new subscription appears in the My Subscriptions table. See [Payment Methods](/account-and-billing-management/payment-methods) for full details on each purchase route. ## My Subscriptions The Subscriptions page displays a table of all subscriptions associated with your account. ![Subscriptions table](/files/LbFlHwf7XqdqP4ZB70kn) The table includes the following columns: | Column | Description | | ------------- | ----------------------------------------------------------------------- | | Plan Name | The subscription plan name, plus free trial status if applicable | | Status | Current status badge (Active or Cancelled) | | Source | Where the subscription was purchased (GitHub, Azure, Invoiced) | | Price | Subscription price (shows "Free for OSS" for open source subscriptions) | | Billing Cycle | Monthly, Quarterly, Semi-Annually, Annually, etc. | | Total | Total units purchased with the subscription | | Scheduled | Units currently in use (assigned to enabled backups) | | Consumption | Visual progress bar showing usage percentage | | Assignments | List of accounts assigned to this subscription | | Actions | View button to open subscription details | You can export the subscriptions table to CSV using the **Export CSV** button. ## Account Coverage Below the subscriptions table, the Account Coverage section provides an overview of backup definitions across all your connected accounts. ![Account coverage](/files/FyENWYbjbVbv0wTPMbAw) | Column | Description | | --------- | ------------------------------------------------------------------- | | Account | Account name with platform icon | | Total | Total units available for the account (from assigned subscriptions) | | Scheduled | Units currently in use by enabled backups | | Coverage | Visual progress bar showing backup coverage percentage | | Plan Type | Shows "Metered" or "Fixed" based on assigned subscription type | This overview helps you identify accounts that may need additional subscription capacity or have unused backup slots. You can export this data to CSV using the **Export CSV** button. ## Assigning Subscriptions to Accounts Subscriptions can be assigned to multiple accounts, allowing you to share a single subscription across different accounts - including accounts from different platforms. This makes it easier to manage backups across your entire infrastructure. ### To Assign a Subscription 1. Navigate to the **Subscriptions** page 2. Locate the subscription you want to assign 3. Click the **View** button in the Actions column to open the subscription details modal 4. In the modal, scroll to the **Account Assignments** section 5. Under "Assign New Account", select an account from the dropdown 6. Click the **Assign** button 7. The account will be added to the assignments list ### To Remove an Assignment 1. Navigate to the **Subscriptions** page 2. Click the **View** button for the subscription you want to modify 3. In the subscription details modal, find the **Account Assignments** section 4. Locate the assignment you want to remove 5. Click the remove (minus) icon next to the assignment 6. Confirm the removal in the warning dialog > **Note**: Some assignments are non-removable. The account where the subscription was originally purchased through GitHub Marketplace or Azure Marketplace cannot be unassigned. At least one account must remain assigned to each subscription. ## Subscription Details Modal Clicking the **View** button opens a detailed modal with detailed subscription information. ![Subscription details](/files/lsLnS3zRPHu9JDOfcvgT) ### Key Metrics * **Plan Units Purchased**: Number of subscription units purchased * **Units Purchased**: Total units purchased (Quantity × units per plan) * **Final Price**: The subscription price after discounts ### Plan Information * Plan type (Metered or Fixed) * Start and end dates * Next billing date * Free trial status and end date (if applicable) * Pricing breakdown including base price, add-ons, and discounts ### Account Assignments Lists all accounts assigned to the subscription with options to add or remove assignments. ### Action Buttons Depending on the subscription source, you may see buttons to manage your subscription in the original marketplace (GitHub Marketplace, Azure Marketplace, etc.). ## Subscription Sources Subscriptions can come from different sources: | Source | Description | | ------------------ | ----------------------------------------------------------- | | GitHub Marketplace | Subscriptions purchased through GitHub Marketplace | | Azure Marketplace | Subscriptions purchased through Azure Marketplace | | Credit Card | Direct purchases through Paddle from the Subscriptions page | | Invoiced | Enterprise subscriptions with custom billing | Each source may have different rules for assignment management. For example: * **Open Source (OSS) subscriptions**: Account assignments cannot be modified for Open Source subscriptions * **Marketplace subscriptions**: The original account is automatically assigned and cannot be removed ## Managing Multiple Accounts You can connect multiple accounts from all supported platforms to a single Cloudback dashboard: * Each account appears separately in the platform-specific section of the left sidebar * Use the left navigation to switch between platform views * A single subscription can cover multiple accounts - including accounts from different platforms ## Managing Multiple Subscriptions If you have multiple subscriptions, you can: * Assign each subscription to different accounts for isolated billing * Assign multiple subscriptions to the same account for increased capacity * View aggregate usage across all subscriptions ## Troubleshooting ### Cannot Assign Subscription If you cannot assign a subscription to an account: 1. Verify you have admin access to the target account 2. Check if the subscription has reached its assignment limit 3. Ensure the account is properly connected to Cloudback ### Cannot Remove Assignment If you cannot remove an assignment: 1. Check if it's the original purchase account (non-removable) 2. Verify the subscription isn't an Open Source subscription 3. Ensure the account doesn't have active backups that exceed the remaining capacity ### Subscription Not Showing If a subscription isn't appearing in your dashboard: 1. Verify the subscription is active in the marketplace (GitHub or Azure Marketplace) 2. Check that you're logged in with the correct account 3. Contact if the issue persists ## Learn More * [Payment Methods](/account-and-billing-management/payment-methods) - How to purchase subscriptions * [Invoiced Customers](/account-and-billing-management/invoiced-customers) - Enterprise billing options # Invoiced Customers Information for GitHub Enterprise and invoiced customers on how to purchase Cloudback plans through direct bank transfers instead of GitHub Marketplace. For those who hold **GitHub Enterprise** accounts and/or settle their GitHub payments through invoices, you will not be able to acquire paid plans from Cloudback via the [GitHub Marketplace](https://github.com/marketplace). Any attempts to do so will result in an error message `Unfortunately, invoiced customers cannot purchase paid plans on the GitHub Marketplace`. However, there is a positive twist to this situation. Cloudback provides an alternative option in the form of direct bank transfers for payment. Simply [get in touch](/troubleshooting-and-support/contact-us), and the team will organize a complimentary trial period for you. ## Learn More * [GitHub Enterprise](https://docs.github.com/en/get-started/learning-about-github/githubs-plans#github-enterprise) * [GitHub Marketplace](https://github.com/marketplace) # Troubleshooting and Support Find solutions to common issues with Cloudback backups and learn how to contact support for additional assistance. Find solutions to common issues and get help when you need it. ## Support Resources * [Known Issues](/troubleshooting-and-support/known-issues) - Solutions to common problems * [IP Address Whitelist](/troubleshooting-and-support/ip-whitelist) - Configure network access for Cloudback * [Contact us](/troubleshooting-and-support/contact-us) - Get in touch with the support team # Known Issues Documentation of known issues in Cloudback, including GitHub organization role changes and their impact on dashboard access, with detailed workarounds. ## "Resource protected by organization SAML enforcement. You must grant your OAuth token access to this organization" Error When Restoring Repository If you see the error message "**Resource protected by organization SAML enforcement. You must grant your OAuth token access to this organization**." when restoring a repository, please follow the steps below to resolve it. ### Why Does This Happen? This error occurs because your GitHub organization has enabled SAML-based SSO (Single Sign-On) **after** you originally authorized the Cloudback Restore GitHub Application. When SSO is enforced, you must explicitly grant your OAuth token (used by Cloudback) access to your organization. ### Symptoms * You try to restore a repository into an SSO-enabled GitHub organization. * You receive the error: **"Resource protected by organization SAML enforcement. You must grant your OAuth token access to this organization."** ### Solution: Re-authorize Cloudback Restore With SAML Access Follow these steps to resolve the issue: 1. **Go to your** [**GitHub Authorized OAuth Apps**](https://github.com/settings/applications) **page.** 2. In the list, find **Cloudback Restore**. 3. Click **Revoke** next to Cloudback Restore. 4. Return to Cloudback and try restoring your repository again. 5. You will be prompted to re-authorize the Cloudback Restore app.\ **Important:** On this prompt, ensure you grant access to your organization with the required SAML permissions. ### Additional Notes * You must complete the re-authorization process for **each** organization where SAML SSO is enforced. * This process is necessary whenever your organization enables SAML SSO **after** your initial Cloudback authorization. ## "It is required to install our GitHub Application" Error After Changing Organization Member Role to Owner If you see the error message **"It is required to install our GitHub Application"** after changing a member’s role to **Owner** in your GitHub organization, please follow the steps below to resolve the issue. ### Why Does This Happen? This error can appear right after you promote a user to the **Owner** role in your GitHub organization. It happens because GitHub does **not** notify Cloudback of this role change immediately. Cloudback relies on cached data from GitHub, so new Owner permissions may not be recognized right away. **Note:** This is a known GitHub limitation and has been confirmed by the GitHub Support Team. ### Symptoms * You have changed a member’s role to **Owner** in your GitHub organization. * The member tries to access the Cloudback Dashboard. * The following error appears: **"It is required to install our GitHub Application"** ### Workarounds #### 1. Clear the Cache in Cloudback 1. Go to the Cloudback Dashboard. 2. Open the [**Contact us**](https://app.cloudback.it/contactus) menu. 3. Click the **Clear cache** button. 4. Try accessing the dashboard again. #### 2. Remove and Re-Add the Member If clearing the cache does not resolve the issue: 1. Remove the affected member from your GitHub organization. 2. Re-add them to the organization with the **Owner** role. 3. Have the member try accessing the Cloudback Dashboard again. ### Additional Notes * The Cloudback Dashboard is accessible **only to organization owners**. * This issue will persist until GitHub improves how role changes are communicated to installed applications. # IP Address Whitelist Configure IP address allowlisting to ensure Cloudback can access your GitHub repositories and maintain uninterrupted backup operations. > **Note**: This feature is also commonly referred to as "IP allowlisting." Both terms are used interchangeably in the industry. Cloudback requires network access to your GitHub repositories to perform automated backups and restore operations. In some cases, organizations implement IP address restrictions or allowlists to control access to their GitHub resources. If your organization uses such security measures, you'll need to add Cloudback's IP addresses to your allowlist to ensure uninterrupted service. ## When IP Allowlisting Is Required You may need to configure IP allowlisting if your organization: * Uses GitHub Enterprise Cloud with IP allowlists enabled for organization resources * Implements network-level security policies that restrict access by IP address * Experiences connectivity issues or backup failures related to network access restrictions If you're unsure whether your organization uses IP allowlists, contact your GitHub organization administrator or IT security team. ## Cloudback IP Addresses To ensure Cloudback can access your repositories, add the following IP addresses to your organization's allowlist: * `20.84.111.92` * `107.152.33.120` * `162.212.158.169` * `130.51.21.102` * `94.16.121.148` * `37.120.161.146` * `152.53.253.208` **Important**: All seven IP addresses must be added to the allowlist for Cloudback to function properly. Partial configuration may result in intermittent connectivity issues or backup failures. For step-by-step instructions on how to configure IP allowlists in GitHub, see the [GitHub documentation](https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization). ## Troubleshooting If you continue to experience connectivity issues after adding the IP addresses: * **Verify all seven IP addresses** are correctly entered in your allowlist without typos. * **Check for additional network restrictions** that may be in place at the infrastructure or firewall level. * **Review your GitHub organization settings** to ensure IP allowlists are properly configured. * **Contact Cloudback support** at for assistance. ## Learn More * [Managing allowed IP addresses for your organization](https://docs.github.com/en/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/managing-allowed-ip-addresses-for-your-organization) - GitHub Documentation * [Contact Cloudback Support](/troubleshooting-and-support/contact-us) - Get help with configuration issues # Contact us Get in touch with Cloudback support via email, submit issues or feature requests through our GitHub issue tracker, or find our company contact information. ## Contact us by email Use any of these emails to contact us: * Questions regarding our privacy policy: * Questions about Cloudback functionality: ## Issue tracker If you have any issues with the product or any ideas about how it can be improved, please feel free to raise a request using our [issue tracker](https://github.com/cloudback/issue-tracker): * [Submit an issue](https://github.com/cloudback/issue-tracker/issues/new?template=bug_report.md) * [Create a feature request](https://github.com/cloudback/issue-tracker/issues/new?template=feature_request.md) ## Company name and address We are the MYRTLELABS S.A.S. (former MYRTLE GROUP S.A.) Address:\ Ecuador, Quito\ La Armenia, Juan Leon Mera y Numa Pompillo\ Conjunto Prados de la Armenia N9-960\ RUC 1793212306001\ Postal code 170803\ Email: \ Website: [cloudback.it](https://cloudback.it) # Security and Compliance Learn about Cloudback's security features and compliance standards for backups, including encryption, access controls, and audit capabilities. Cloudback provides enterprise-grade security features to protect your backup data and help meet compliance requirements. ## Security Features * [Access Review: Vanta Integration](/security-and-compliance/vanta-integration) - Automated compliance monitoring with Vanta * [Immutability: Amazon S3 Object Lock](/security-and-compliance/amazon-s3-object-lock) - Protect backups from deletion or modification * [Encryption: Password-Protected Archives](/security-and-compliance/password-protected-archives) - AES-256 encryption for backup archives * [Encryption: Customer-Managed Keys](/encryption-management/encryption-overview) - Bring your own encryption keys (see [Encryption Management](/encryption-management)) * [Traceability: Audit Log](/security-and-compliance/audit-log) - Track all activities in your account # Access Review: Vanta Integration Set up and manage the integration between Cloudback and Vanta for automated security compliance monitoring, including user data synchronization and audit logging. Vanta is a security and compliance tool that helps companies achieve compliance with SOC 2, ISO 27001, and other security standards. Vanta provides a platform that helps companies prepare for audits by automating the collection of evidence and providing guidance on how to improve security practices. Cloudback integrates with Vanta to provide a smooth experience for customers who use both services. This document explains how to set up the integration and what data is shared between Cloudback and Vanta. ## Setting up the Integration To set up the integration between Cloudback and Vanta, follow these steps: * Log in to Vanta, and navigate to the [Integrations page](https://app.vanta.com/integrations?state=available). * Locate "Cloudback" in the list, click "Connect," then select "Connect to Cloudback". * Follow the installation instructions. You will be redirected to Cloudback to log in and authorize the integration. * Once the installation is complete, you will be redirected back to Vanta. Cloudback will now be connected and users automatically uploaded to Vanta. ## Data Shared with Vanta The Cloudback-Vanta integration automatically syncs user data between Cloudback and Vanta. Cloudback sends a list of users to Vanta, including their email addresses. The list takes into account all users who have access to Cloudback across all connected platform accounts. For example, if you have 3 different GitHub organizations and 1 Linear workspace connected to Cloudback, Vanta will receive a combined list of users from all 4 accounts. Cloudback shares the following user data with Vanta: * **Account:** Platform account name * **Email address:** The email address associated with the user's account * **User role:** Cloudback roles are mapped to Vanta permission levels as follows: **Global Admin** → `ADMIN`, **Admin** → `EDITOR`, all other roles → `BASE`. All the data is shared immediately after the integration is enabled, and every 24 hours to ensure that Vanta has the most up-to-date information about Cloudback users. If something goes wrong during the data sync, Cloudback will automatically disable the integration. The integration can be re-enabled by following the steps outlined in the "Setting up the Integration" section. You can check the reason for the integration failure in the audit log. ## Audit Log Cloudback records all user actions in an audit log. The audit log also captures all actions related to the Vanta integration, including when the integration was enabled, disabled, or updated. The audit log is available to all Cloudback users. To locate the audit log records related to the Vanta integration, filter the log by the "Vanta Integration" action type. ## Disabling the Integration To disable the Cloudback-Vanta integration, follow these steps: * Log in to Vanta, and navigate to the [Integrations page](https://app.vanta.com/integrations?state=connected). * Locate "Cloudback" in the list, click "Manage" then select "Delete". * Confirm the deletion by clicking "Delete credential and data" in the confirmation dialog. Cloudback will automatically stop sharing user data with Vanta once the integration is disabled; no further action is required. ## Learn More * [Vanta Partners](https://www.vanta.com/partners/find-a-partner) * [Cloudback on Vanta partners page](https://www.vanta.com/partners/find-a-partner?title=Cloudback) * [Audit Log](/security-and-compliance/audit-log) # Immutability: Amazon S3 Object Lock Protect backups from deletion with Amazon S3 Object Lock, ensuring compliance with data retention regulations and enhancing security. [Amazon S3 Object Lock](https://aws.amazon.com/s3/features/object-lock/) is a feature provided by Amazon Web Services in their Simple Storage Service. It's designed to help you protect your data from being accidentally or intentionally deleted or overwritten. Cloudback supports S3 Object Lock feature for [customer-managed storages](/storage-configuration/customer-managed-storages) and allows you to enable it for your backups. ## Key Benefits of Amazon S3 Object Lock Support * **Enhanced Data Protection**: With Amazon S3 Object Lock, you can implement retention policies to ensure your backups remain untouched during a specified period. This prevents the accidental or malicious deletion of your backups and offers greater peace of mind. * **Compliance with Industry Regulations**: For organizations that need to comply with industry-specific regulations such as HIPAA, GDPR, or SEC Rule 17a-4, Amazon S3 Object Lock offers a convenient solution to meet data retention requirements. ## Get Started with Amazon S3 Object Lock 1. Create an AWS S3 bucket with Object Lock enabled: 1. Sign in to Amazon S3 Console 2. Enable Object Lock for your bucket: [Bucket configuration](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html#object-lock-bucket-config) 2. Configure your Cloudback's storage with Object Lock: 1. Sign in to your Cloudback account and navigate to the repository details page 2. Open repository settings and click the 'New Storage' button to open the `New Storage` page 3. Select `Amazon S3 AccessKey` storage provider and fill in `Step 4` with HTTP headers ## S3 Bucket Configuration in AWS Console Before you can lock any objects, you have to configure a bucket to use S3 Object Lock. To do this, you specify when you create the bucket that you want to enable Object Lock. After you configure a bucket for Object Lock, you can lock objects in that bucket using retention periods, legal holds, or both. You can find more information in the [official documentation](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-overview.html#object-lock-bucket-config). ## Storage Configuration in Cloudback Dashboard ### New Storage page In general, S3 object Lock parameters are specified using HTTP headers for the [PutObject](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) API call. There is an additional step in the `New Storage` page where you can provide additional HTTP headers for backups. Additional HTTP headers are supported for all S3 compatible storage, such as: * Amazon S3 Bucket: Access Point * Amazon S3 Bucket: Access Key * OpenStack Swift Container: S3 API * Wasabi S3 Bucket: Access Key The `New Storage` page with additional HTTP headers looks like this: ![HTTP headers for S3 Object Lock](/files/nwa6bPdp0omAZ0bmr168) ### HTTP headers for S3 Object Lock The headers are specified in the format `key:value` divided by a new line. For example: ``` x-amz-object-lock-mode: COMPLIANCE x-amz-object-lock-retain-until-date: 2027-01-01T00:00:00Z ``` Below is the list of S3 Object Lock related headers: #### x-amz-object-lock-mode * Must be `COMPLIANCE` or `GOVERNANCE` (case-sensitive). Cloudback passes the value through to AWS S3 without restriction. * If you specify `x-amz-object-lock-mode`, you must also specify `x-amz-object-lock-retain-until-date`. * `s3:PutObjectRetention` permission is required to use this header. #### x-amz-object-lock-retain-until-date * Format `yyyy-MM-ddThh:mm:ssZ`. The retain-until-date value must be in the format 2027-04-23T11:28:00Z. Fractional seconds are allowed, but only 3 decimal digits are preserved (milliseconds precision). Other ISO 8601 formats are not allowed. * The retain-until-date must be in the future. * [Dynamic values for retain-until-date](#dynamic-values-for-headers) can be used. #### x-amz-object-lock-legal-hold * Can be `ON` or `OFF` (case-sensitive). If legal hold is `ON`, the object is placed under a legal hold. If legal hold is OFF, no legal hold is placed. Any other value results in a 400 Bad Request (InvalidArgument) error. * `s3:PutObjectLegalHold` permission is required to use this header. #### Content-MD5 * The required `Content-MD5` header is added by Cloudback automatically, no need to specify it manually. ### Dynamic values for headers Cloudback uses [Scriban](https://github.com/scriban) templates to dynamically calculate values. It evaluates expressions inside braces `{{ }}`. You can see how it works in the examples given below. If you need more scripting options, you can consult the scriban documentation: * For date functions, visit [here](https://scriban.github.io/docs/builtins/date) * For a list of built-in functions, check [this link](https://scriban.github.io/docs/builtins) * General documentation can be found [here](https://scriban.github.io/docs) ### Examples of HTTP headers #### Retain the object for 1 month from the current date: ``` x-amz-object-lock-mode:COMPLIANCE x-amz-object-lock-retain-until-date:{{ date.now | date.add_months 1 }} ``` #### Retain the object for 1 year from the current date: ``` x-amz-object-lock-mode:COMPLIANCE x-amz-object-lock-retain-until-date:{{ date.now | date.add_years 1 }} ``` ## Learn More * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * External Article: [Using S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) * External Article: [Managing S3 Object Lock](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock-managing.html) # Encryption: Password-Protected Archives Secure your backups with Cloudback's AES-256 encryption and password protection, ensuring data confidentiality and tamper-proof archives. Every backup is stored as a ZIP archive that is automatically encrypted with a unique, system-generated password. This ensures that your backup data remains confidential and tamper-proof. ## Encryption Standards The archive is built using [ZIP File Version 5.2](https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-5.2.0.txt) combined with [AES-256](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) encryption-one of the strongest encryption methods available. > **Note:** Many built-in ZIP utilities (e.g., Microsoft Windows Compressed Folders) do not support AES encryption. For optimal compatibility, we recommend third-party tools such as [7-Zip](https://www.7-zip.org/). ## Double-Archive Method To protect filenames, Cloudback embeds one ZIP archive inside another. Filename encryption is introduced in [ZIP File Format Specification 6.2](https://pkware.cachefly.net/webdocs/APPNOTE/APPNOTE-6.2.0.txt). We use version 5.2 for better compatibility while still protecting your filenames. ## Managing Encryption Settings For customer managed storages, you have the option to disable archive encryption: * **Disabling Encryption:** Edit your customer managed storage settings and select `ZIP archive without password protection`. > **WARNING:** Disabling encryption requires that you implement alternative measures to secure your data. * **Enabling Encryption:** To ensure maximum security, choose `Password-protected ZIP archive`. ![Setting up archive type](/files/EebGRrLAiuTxsrcEafuQ) Cloudback-managed storages always enforce password protection to maximize data safety. ## Archive Sample & Password You can download a sample archive to test your extraction tools: * **Download:** [bee12062e5d741b1baf334088c2c980d.zip](https://github.com/cloudback/docs/raw/refs/heads/master/static/features/bee12062e5d741b1baf334088c2c980d.zip) * **Password:** `c8f42392e86e4f7fbe8b4adf7ec65694` ![Archive encryption method](/files/WBQarjMD111zxxDN1OKt) ![Archive password](/files/QA8KJKGTNUvUT9ZseeFA) ![Archive content](/files/MX5kUbeXpbMkS462LUxu) ## Customer-Managed Encryption By default, Cloudback generates and manages archive passwords automatically. For organizations that need to manage their own encryption keys, Cloudback also supports **customer-managed encryption** using RSA Lockbox. You provide your own RSA public key, and Cloudback encrypts each backup password with that key. To decrypt backups, you use your private key. For details on setting up customer-managed encryption, see [Encryption Overview](/encryption-management/encryption-overview). ## Learn More * [Encryption Overview](/encryption-management/encryption-overview) * [Customer Managed Storages](/storage-configuration/customer-managed-storages) * [Restoring a Backup](/data-restoration/restoring-a-backup) * [Data Deduplication](/managing-backups/data-deduplication) # Traceability: Audit Log Track activities in your Cloudback account with detailed audit logs, providing security oversight, compliance support, and detailed event records. An audit log, also sometimes called an audit trail, is a digital record that tracks activity within a system. The audit log covers activities such as logins, logouts, backups, restores, account creations and deletions, storage edits, and more. ![Audit Log page](/files/R8x7k1md1zULKJxrO8C3) ## Why is an audit log important? Audit logs are important because they act like a security camera for computer systems, watching over all the actions that happen inside them. They help us: * **Catch Mistakes**: Sometimes, people make mistakes without realizing it. Audit logs let us look back and understand what went wrong, so we can fix it. * **Stop Wrongdoing**: If someone tries to do something they shouldn't, audit logs record their actions. This can stop them from causing harm or help catch them if they do. * **Check Who Did What**: Audit logs keep a clear record of who did something, what they did, and when they did it. This is really helpful for solving disputes or proving what happened. * **Stay Safe**: They help keep systems safe by making sure only the right people can do certain things. If something unusual happens, the logs can alert us. * **Meet Rules**: Many times, laws or rules require that we keep these logs to show we are protecting information properly. ## Accessing the Audit Log Screen ### Permissions required to view the audit log Every Cloudback user can see the audit log. In the audit log, you can find: * Logs of what you have done. * Logs of activities in the organizations you're part of. * Logs of what everyone in your organizations has done. This way, you can easily check actions by you, your team, or your entire organization. ### Locating the audit log within the application The audit log screen can be accessed from the left navigation menu by clicking on **Audit Log**. ## Layout of the Audit Log Screen Below is the list of table columns of the audit log screen: * **Time:** When the action took place. Dates and times are listed in descending order (most recent first). * **Action:** Describes the type of event. * **Description:** Provides more details about the action, including what was backed up, what notifications were sent, and which repositories were affected. * **Account:** Indicates the platform account name associated with the action. * **User:** Specifies the username that executed the action. * **IP:** Shows the IP address from which the action was taken. * **Device:** Describes the device or browser used. * **Location:** Shows the geographic location associated with the IP address. * **CorrelationId:** A unique identifier that links related actions together (e.g., a backup trigger and its completion). * **Error:** This column would display any error messages associated with the action. ## Interpreting Audit Log Entries Below is a list of events you may encounter in the audit log: ### User Events * **Login:** Occurs when a user successfully logs in to the system. * **Logout:** Recorded when a user logs out of the system. * **UserSettingsUpdated:** Recorded when changes are made to a user's settings. * **UserSettingsDeleted:** User settings have been deleted. * **AuditLogExported:** Indicates an export of the audit log has been performed. ### Notification Events * **InstantNotificationSent:** A notification about backup success or failure has been sent. * **EmailNotificationSent:** A notification has been sent via email. ### Storage Events * **StorageCreated:** Recorded when new storage is created. * **StorageUpdated:** Indicates updates made to existing storage. * **StorageDeleted:** Marks the deletion of storage. ### Schedule Events * **ScheduleCreated:** A new backup schedule has been created. * **ScheduleUpdated:** Changes have been made to an existing backup schedule. * **ScheduleDeleted:** A backup schedule has been removed. ### Retention Policy Events * **RetentionPolicyCreated:** A new retention policy for backups has been established. * **RetentionPolicyUpdated:** An existing retention policy has been modified. * **RetentionPolicyDeleted:** A retention policy has been deleted. ### Backup Events * **BackupTriggered:** A backup process has been initiated. * **BackupCompleted:** A backup has completed. It is failed if Error is indicated, otherwise it is succeeded. * **BackupDeleted:** A backup has been removed from storage by retention policy. * **BackupDownloaded:** A backup has been downloaded by a user. ### Restore Events * **RestoreTriggered:** The process to restore data from a backup has started. * **RestoreCompleted:** The restoration of data has been completed. ### Account Events * **AccountCreated:** A new account integration has been created. * **AccountDeleted:** An account integration has been deleted. * **AccountRenamed:** An account has been renamed. * **AccountSettingsUpdated:** Settings for an account have been updated. * **TermsOfServiceAccepted:** User has accepted the Terms of Service. ### GitHub Installation Events * **InstallationCreated:** A new GitHub installation has been set up. * **InstallationSuspended:** A GitHub installation has been temporarily suspended. * **InstallationUnsuspended:** A previously suspended GitHub installation has been reactivated. * **InstallationDeleted:** A GitHub installation has been permanently removed. * **InstallationNewPermissionsAccepted:** New permissions for a GitHub installation have been accepted. ### GitHub Marketplace Events * **PurchaseCreated:** A new purchase or subscription has been made via GitHub Marketplace. * **PurchaseChanged:** An existing purchase or subscription has been altered. * **PurchaseCancelled:** A purchase or subscription has been cancelled. ### Azure Marketplace Events * **SubscriptionActivated:** An Azure Marketplace subscription has been activated. * **SubscriptionChanged:** An Azure Marketplace subscription has been changed. * **SubscriptionSuspended:** An Azure Marketplace subscription has been suspended. * **SubscriptionCancelled:** An Azure Marketplace subscription has been cancelled. ### Repository Events * **RepositoryAdded:** A new repository has been added to the account. * **RepositoryUpdated:** An existing repository has been updated. * **RepositoryPublicized:** A repository has been made public. * **RepositoryPrivatized:** A repository has been made private. * **RepositoryArchived:** A repository has been archived. * **RepositoryUnarchived:** An archived repository has been made active again. * **RepositoryRenamed:** A repository has changed its name. * **RepositoryRemoved:** A repository has been removed from the account. ### Project Events (Azure DevOps, GitLab) * **ProjectAdded:** A new project has been added to the account. * **ProjectUpdated:** An existing project has been updated. * **ProjectRemoved:** A project has been removed from the account. ### Workspace Events (Linear) * **WorkspaceAdded:** A new Linear workspace has been added to the account. * **WorkspaceUpdated:** An existing Linear workspace has been updated. * **WorkspaceRemoved:** A Linear workspace has been removed from the account. ### Vanta Integration Events For details on setting up and managing the Vanta integration, see [Vanta Integration](/security-and-compliance/vanta-integration). * **VantaIntegrationActivated:** Vanta integration has been activated. * **VantaIntegrationDeactivated:** Vanta integration has been deactivated. * **VantaIntegrationUsersSync:** Users have been synced with Vanta. ### API Key Events * **ApiKeyCreated:** A new API key has been created. * **ApiKeyRevoked:** An API key has been revoked. ### Encryption Events These events relate to [customer-managed encryption](/encryption-management/encryption-overview) keys (e.g., RSA Lockbox). * **EncryptionKeyCreated:** A new encryption provider has been created. The log entry includes the provider name, type, and public key fingerprint. * **EncryptionKeyUpdated:** An encryption provider's settings have been changed (e.g., name or public key). The log entry includes the old and new public key fingerprints when the key changes. * **EncryptionKeyDeleted:** An encryption provider has been deleted. * **EncryptionKeyReencrypted:** A [key rotation](/encryption-management/rsa-lockbox#rotating-your-rsa-key) with re-encryption was completed. The log entry includes the provider name and the number of backup passwords that were re-encrypted. * **EncryptionKeyAccessUpdated:** Access permissions for an encryption provider have been changed - this controls which platform accounts can use the provider. ## Exporting Audit Logs To conduct a more detailed analysis, use the "Export to CSV" button to download the log entries. The export function currently supports the CSV format only, suitable for opening and analyzing in Microsoft Excel. Please note that the export is limited to a maximum of 1,048,576 rows; any data beyond this limit will be truncated. To ensure the export encompasses only the most relevant data, it's advisable to refine your search criteria prior to initiating the export process. ## Log Retention Policy The default retention period for audit logs is 180 days. Should you require a longer retention duration, please [reach out to support](/troubleshooting-and-support/contact-us) to establish a customized retention policy. ## Integrating Audit Logs with External Systems For Enterprises who want to integrate audit logs with SIEM systems, Cloudback audit logs can be forwarded to an external system. [Contact the support team](/troubleshooting-and-support/contact-us) for assistance with configuring this integration. They'll be happy to discuss your specific needs and recommend the best approach. # Legal Legal documentation for Cloudback, including Terms of Service and Privacy Policy. Review Cloudback's legal documents and policies. ## Legal Documents * [Terms of Service](/legal/terms-of-service) - Terms governing use of Cloudback services * [Data Processing Agreement](/legal/data-processing-agreement) - GDPR-compliant data processing terms * [Privacy Policy](/legal/privacy-policy) - How we collect and use your data # Terms of Service Comprehensive terms and conditions for using Cloudback services, including account terms, payment policies, service level objectives, and legal responsibilities. ## Introduction The Cloudback Terms of Service are between MYRTLELABS S.A.S. (former MYRTLE GROUP S.A.) (“we” or “Cloudback”) and the customer who orders the Cloudback services (“you” or “Customer”). By using the cloudback.it website or any services described on the cloudback.it website (collectively, “Service”), you are agreeing to be bound by the following terms and conditions (“Terms of Service”). Violation of any of the terms below will result in the termination of your Account. Cloudback prohibits certain conduct on the Service as described below. You understand and agree that Cloudback cannot be responsible for conduct or activity on the Service or for “Content” transmitted, posted, or stored using the Service. You agree to use the Service at your own risk. For the purposes of this agreement “Content” means information, data files, written text, computer software, music, audio files or other sounds, photographs, videos or other images to which you may have access as part of, or through your use of, the Service. ## Account Terms * You must be a human. Accounts registered by “bots” or other automated methods are not permitted. * You must be 16 years or older to use this Service. * You must use a valid GitHub account in order to complete the signup process. * Your login may only be used by one person - a single login shared by multiple people is not permitted. You may create separate logins for as many people as you need. * You are responsible for maintaining the security of your GitHub account and password. Cloudback cannot and will not be liable for any loss or damage from your failure to comply with this security obligation. * You are responsible for all Content posted and activity that occurs under your account (even when Content is posted by others who have accounts under your account). * You may not use the Service for any illegal or unauthorized purpose. You must not, in the use of the Service, violate any laws in your jurisdiction (including but not limited to copyright laws). ## General Conditions Your use of the Service is at your sole risk. The service is provided on an “as is” and “as available” basis. By using Cloudback, your company accepts public disclosure of its integration with Cloudback via Cloudback’s marketing activities. If you want to opt out, please contact our marketing team at . You understand that Cloudback uses third party vendors and hosting partners to provide the necessary hardware, software, networking, storage, and related technology required to run the Service. You must not modify, adapt or hack the Service or modify another website so as to falsely imply that it is associated with the Service, Cloudback, or any other Cloudback service. You agree not to reproduce, duplicate, copy, sell, resell or exploit any portion of the Service, use of the Service, or access to the Service without the express written permission by Cloudback. You may not access the Service for the purpose of bringing an intellectual property infringement claim against Cloudback or for the purpose of creating a product or service competitive with the Cloudback Service. We may, but have no obligation to, remove Content and Accounts containing Content that we determine in our sole discretion are unlawful, destructive, offensive, threatening, libelous, defamatory, pornographic, obscene or otherwise objectionable or violates any party’s intellectual property or these Terms of Service. Verbal, physical, written or other abuse (including threats of abuse or retribution) of any Cloudback customer, employee, member, or officer will result in immediate account termination. Cloudback does not warrant that: * the service will meet your specific requirements, * the service will be uninterrupted, timely, or error-free, * the results that may be obtained from the use of the service will be accurate or reliable, * the quality of any products, services, information, or other material purchased or obtained by you through the service will meet your expectations, * any errors in the Service will be corrected. You expressly understand and agree that Cloudback shall not be liable for any indirect, incidental, special, consequential or exemplary damages, including but not limited to, damages for loss of profits, goodwill, or other intangible losses (even if Cloudback has been advised of the possibility of such damages). If Cloudback, its affiliates, or any of the employees, agents, or suppliers of Cloudback (the “Cloudback Indemnitees”) are faced with a legal claim by a third party arising out of your actual or alleged gross negligence, willful misconduct, violation of law, failure to meet your obligations under the Terms of Service, then you will pay the cost of defending the claim (including reasonable attorney fees) and any damages award, fine, or other amount that is imposed on the Cloudback Indemnitees as a result of the claim. Your obligations under this Section include claims arising out of the acts or omissions of your employees, any other person to whom you have given access to the Services, and any person who gains access to the Services as a result of your failure to meet your security obligations in the Terms of Service, even if the acts or omissions of such persons were not authorized by you. Cloudback will choose legal counsel to defend the claim, provide that these decisions must be reasonable and must be promptly communicated to you. You must comply with our reasonable requests for assistance and cooperation in the defense of the claim. Cloudback may not settle the claim without your consent, although such consent may not be unreasonably withheld. You must pay expenses due under this Section as Cloudback incurs them. Neither of us will be in violation of these Terms of Service if the failure to perform the obligation is due to an event beyond our control, such as significant failure of a part of the power grid, significant failure of the Internet, natural disaster, war, riot, insurrection, epidemic, strikes or other organized labor action, terrorism, or other events of a magnitude or type for which precautions are not generally taken in the industry. You may not assign these Terms of Service without Cloudback’s prior written consent. Cloudback may assign the Terms of Service in whole or in part to an affiliate with sufficient financial standing in order to meet its obligations under the Terms of Service or as part of a corporate reorganization or a sale of its business, and we may transfer your information as part of any such transaction. Cloudback reserves the right to update and change the Terms of Service from time to time. Any new features that augment or enhance the current Service, including the release of new tools and resources, shall be subject to the amended Terms of Service as follows: Amended Terms of Service will become effective the earlier of either your acceptance of the amended Terms of Service, your continued use of the Services after written notice of the amended Terms of Service, or thirty days after the date Cloudback posts such amended Terms of Service on the Cloudback website. In addition, if over time you sign multiple orders for a single account, then the Terms of Service incorporated in the latest order posted on the effective date of the latest order will govern the entire account. The failure of Cloudback to exercise or enforce any right or provision of the Terms of Service shall not constitute a waiver of such right or provision. The Terms of Service constitutes the entire agreement between you and Cloudback and govern your use of the Service, superseding any prior agreements between you and Cloudback (including, but not limited to, any prior versions of the Terms of Service). ## Payment, Refunds, Upgrading and Downgrading Terms Cloudback is not responsible for any errors, delays, or issues arising from third-party payment processors or financial institutions. Users are responsible for ensuring that their payment information is accurate and up-to-date. All payments are processed in USD. Users may be subject to currency conversion fees or other charges imposed by their financial institution. Please check with your bank or credit card provider for details. ### Payment Methods * **GitHub Marketplace.** When purchasing Cloudback via [GitHub Marketplace](https://github.com/marketplace/cloudback), payments are processed by GitHub. By using the Service you agree with [GitHub Marketplace Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-marketplace-terms-of-service). * **Credit Card Payments.** Credit card payments are processed through Paddle.com, a third-party payment processor. By using credit card payment, you agree to Paddle.com’s [Master Services Agreement](https://www.paddle.com/legal/terms). * **Bank Account Payments.** Cloudback accepts payments via direct bank transfer. To arrange payment via bank transfer, users must request the necessary banking details by contacting our support team at . Invoices will be issued for all payments made via bank transfer. Please note that bank transfers may require several business days to process, depending on the financial institutions involved. Any fees or charges imposed by your bank, including those related to currency conversion, are the responsibility of the user. Cloudback is not liable for any delays, errors, or additional costs that may result from the use of this payment method. ### Refunds All payments for Cloudback services are billed in advance, either on a monthly or yearly basis, and are non-refundable. This policy applies to all circumstances, including but not limited to partial months of service, downgrades, or unused services within a billing period. Once a payment is made, no refunds or credits will be provided for any unused time or services during the paid billing period. Upon downgrading your service, the current service level will remain active until the end of the billing period, but no refunds or prorated credits will be issued for the downgrade. In the event that Cloudback is unable to provide the service due to a fault on our part, or where required by applicable law, exceptions to this refund policy may be considered. Any such exceptions will be evaluated on a case-by-case basis and are at the sole discretion of Cloudback. This refund policy is designed to maintain service consistency and predictability. Please ensure that you are fully committed to the chosen service level before completing your purchase. ### Upgrading * **GitHub Marketplace Subscriptions**: If you are using GitHub Marketplace to manage your Cloudback subscription, all service upgrades must be processed directly through the GitHub platform. Once your upgrade is confirmed, the enhanced plan features will be activated immediately. * **Invoiced Subscriptions:** For invoiced subscriptions, upgrades can be requested by contacting our support team at . Upon confirmation of payment, your upgraded plan will take effect immediately, and the new features will be available for use. The billing cycle will be updated to reflect the change, and any remaining balance from your previous plan will be credited toward the new plan. ### Downgrading Downgrading your Service may cause the loss of features or capacity of your Account. Cloudback does not accept any liability for such loss. * **GitHub Marketplace Subscriptions:** If you are using GitHub Marketplace to manage your Cloudback subscription, all service downgrades must be processed directly through the GitHub platform. Once your downgrade is confirmed, the reduced plan features will take effect at the start of the next billing cycle. * **Invoiced Subscriptions:** For invoiced subscriptions, downgrades can be requested by contacting our support team at . All downgrade requests will be implemented at the start of the next billing cycle, allowing you to maintain your current plan's features until the end of the paid period. ## Plan Cancellation You are solely responsible for properly canceling your plan. When you cancel your "Cloudback Backup" GitHub Application installation, your subscription remains active until the end of your current billing cycle. The cancellation takes effect on your next billing date. When you cancel a free trial on a paid plan, your subscription is immediately canceled and you will lose access to the app. If you don't cancel your free trial within the trial period, the payment method on file for your account will be charged for the plan you chose at the end of the trial period. * **GitHub Subscriptions:** You can cancel your plan at any time on the GitHub website. For more details, visit [Canceling a GitHub Marketplace app](https://docs.github.com/en/billing/how-tos/pay-third-parties/cancel-marketplace-app) page in the [Managing Billing for GitHub Marketplace app](https://docs.github.com/en/billing/how-tos/pay-third-parties) guide. * **Invoiced Subscriptions:** For invoiced subscriptions, cancellation requests must be submitted in writing to our support team at . Once your cancellation request is confirmed, your subscription will remain active until the end of your current billing cycle. The cancellation will take effect at the start of the next billing cycle. Please note that you are responsible for any outstanding payments up to the effective cancellation date, and no refunds will be provided for unused portions of your billing period. ## Cloudback Account Termination You are solely responsible for properly terminating your account. An email or phone request to terminate your account is not considered termination. You can terminate your account by clicking on the Settings link in the user menu at the top right corner of the screen, and going into the Settings page. Under Account Settings, there is a ‘Delete my account’ button. Your error details and related account information will be deleted from the Service within 30 days of termination. This information can not be recovered once it is deleted. Be aware that account termination does not cancel your GitHub Marketplace plan. Cloudback, in its sole discretion, has the right to suspend or terminate your account and refuse any and all current or future use of the Service, for any reason at any time. Such termination of the Service will result in the deactivation or deletion of your Account or your access to your Account. Cloudback reserves the right to refuse service to anyone for any reason at any time. ## Modifications to the Service and Prices Cloudback reserves the right at any time and from time to time to modify or discontinue, temporarily or permanently, the Service (or any part thereof) with or without notice. Prices of all Services, including but not limited to monthly subscription plan fees to the Service, are subject to change upon 30 days notice from us. Such notice may be provided at any time by posting the changes to the [Cloudback website](https://cloudback.it/) or the Service itself. Cloudback shall not be liable to you or to any third party for any modification, price change, suspension or discontinuance of the Service. ## Copyright and Content Ownership We claim no intellectual property rights over the material you provide to the Service. Your profile and materials uploaded remain yours. Cloudback does not pre-screen Content, but Cloudback and its designee have the right (but not the obligation) in their sole discretion to refuse or remove any Content that is available via the Service. All rights reserved. You may not duplicate, copy, or reuse any portion of the HTML/CSS, Javascript, or visual design elements or concepts without express written permission from Cloudback. ### Content Removal Cloudback reserves the right to remove Content for the following reasons: 1. **Violation of Terms of Service**: If the content breaches any terms outlined in the agreement, it may be removed. 2. **Illegal Content**: Any content that is illegal will be subject to removal. 3. **Security Threats**: Content that poses a security risk, such as malware, viruses, or content designed to hack or exploit the platform or its users, will be removed to protect the system and user data. #### Data Processing Agreement (DPA) If and to the extent Cloudback processes personal data on your behalf in the course of providing the Services, the terms of the Cloudback Data Processing Agreement (“DPA”) shall apply and are incorporated into these Terms of Service by reference. By agreeing to these Terms of Service and using our Services, you are also agreeing to the terms of the DPA, which governs the rights and obligations of both parties with respect to personal data processing, including security measures, data subject rights, subprocessors, and international data transfers. The DPA outlines how Cloudback complies with the EU General Data Protection Regulation (GDPR) and other applicable data protection laws. You can review the full DPA [here](/legal/data-processing-agreement). For details on how we collect and use personal information, see our [Privacy Policy](/legal/privacy-policy). ## Service Level Objectives ### Backup Frequency We commit to performing backups at least once daily by default, with the flexibility for users to configure custom backup schedules to fit their specific needs. ### Backup Concurrency We commit to supporting up to 4 concurrent in-progress backups per account. ### Restore Time We commit to initiating the restore process within 5 minutes. The total completion time depends on the archive storage provider and the upload rate to the target system. In the worst-case scenario, it may take up to 48 hours to begin the download from deep archive storage. Additionally, the restore process may take up to 7 seconds per individual metadata entry (e.g., 1,000 comments could take approximately 2 hours to restore). ### Restore Concurrency We commit to supporting up to 2 concurrent in-progress restores per account. ### Data Redundancy Cloudback-managed storages are not redundant. Replicate backups using composite customer-managed storage to enhance data redundancy. ### Security and Compliance At MYRTLELABS S.A.S., maintaining the security and integrity of our customer data is paramount. We are committed to providing services that are secure, reliable, and compliant with the highest industry standards, including SOC 2 Type II compliance. **Data Protection:** We employ a variety of security measures including encryption, firewalls, and access controls to protect the confidentiality and integrity of your data. **Compliance:** Our services are designed to comply with SOC 2 Type II requirements. We regularly undergo audits performed by independent third-party organizations to ensure that our security controls are effective and in accordance with current standards. **Communication:** We are committed to keeping our customers informed about any changes to our security policies and practices. Any amendments related to security will be communicated through updates to this Terms of Service (TOS) document. **Transparency:** Detailed information about our security practices and the specific controls we have in place is available upon request. Customers can contact our support team for more information about our compliance certifications and security measures. Cloudback has achieved SOC 2 Type II compliance (October 2024) to provide independent verification of its security practices. By using our services, you acknowledge and agree that it is your responsibility to ensure that your use of our services complies with all applicable laws and regulations, and that the integrity, security, and confidentiality of your data transmitted through our services are appropriately maintained. ### Support We commit to providing an initial response to all support requests within 24 hours. ### Maintenance You acknowledge that Cloudback may be unavailable due to maintenance performed by Cloudback. Cloudback will use reasonable efforts to schedule maintenance during non-peak usage hours. Cloudback’s scheduled maintenance (as well as any unscheduled, emergency maintenance, to the extent Cloudback is able to provide any advance notice) will be notified to you at [Cloudback Status](https://status.cloudback.it) or by email. We will endeavor to limit actual maintenance outages to the minimum necessary to provide a consistent and reliable service to you. ### Service Availability We commit to an annual uptime percentage of 99.5% for our service. This means that our system will be operational and accessible to users for at least 99.5% of the total time in a given year. ## Changes To This Document This Document is effective as of August 7, 2025, and will remain in effect except with respect to any changes in its provisions in the future. We reserve the right to update or change this Document at any time. ## Contact Us If you have any questions or suggestions about the Terms of Service, do not hesitate to contact us at . # Data Processing Agreement For Customers Subject to EU Data Protection Laws This Data Processing Agreement forms part of the Contract for Services between MYRTLELABS SAS, located at La Armenia, Juan Leon Mera y Numa Pompillo, Conjunto Prados de la Armenia N9-960, Quito, Ecuador, company identification number RUC 1793212306001, doing business as **Cloudback** (referred to as the "**Processor**") and the Company using Cloudback’s services (referred to as the "**Company**”). This Agreement governs the specific requirements of Data Protection Laws to the extent that Company’s use of Cloudback Services implies the processing of Personal Data subject to Data Protection Laws. #### WHEREAS (A) The Company acts as a Data Controller (the “**Controller**”). (B) The Company wishes to subcontract certain Services, which imply the processing of personal data, to Cloudback, acting as a Data Processor (the “**Processor**”). (C) The Parties seek to implement a data processing agreement that complies with the requirements of the current legal framework in relation to data processing and with the Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation) and other applicable data protection laws. (D) The Parties wish to lay down their rights and obligations. #### IT IS AGREED AS FOLLOWS: ## 1. Definitions and Interpretation Unless otherwise defined herein, capitalized terms and expressions used in this DPA shall have the following meaning: 1.1) “**Agreement**” means this Data Processing Agreement and all Schedules; 1.2) “**Company Personal Data**” means any Personal Data Processed by a Contracted Processor on behalf of Company pursuant to or in connection with the Service Agreement; 1.3) “**Contracted Processor**” means a Subprocessor; 1.4) “**Data Protection Laws**” means EU Data Protection Laws and, to the extent applicable, the data protection or privacy laws of any other country; 1.5) “**EEA**” means the European Economic Area; 1.6) “**EU Data Protection Laws**” means EU Directive 95/46/EC, as transposed into domestic legislation of each Member State and as amended, replaced or superseded from time to time, including by the GDPR and laws implementing or supplementing the GDPR; 1.7) “**GDPR**” means EU General Data Protection Regulation 2016/679; 1.8) “**Data Transfer**” means: * 1.8.1) a transfer of Company Personal Data from the Company to a Contracted Processor; or * 1.8.2) an onward transfer of Company Personal Data from a Contracted Processor to a Subcontracted Processor, or between two establishments of a Contracted Processor, in each case, where such transfer would be prohibited by Data Protection Laws (or by the terms of data transfer agreements put in place to address the data transfer restrictions of Data Protection Laws); 1.9) “**Services**” means the online services provided by the Processor, such as automated GIT repository backups and other services as developed by the Processor. 1.10) “**Subprocessor**” means any person appointed by or on behalf of Processor to process Personal Data on behalf of the Company in connection with the Agreement. The terms, “**Commission**”, “**Controller**”, “**Data Subject**”, “**Member State**”, “**Personal Data**”, “**Personal Data Breach**”, “**Processing**”, and “**Supervisory Authority**” shall have the same meaning as in the GDPR, and their cognate terms shall be construed accordingly. ## 2. Processing of Company Personal Data #### Processor shall: 2.1) comply with all applicable Data Protection Laws in the Processing of Company Personal Data; 2.2) and not Process Company Personal Data other than on the relevant Company’s documented instructions. #### The Company instructs Processor to process Company Personal Data to: 2.3) provide the Services and related technical support; 2.4) fulfil legal obligations or resolve disputes; 2.5) exercise any internal task aimed to optimise the security, privacy, confidentiality, and functionalities of the Services; 2.6) exercise internal reporting, financial reporting, and other similar internal tasks. ## 3. Processor Personnel Processor shall take reasonable steps to ensure the reliability of any employee, agent or contractor of any Contracted Processor who may have access to the Company Personal Data, ensuring in each case that access is strictly limited to those individuals who need to know / access the relevant Company Personal Data, as strictly necessary for the purposes of the Service Agreement, and to comply with Applicable Laws in the context of that individual’s duties to the Contracted Processor, ensuring that all such individuals are subject to confidentiality undertakings or professional or statutory obligations of confidentiality. ## 4. Security In accordance with Article 32 (1) of the GDPR, the Processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing. These measures shall be designed to protect the rights and freedoms of natural persons, considering the risks of varying likelihood and severity, including the risk of a Personal Data Breach. The Processor shall also assess the risks associated with processing activities and apply measures that are consistent with the requirements set forth in Article 32 (1) GDPR, ensuring the security of Company Personal Data at all times. ## 5. Subprocessing Subject to this Agreement, the Company grants general authorization to the Processor to engage Subprocessors and disclose or transfer Company Personal Data to them. The Company acknowledges and approves the list of Subprocessors outlined in the Processor’s [Privacy Policy](/legal/privacy-policy), understanding that this list may be updated by the Processor regularly, in which case the company shall be informed by the Processor according to the Privacy Policy notification process. Furthermore, the Company authorizes the Processor to disclose and transfer Personal Data to any company within its corporate group. Processor ensures that Subprocessors are subject to an agreement with Processor no less restrictive and protective than the present Agreement with respect to the protection of Company Personal Data to the extent applicable to the nature of the services provided by the Subprocessor. ## 6. Data Subject Rights Taking into account the nature of the processing, Processor shall reasonably assist Company for the fulfilment of Company’s obligations to respond to requests to exercise Data Subject rights under the Data Protection Laws. #### Processor shall: 6.1) promptly notify Company if it receives a request from a Data Subject under any Data Protection Law in respect of Company Personal Data; and 6.2) ensure that it does not respond to that request except on the documented instructions of Controller or as required by Applicable Laws to which the Processor is subject, in which case Processor shall, to the extent permitted by Applicable Laws, inform Controller of that legal requirement before the Contracted Processor responds to the request. ## 7. Personal Data Breach The Processor shall manage any Personal Data Breach in compliance with applicable Data Protection Laws and its internal Personal Data Breach procedures. In the event of a Personal Data Breach affecting company's Personal Data, the Processor shall notify the Company without delay, providing sufficient information to enable the Company to fulfill its obligations under Data Protection Laws, including informing Data Subjects as necessary. In such cases, Processor shall provide Company with sufficient information to allow Company to meet any obligations to report or inform Data Subjects of the Personal Data Breach under the Data Protection Laws. Processor shall co-operate with Company and take reasonable commercial steps as are directed by Company to assist in the investigation, mitigation, and remediation of each such Personal Data Breach. Each party shall bear the costs of the investigation, remediation, mitigation, and other related costs to the extent a Data Breach is caused by such party. Each party shall bear the costs of any fines, penalties, damages, or other related amounts imposed by an authorized regulatory body, governmental agency, or court of competent jurisdiction to the extent arising from such party’s breach of its obligations under this Agreement. ## 8. Data Protection Impact Assessment and Prior Consultation Processor shall provide reasonable assistance to the Company with any data protection impact assessments, and prior consultations with Supervising Authorities or other competent data privacy authorities, which Company reasonably considers to be required by article 35 or 36 of the GDPR or equivalent provisions of any other Data Protection Law, in each case solely in relation to Processing of Company Personal Data by, and taking into account the nature of the Processing and information available to, the Contracted Processors. ## 9. Deletion or return of Company Personal Data Subject to this section 9, Processor shall promptly and in any event within ninety (90) days of the date of cessation of any Services involving the Processing of Company Personal Data (the "Cessation Date"), delete and procure the deletion of all copies of Company Personal Data. Processor shall comply with any applicable Data Protection Law requirements relating to the deletion of Personal Data. ## 10. Audit rights Subject to this section 10, Processor shall make available to Company on request all information necessary to demonstrate compliance with this Agreement, and shall allow for and contribute to audits, including inspections, by Company or an auditor mandated by Company in relation to the Processing of the Company Personal Data by the Contracted Processors. Company shall not exercise its audit rights more than once per calendar year except following a Personal Data Breach or an instruction by a regulatory authority. Company shall give Processor at least sixty (60) days prior written notice of its intention to audit Processor pursuant to this Agreement. Audit shall be conducted during Processor’s business hours, shall not disrupt Processor’s operations and shall ensure the protection of the Company’s, Processor’s and other Data Subjects’ Personal Data. Processor and Company shall mutually agree in advance on the date, scope, duration and security and confidentiality controls applicable to the audit. Company acknowledges that the signing of a non-disclosure agreement may be required by the Processor prior to the conduction of the audit. Information and audit rights of Company only arise under section 10 to the extent that the Agreement does not otherwise give them information and audit rights meeting the relevant requirements of Data Protection Law. ## 11. Data Transfer To the extent possible, the Processor shall only transfer or authorize the transfer of Data to countries within the EU and/or countries subject to an adequacy decision, as provided for in art. 45 GDPR. If Personal Data processed under this Agreement is transferred from any country within the EU or any country subject to an adequacy decision to a country outside of this scope, the Parties shall ensure that the Personal Data are adequately protected. To achieve this, the Parties shall, unless agreed otherwise, rely on EU-approved and then-current standard contractual clauses for the transfer of Personal Data or other transfer mechanisms as provided for by Data Protection Laws. Processor shall be authorized to perform such transfers to Subprocessors provided that adequate safeguards are implemented with regards to the nature of the transfer. ## 12. General Terms **Compliance with Applicable Laws.** Processor will process Company Personal Data in accordance with this Agreement and Data Protection Laws applicable to its role under this Agreement. Processor is not responsible nor liable for complying with Data Protection Laws solely applicable to Company by virtue of its business or industry. **Confidentiality.** Each party must keep any information it receives about the other party and its business in connection with this Agreement (“**Confidential Information**”) confidential and must not use or disclose that Confidential Information without the prior written consent of the other party except to the extent that: (a) disclosure is required by law; (b) the relevant information is already in the public domain through no fault of the Parties. **Notices.** All notices and communications given under this Agreement must be in writing and will be sent by email. Controller shall be notified by email sent to the address related to its use of the Services under the Principal Agreement. Processor shall be notified by email sent to the address: . **Governing Law and Jurisdiction.** This Agreement shall be governed by Ecuador law, without regard to the choice or conflicts of law provisions of any jurisdiction to the contrary, and disputed, actions, claims or causes of action arising out of or in connection with this Agreement, an order form, any document incorporated by reference, or the Services shall be subject to the exclusive jurisdiction of Quito, Ecuador. # Privacy Policy Cloudback Privacy Policy detailing how user data is collected, used, and protected in compliance with GDPR and other data protection regulations. ## Introduction We, the MYRTLELABS S.A.S. (former MYRTLE GROUP S.A.), have built the Cloudback application as a Commercial service. This service is provided by us and is intended for use as is. We fully comply with the European General Data Protection Regulation (GDPR) laws, requirements, and regulations. This Policy is used to inform visitors and users regarding our policies about the collection, use, and disclosure of Personal Information of anyone using the Service. By using the Service, you agree to the collection and use of information mentioned in this policy. The Personal Information that we collect is used for providing and improving the Service. We respect the privacy of our users and will not use or share the information with anyone except as described in this Privacy Policy. The terms used in this Privacy Policy have the same meanings as in our Terms of Service, which can be accessed [here](/legal/terms-of-service), unless otherwise defined in this Privacy Policy. This policy only applies to our site. If you leave the site via a link or otherwise, you will be subject to the policy of that website provider. We have no control over that policy or the terms of the website, and you should check their policy before continuing to access the site. ## Information Collection and Use For a better experience, while using our Service, we may require you to provide us with certain personally identifiable information, including but not limited to email and location. The information that we request will be retained by us and used as described in this privacy policy. We may collect and process the following data about you: * Information provided at the time of signing up for our service or requesting further services: * Your account name * Your email address * Your IP address * Your browser agent name * Information that you provide by filling in forms on our site ([cloudback.it](https://cloudback.it/)). We may also ask you for information when you report a problem with our site or send any feedback information. * If you contact us, we may keep a record of that correspondence. * We may also ask you to complete some surveys that we use for research purposes, although you do not have to respond to them. * Details of your visits to our site, including, but not limited to, traffic data, location data, weblogs, operating system, browser usage, and other communication data. ## Links to Other Sites This Service may contain links to other sites. If you click on a third-party link, you will be directed to that site. Note that these external sites are not operated by us. Therefore, we strongly advise you to review the Privacy Policy of these websites. We have no control over and assume no responsibility for the content, privacy policies, or practices of any third-party sites or services. ## External Services To deliver our services effectively, we engage with external third-party providers. These parties may process personal data either on our behalf (as **subprocessors**) or independently (as **independent data controllers**) in accordance with their own privacy policies. **Subprocessors** These service providers process data strictly on our behalf and under our instructions, as part of our service delivery: * **Twilio Inc.** (USA) - Provides email automation services (SendGrid). [Privacy Policy](https://www.twilio.com/legal/privacy) * **Microsoft Corporation** (USA) - Cloud infrastructure provider. [Privacy Statement](https://privacy.microsoft.com/) * **Zoho Corporation** (USA) - Used for invoicing and collecting electronic signatures. [Privacy Policy](https://www.zoho.com/privacy.html) * **ChartMogul GmbH & Co. KG** (Germany) - CRM and subscription analytics. [Privacy Policy](https://chartmogul.com/privacy/) **Independent Processors** These providers process personal data for their own purposes and determine the means and purposes of processing. When you interact with these services (e.g. for payments or scheduling), their respective privacy policies apply: * **Google LLC (Google Ads)** (USA) - Used for web analytics. [Privacy & Terms](https://policies.google.com/privacy) * **Paddle.com Market Ltd.** (United Kingdom) - Payment processor for credit card transactions. [Privacy Policy](https://www.paddle.com/legal/privacy) * **Calendly LLC** (USA) - Used for meeting scheduling. [Privacy Policy](https://calendly.com/privacy) ## Cookies Cookies are files with a small amount of data that are commonly used as anonymous unique identifiers. These are sent to your browser from the websites that you visit and are stored on your device’s internal memory. We may obtain information about your general internet usage by using a cookie file, which is stored on your computer. Cookies contain information that is transferred to your computer’s hard drive. They help us to improve our site and to deliver a better and more personalized service. They enable us: * To estimate our audience size and usage pattern. * To store information about your preferences, and so allow us to customize our site according to your individual interests. * To speed up your searches. * To recognize you when you return to our site. You may refuse to accept cookies by activating the setting on your browser which allows you to refuse the setting of cookies. However, if you select this setting, you may be unable to access certain parts of our site. Unless you have adjusted your browser setting so that it will refuse cookies, our website will issue cookies when you log on to our site. ## For Data Subjects in the EU We value your data subject rights under GDPR and therefore appointed Prighter.com as representative according to Art 27 GDPR and provide you with an easy way to submit a privacy-related request, such as a request to access or erase your personal data. If you want to make use of your data subject rights, please visit: **Contact Prighter.com** Prighter.com\ Maetzler Rechtsanwalts GmbH & Co KG\ Attorneys at Law\ c/o MYRTLELABS S.A.S.\ Schellinggasse 3/10, 1010 Vienna, Austria Please add the following subject to all correspondence: GDPR-REP ID: 15719145 **Information according to Art 27 EU GDPR** MYRTLELABS S.A.S. is a company located outside the European Union. In order to comply with Art 27 EU GDPR, Prighter.com has been nominated as our representative in the European Union. If you want to make use of your data privacy rights, please visit our [Compliance Landing Page](https://prighter.com/q/15719145).
GDPR Representation Certificate
## Controller Name and Address Controller for the purposes of the General Data Protection Regulation (GDPR), other data protection laws applicable in Member states of the European Union, and other provisions related to data protection is: Address:\ Ecuador, Quito\ La Armenia, Juan Leon Mera y Numa Pompillo\ Conjunto Prados de la Armenia N9-960\ RUC 1793212306001\ Postal code 170803\ Email: \ Website: cloudback.it ## Changes To This Document This document is effective as of August 7, 2025, and will remain in effect except with respect to any changes in its provisions in the future. We reserve the right to update or change this document at any time. ## Contact Us If you have any questions or suggestions about our Privacy Policy, do not hesitate to contact us at .