Object Storage Backup: A Step-by-Step Guide to Secure Data

Object storage backup is the process of copying files, application data, databases, or server backups to an object storage service for long-term protection and recovery. It helps protect data against hardware failures, accidental deletion, ransomware, and other events that can disrupt a server. With the right backup software, you can encrypt your data, automate uploads, retain multiple recovery points, and restore files when needed.

This guide explains how object storage backup works, how to configure it on a Linux server, and how to automate and test backups using Restic and an S3-compatible storage service.

What Is Object Storage Backup?

Object storage backup stores copies of data as objects in a storage system rather than keeping them only on a local disk or traditional file system. Each object typically contains the data, metadata, and an identifier used to retrieve it.

Object storage services are commonly used for website backups, database exports, application files, media libraries, logs, and disaster recovery archives.

A typical backup workflow looks like this:

1. Select the files or data that need protection.
2. Prepare a backup using a suitable backup tool.
3. Encrypt the backup before transferring it, when supported.
4. Upload the backup to a remote object storage repository or bucket.
5. Apply retention rules and monitor backup results.
6. Restore the data when the original files are lost or damaged.

Object storage is useful because it separates backup copies from the server that generates them. If the server fails, a backup stored in a separate account or location can remain available for recovery.

How Does Object Storage Backup Work?

Object storage backup usually involves a source system, backup software, a storage endpoint, and a recovery process.

For example, a website hosted on a Linux VPS may store its application files and database locally. A backup tool can create a recoverable snapshot and transfer the data to an S3-compatible object storage service.

If the VPS becomes unavailable, you can provision a replacement server and restore the backup.

However, uploading files alone does not guarantee that an application can be recovered. Databases may need consistent exports, application configuration may need separate protection, and the recovery process must be tested.

Object Storage Backup vs. Traditional Backup

Object storage is a storage destination, while traditional backup can describe several approaches, including local disks, external drives, and dedicated backup servers. The most useful comparison is between storing backup copies in object storage and keeping them on the same server or local network.

For important systems, these methods can complement each other. A local backup can support fast recovery, while a remote object storage copy provides additional protection against a local disaster.

What Data Should You Back Up to Object Storage?

Before configuring a backup, identify the data needed to rebuild the service.

Website Files

Website backups may include application code, themes, plugins, uploaded media, configuration files, and other required assets. For a WordPress site, the database is also essential because it contains posts, settings, user information, and other application data.

Databases

Databases require special care because copying their underlying files while they are changing may produce an inconsistent backup.

Use a database-aware backup tool or a consistent database export process. For example, a MySQL or MariaDB application may use a logical database dump that can be stored alongside the website files.

Server Configuration

Protect the configuration needed to rebuild the service, such as web server settings, deployment files, scheduled task definitions, and relevant system configuration.

Do not automatically copy every system file. Identify which files are necessary for recovery and avoid including temporary data, caches, or secrets that do not belong in the backup.

Application and Business Data

Applications may store uploaded documents, reports, user-generated content, and other business records. Identify where this data resides before setting a backup policy.

Credentials and Encryption Keys

Recovery may depend on credentials, encryption keys, or backup repository passwords. Protect these separately using a secure password manager or secrets-management system. A backup that cannot be decrypted is not a usable recovery copy.

How to Set Up Object Storage Backup on Linux

This tutorial uses Restic, an open-source backup tool that supports encrypted backups and S3-compatible storage. The same general workflow applies to many object storage providers, although their endpoint formats, authentication methods, and storage policies differ.

You will need:

• A Linux server containing the files you want to back up.
• An object storage account and a bucket created through your provider.
• An access key with the minimum permissions required for the backup.
• Restic installed on the server.
• A strong repository password stored securely outside the server.

The commands below are examples. Replace the placeholder endpoint, bucket name, and file paths with values from your own environment.

Step 1: Install Restic

Install Restic using your Linux distribution’s supported package manager or the official installation instructions.

For Debian or Ubuntu, you can try:

sudo apt update
sudo apt install restic

sudo apt update
sudo apt install restic

Check the installation:

restic version

restic version

If your distribution does not provide a suitable version, consult the official Restic documentation.

Step 2: Create an Object Storage Bucket

Sign in to your chosen storage provider and create a bucket for backups.

Choose a name that identifies its purpose without revealing sensitive information. For example, a bucket might be dedicated to production server backups.

Before proceeding, check the following settings:

• The bucket belongs to the intended account and region.
• Access is private by default.
• The backup identity has only the permissions it needs.
• Versioning or deletion protection is configured where supported and appropriate.
• Lifecycle rules match your retention requirements.
• The provider’s endpoint and region are recorded correctly.

Do not make a backup bucket public to simplify uploads. Backup data may contain personal information, application files, or confidential business records.

Step 3: Configure Access Credentials

Restic can connect to Amazon S3 and other compatible storage services using the appropriate endpoint and credentials.

For an S3-compatible service, the repository URL generally follows this format:

s3:https://STORAGE_ENDPOINT/BUCKET_NAME

s3:https://STORAGE_ENDPOINT/BUCKET_NAME

Replace STORAGE_ENDPOINT and BUCKET_NAME with the values supplied by your provider.

Set the repository and credentials in your current shell:

export RESTIC_REPOSITORY="s3:https://STORAGE_ENDPOINT/BUCKET_NAME"
export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"

export RESTIC_REPOSITORY="s3:https://STORAGE_ENDPOINT/BUCKET_NAME"
export AWS_ACCESS_KEY_ID="YOUR_ACCESS_KEY"
export AWS_SECRET_ACCESS_KEY="YOUR_SECRET_KEY"

These are placeholders, not working credentials. Some providers also require a region setting or a provider-specific endpoint configuration.

Avoid putting real secrets directly into scripts, source control, or commands that may be saved in shell history. For a production setup, use a protected environment file, a secrets manager, or a suitable machine identity supported by the provider. Restrict access to any file containing credentials.

Step 4: Set a Strong Repository Password

Restic encrypts backup data using a repository password. Set a strong password and store it securely.

For a temporary test, you can enter it interactively when prompted. For unattended backups, configure a protected password file or secrets-management mechanism.

If using a password file, set the environment variable to its location:

export RESTIC_PASSWORD_FILE="/secure/path/restic-password"

export RESTIC_PASSWORD_FILE="/secure/path/restic-password"

Restrict the file’s permissions so only the backup service account or authorized administrator can read it.

The password is essential for recovery. If you lose it and have no other valid repository key, you may be unable to decrypt the backup data.

Step 5: Initialize the Backup Repository

Once the storage endpoint, credentials, and repository password are configured, initialize the repository:

restic init

restic init

Run this only when creating a new Restic repository. If the repository already exists, initializing it again is unnecessary and will generally return an error.

Restic prepares the repository structure needed to store snapshots and backup metadata.

Step 6: Run Your First Backup

Choose a directory that contains the data you need to protect.

For example, to back up a website directory:

restic backup /var/www/example.com

restic backup /var/www/example.com

Replace /var/www/example.com with your actual source path.

Restic creates a snapshot of the selected files and stores the backup data in the configured repository. Later backups can reuse unchanged data, reducing repeated uploads.

If the backup includes a live database, create a consistent database export or use a database-aware backup method before backing it up. Do not assume that copying an active database directory will produce a reliable restore point.

Step 7: Verify the Backup

List available snapshots:

restic snapshots

restic snapshots

The output should show the snapshot created by the backup command.

You can inspect the files recorded in a snapshot with:

restic ls latest

restic ls latest

To perform a repository integrity check:

restic check

restic check

A repository check helps identify certain structural or data-integrity issues, but it does not replace a complete test restore. Recovery testing is necessary to verify that the files you need can actually be retrieved and used.

How to Restore Data from Object Storage

A backup is only valuable if you can recover the data when needed.

Step 1: Prepare a Restore Location

Choose an empty directory for the restored files. Do not restore over a live production directory until you have confirmed the correct snapshot and understand the consequences.

For example:

sudo mkdir -p /restore/test
sudo chown "$USER":"$(id -gn)" /restore/test

sudo mkdir -p /restore/test
sudo chown "$USER":"$(id -gn)" /restore/test

Step 2: Restore the Latest Snapshot

Run:

restic restore latest --target /restore/test

restic restore latest --target /restore/test

Restic downloads the required data and reconstructs the files under the specified destination. Depending on the snapshot paths, the restored files may appear beneath additional directory levels.

Inspect the resulting files and verify their contents.

Step 3: Verify the Restored Application

For a website, check that the expected files and configuration exist. For a database, restore the export into a test database and confirm that the data can be queried. For an application, test its dependencies and configuration before returning it to production.

A successful download is not the same as a successful application recovery.

Step 4: Document the Recovery Process

Record the commands, required permissions, repository location, password recovery procedure, and dependencies needed to restore the service.

Keep this information somewhere accessible if the original server is unavailable. Do not store the only copy of the recovery instructions on the machine being backed up.

How to Automate Object Storage Backups

Manual backups are useful for testing, but important servers need a repeatable schedule.

On Linux, cron can run a backup script at a set time. A production setup should also log the result, alert an administrator when a backup fails, and apply a defined retention policy.

Step 1: Create a Backup Script

Create a script such as /usr/local/sbin/object-storage-backup.sh:

#!/usr/bin/env bash
set -Eeuo pipefail

# Load protected configuration.
source /etc/restic/backup.env

# Create a backup snapshot.
restic backup /var/www/example.com

# Verify repository structure and data integrity.
restic check

#!/usr/bin/env bash
set -Eeuo pipefail

# Load protected configuration.
source /etc/restic/backup.env

# Create a backup snapshot.
restic backup /var/www/example.com

# Verify repository structure and data integrity.
restic check

Replace the example path with the directory you intend to back up. The protected configuration file should define the repository, credentials, and password-file location.

The example runs an integrity check after every backup. For large repositories, you may prefer to schedule repository checks separately according to your performance and recovery requirements.

Secure the script and configuration file. The configuration must not be readable by unauthorized users if it contains credentials.

Make the script executable:

sudo chmod 750 /usr/local/sbin/object-storage-backup.sh

sudo chmod 750 /usr/local/sbin/object-storage-backup.sh

Ensure that the account running the script can read the source files and protected configuration, access the object storage endpoint, and write its logs.

Step 2: Schedule the Backup

Open the appropriate user’s crontab:

crontab -e

crontab -e

For a daily backup at 2:00 AM, add:

0 2 * * * /usr/local/sbin/object-storage-backup.sh >> /var/log/object-storage-backup.log 2>&1

0 2 * * * /usr/local/sbin/object-storage-backup.sh >> /var/log/object-storage-backup.log 2>&1

Cron uses the server’s configured time zone. Check the server clock and time zone so the backup runs when expected.

For production environments, configure monitoring or alerts for failed jobs. A log file alone may not be noticed when a backup stops working.

Step 3: Define a Retention Policy

Keeping every snapshot indefinitely can increase storage costs. A retention policy specifies which recovery points should remain available.

For example, a policy that retains recent daily, weekly, and monthly snapshots can be applied with Restic:

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6

Review the snapshots that would be removed before applying a retention policy in a production repository. You can use Restic’s dry-run options to preview the changes.

When you are ready to remove old snapshots and prune data that is no longer referenced, run the appropriate forget and prune operation:

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

restic forget \
  --keep-daily 7 \
  --keep-weekly 4 \
  --keep-monthly 6 \
  --prune

The example is illustrative. Adjust the policy to match your recovery objectives, compliance requirements, and storage budget. Retention rules should not remove every usable recovery point during a long outage or security incident.

Object Storage Backup Best Practices

A reliable backup strategy needs more than an upload command. Use these practices to protect data and improve recovery.

Encrypt Backups

Encrypt backup data before it leaves the source server whenever the backup tool supports client-side encryption. Protect encryption keys and repository passwords separately from the backup data.

Transport encryption, such as HTTPS, protects data in transit. Client-side encryption provides an additional layer of protection for stored backup contents.

Enable Versioning or Deletion Protection

Where supported, object versioning can preserve earlier object versions after an object is overwritten or deleted. Some providers also offer soft delete, retention policies, or immutable storage.

These features are not identical, and their protection depends on the provider’s configuration. Versioning alone may not protect against every type of bucket deletion or account compromise.

Use Separate Credentials

Create a dedicated backup identity instead of using the main administrator account. Grant only the permissions required for the backup and recovery workflows.

Where possible, separate backup creation permissions from deletion and retention-management permissions. Restrict access to the storage account and review credentials periodically.

Keep an Independent Recovery Copy

Consider maintaining another backup copy in a separate account, region, or provider for critical data. This helps reduce the impact of a single account compromise or storage failure.

Follow an appropriate backup strategy, such as keeping multiple copies across independent locations and ensuring at least one copy is isolated from routine administration.

Monitor Backup Results

Monitor successful runs, failures, backup age, storage growth, and available capacity. A scheduled job that silently fails can leave a server without a recent recovery point.

Configure alerts that reach someone who can investigate the failure. Periodically confirm that backups are recent enough to meet your recovery objectives.

Test Restores Regularly

Perform test restores to a separate location. Check files, database contents, permissions, and application functionality.

A backup test should confirm that you can access the repository, decrypt the data, restore the required files, and follow the recovery procedure without depending on the original server.

Manage Storage Costs

Object storage costs can include stored data, API requests, data retrieval, and transfer charges. Versioning and long retention periods may increase the amount of stored data.

Use retention rules that match business needs, exclude unnecessary temporary files, and review storage usage over time. Do not delete recovery points simply to reduce costs without evaluating the risk.

Common Object Storage Backup Problems

When troubleshooting, inspect the backup tool’s output first. Then check credentials, connectivity, source file permissions, storage capacity, and the repository configuration.

Avoid fixing an access problem by making the bucket public or granting broad administrator permissions. Resolve the specific permission or configuration issue instead.

Frequently Asked Questions

Conclusion

Object storage backup provides a practical way to keep server and application data separate from the systems that generate it. With a tool such as Restic, you can configure an encrypted repository, upload snapshots to an S3-compatible service, automate backups, and restore data when required.

For a dependable setup, use least-privilege credentials, protect encryption keys, define retention rules, monitor every scheduled run, and test recovery regularly. The goal is not simply to upload data, but to ensure that a usable copy remains available when you need it most.