Alibaba Cloud Backup Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Storage

1. Introduction

Alibaba Cloud Cloud Backup is a managed data protection service that helps you back up and restore data from cloud and hybrid environments to reduce the risk of data loss and shorten recovery time.

In simple terms: you tell Cloud Backup what to protect (servers, file systems, objects, or supported cloud resources), when to back it up (schedule and retention), and where to store backups (a backup vault in a region). Then Cloud Backup handles the backup jobs, retention, and restore workflows.

Technically, Cloud Backup provides a control plane (console and APIs) to define backup plans and a data plane that transfers backup data into backup vaults. Depending on what you protect, Cloud Backup uses an agent/client (for file-level backup of servers) or integrates with Alibaba Cloud resource capabilities (for example, snapshot-based approaches for some resources). Backups are stored in Cloud Backup-managed storage (vaults), and restore operations read from vaults back to the original or alternate targets.

Cloud Backup solves common problems such as accidental deletion, ransomware recovery, misconfiguration rollback, compliance retention, and “I can’t rebuild this fast enough” operational risks—without requiring you to build and maintain your own backup infrastructure.

Naming note (verify in official docs): Alibaba Cloud previously marketed this capability as Hybrid Backup Recovery (HBR). In current Alibaba Cloud documentation and console, the primary service name is Cloud Backup. If you still see “HBR” in APIs, agents, documentation paths, or logs, treat it as a legacy name/abbreviation for Cloud Backup.

2. What is Cloud Backup?

Official purpose: Cloud Backup is designed to provide centralized backup and restore for Alibaba Cloud and hybrid workloads with policy-based scheduling, retention management, and operational visibility.

Core capabilities (high level)

Backup vaults to store protected backup data in a chosen region.
Backup plans/policies to automate schedules, retention, and backup windows.
Clients/agents (for supported server/file backups) that perform incremental backups and restore.
Restore workflows to recover files/directories (and, for certain protected resources, restore to original or alternate locations depending on resource type).
Monitoring and job history to track backup success/failure, throughput, and audit operations.

Supported workload types vary by region and product updates. Always verify the current “Supported data sources” list in official documentation before designing production coverage.

Major components

Component	What it is	Why it matters
Cloud Backup console & API	Management plane for plans, vaults, jobs, restore	Centralized operations and automation
Backup vault	Logical storage container for backup data in a region	Where backups live; drives cost and retention strategy
Backup client/agent (for server/file backup)	Software installed on protected hosts	Enables file-level protection and restore
Backup plan	Schedule + retention + source selection	Turns backup into an automated, repeatable control
Restore task	Point-in-time recovery workflow	Your “get data back” mechanism when incidents happen

Service type

Managed backup service in the Storage category (data protection).
Typically region-scoped: backup vaults are created in a specific region, and most backup/restore operations are anchored to that region. Cross-region patterns may exist (for example, replication or secondary vaults), but you must verify in official docs because availability can vary.

How it fits into the Alibaba Cloud ecosystem

Cloud Backup commonly works alongside:

ECS (Elastic Compute Service) as the server compute platform to protect.
VPC and security groups for network reachability between hosts and Cloud Backup endpoints.
RAM (Resource Access Management) for permissions and service roles.
KMS (Key Management Service) for encryption key management (where supported/configured).
ActionTrail for auditing API activity.
CloudMonitor for operational monitoring (metrics/alerts) — verify exact metric availability per region.

Cloud Backup is not a replacement for high availability. It is a recovery layer that complements HA designs (multi-zone deployments, replication, snapshots, and application-level resiliency).

3. Why use Cloud Backup?

Business reasons

Reduce outage cost: faster recovery means less downtime and fewer revenue impacts.
Lower operational overhead compared to self-managed backup servers, storage sizing, patching, and scheduling scripts.
Meet retention and audit requirements through policy-driven backup and job history.

Technical reasons

Policy-based automation: consistent backups across many resources.
Point-in-time restore: recover from accidental deletion, corruption, or ransomware.
Central visibility: job status, failures, and restore points in one place.

Operational reasons

Standardize backup operations across teams and accounts (where supported).
Reduce human error by replacing ad-hoc scripts with managed plans.
Faster onboarding: new hosts can be brought under protection with defined policies.

Security/compliance reasons

Encryption support (in transit and at rest depending on configuration).
Access control through RAM policies and separation of duties.
Auditability via ActionTrail logs and job records.
Helps support common control objectives (backup retention, recoverability testing, least privilege).

Scalability/performance reasons

Designed to scale across many protected items without you managing backup servers.
Incremental backup behavior and bandwidth controls (where available) can reduce impact on production workloads.

When teams should choose Cloud Backup

You need centralized, policy-based backup/restore for Alibaba Cloud workloads.
You want managed backup storage (vaults) without building object storage layouts yourself.
You want a guided operational experience: job monitoring, retention policies, restore points.

When teams should not choose it

You need application-consistent backups with specialized enterprise backup tooling features not available in Cloud Backup (verify feature parity in docs).
You already have a standardized enterprise backup platform (Veeam/Commvault, etc.) and Cloud Backup doesn’t integrate in your required way.
Your RPO/RTO requirements require continuous replication or near-zero RPO. Cloud Backup is typically scheduled protection, not continuous replication.

4. Where is Cloud Backup used?

Industries

Finance and fintech (retention, auditability, recovery drills)
Healthcare (data protection, retention policies)
E-commerce (ransomware recovery, rapid restore of critical configs)
SaaS providers (tenant data recovery, infrastructure-as-code state recovery)
Manufacturing and IoT (edge/hybrid server backups — verify supported hybrid agents)

Team types

Platform/infra teams standardizing backup across ECS fleets
SRE/operations teams managing incident response and recovery
Security teams enforcing backup immutability patterns (where supported) and recovery readiness
DevOps teams integrating backups into CI/CD and change-management workflows

Workloads

Linux/Windows servers (file-level protection via agent/client)
Shared file storage and object storage protection patterns (verify supported sources)
Configuration and state protection (configs, scripts, infrastructure artifacts)
Hybrid hosts that need centralized backup governance

Architectures and deployment contexts

Single-region production with periodic backups to a vault
Multi-environment (dev/test/prod) with different retention and frequency
Multi-account organizations needing standardized policies (verify multi-account options)
Hybrid deployments with on-prem servers connecting to Alibaba Cloud

Production vs dev/test usage

Production: focus on RPO/RTO, retention, encryption, access control, restore testing, and monitoring.
Dev/Test: lower retention, less frequent backups, cost controls; still validate restore processes (restore is the real product).

5. Top Use Cases and Scenarios

Below are realistic Cloud Backup use cases. Each includes the problem, why Cloud Backup fits, and a short scenario.

1) ECS configuration and application file backup (file-level)

Problem: Critical config files and application artifacts change frequently and can be deleted or corrupted.
Why Cloud Backup fits: Agent-based backups can protect directories with scheduled incremental backups and retention.
Scenario: Back up /etc, /opt/app/config, and /var/www nightly with 30-day retention, and restore a single config file after an accidental overwrite.

2) Ransomware recovery for small servers

Problem: Ransomware encrypts server files; you need clean restore points.
Why this service fits: Centralized restore points and controlled restore workflows; can support isolated recovery processes (design-dependent).
Scenario: Restore /home and /srv/data from the last known-good backup vault recovery point after a compromise.

3) Compliance retention for operational logs (file backup)

Problem: You must retain operational/security logs for months.
Why this service fits: Policy-based retention and centralized storage in a managed vault.
Scenario: Back up /var/log weekly with 180-day retention; maintain job history for audits.

4) Rapid rollback after failed deployments

Problem: A deployment breaks the application; rolling back code/config is urgent.
Why this service fits: Restore selected directories from a pre-deployment backup.
Scenario: Trigger a manual backup before deployment; if deploy fails, restore application directory to the last backup point.

5) Protecting jump hosts and bastion toolchains

Problem: Jump hosts contain automation scripts, SSH configs, and operational tools.
Why this service fits: Low-cost, low-data backup that provides quick recovery.
Scenario: Back up /home/ops, /usr/local/bin, and automation repos nightly.

6) Backup for hybrid/edge servers (where supported)

Problem: Remote sites lack consistent backup; tapes and manual copies fail.
Why this service fits: Cloud-managed backup target (vault) with centralized policies.
Scenario: Edge Linux servers run an agent and back up data over VPN to a vault in the nearest region.

7) Protecting shared content repositories

Problem: Teams store shared content or build artifacts on servers; accidental deletion is common.
Why this service fits: Directory-level backup and selective restore.
Scenario: Back up /srv/artifacts every 6 hours; restore a deleted release artifact within minutes.

8) Incident response: forensic snapshot of critical directories

Problem: After a security event, you need to preserve evidence.
Why this service fits: Create on-demand backups and retain for investigation.
Scenario: Trigger a manual backup of security-relevant folders, retain for 1 year, and restrict restore permissions.

9) Migration safety net during re-platforming

Problem: Re-platforming introduces risk; you want a rollback option.
Why this service fits: Consistent backups before cutovers; restore if needed.
Scenario: Before migrating data to a managed service, back up directories and verify restore to a staging host.

10) Backup standardization across many teams

Problem: Every team runs different scripts; no standard monitoring.
Why this service fits: Central plans, job histories, and consistent retention policies.
Scenario: Platform team creates a baseline policy and onboards all ECS instances into Cloud Backup.

11) DR drills and restore testing

Problem: Backups exist but restores fail when needed.
Why this service fits: Restore tasks can be performed and validated regularly.
Scenario: Monthly restore test to a sandbox ECS instance and compare checksums.

12) Long-term retention using lower-cost storage class (where supported)

Problem: You need long retention but costs rise with standard storage.
Why this service fits: Vault storage classes (for example, Standard vs Archive) may be available.
Scenario: Keep 30 days in standard vault, replicate/retain quarterly points in archive vault (verify feature availability).

6. Core Features

Feature availability differs by backup source type, region, and product edition. Verify exact support in official docs for your workload.

1) Backup vaults (regional backup storage)

What it does: Creates a managed container where backup data is stored.
Why it matters: The vault is the core Storage cost and retention boundary.
Practical benefit: Central place to control retention, encryption options, and lifecycle behaviors.
Limitations/caveats: Vault location is region-bound; moving data cross-region may require replication or export patterns (verify).

2) Policy-based scheduling (backup plans)

What it does: Automates backup frequency (hourly/daily/weekly), backup windows, and retention rules.
Why it matters: Removes manual backups and ensures consistent RPO.
Practical benefit: Predictable restore points and reduced operator overhead.
Limitations/caveats: Aggressive schedules increase storage growth and network/host impact.

3) Incremental backups (agent-based file backup)

What it does: After an initial full backup, transfers only changed blocks/files depending on implementation.
Why it matters: Faster backups and lower bandwidth/storage consumption.
Practical benefit: More frequent backups without proportional cost increase.
Limitations/caveats: Initial seed backup can be heavy; plan off-peak windows.

4) Point-in-time restore and selective restore

What it does: Restores data from a chosen recovery point; often supports restoring individual files/folders for file backups.
Why it matters: Most incidents require restoring a subset, not the entire server.
Practical benefit: Faster recovery, less disruption.
Limitations/caveats: Application consistency is your responsibility unless the backup type supports app-consistent modes (verify).

5) Backup job management and history

What it does: Shows job status, durations, transferred size, success/failures, and logs.
Why it matters: Backups that aren’t monitored are effectively not reliable.
Practical benefit: Faster troubleshooting and audit-ready reporting.
Limitations/caveats: Retention of job history itself may be limited; export if you need long-term operational reporting (verify).

6) Access control with RAM and service roles

What it does: Uses Alibaba Cloud RAM users/roles/policies to control who can manage backups and perform restores.
Why it matters: Restore permissions are highly sensitive and should be restricted.
Practical benefit: Separation of duties (backup admin vs restore operator).
Limitations/caveats: Misconfigured roles can block backups; validate permissions early.

7) Encryption (in transit and at rest)

What it does: Protects backup data during transfer and while stored; may integrate with KMS for key management.
Why it matters: Backup vaults contain high-value data.
Practical benefit: Reduces risk of data exposure and supports compliance controls.
Limitations/caveats: Customer-managed keys require strong key lifecycle management; key loss can make backups unrecoverable.

8) Bandwidth and performance controls (where available)

What it does: Lets you control backup windows, concurrency, or throughput (implementation varies).
Why it matters: Prevents backups from impacting production.
Practical benefit: Predictable workload performance.
Limitations/caveats: Tight throttles can cause missed backup windows.

9) Hybrid connectivity patterns (where supported)

What it does: Protects supported on-prem or edge hosts by sending backups to Alibaba Cloud vaults.
Why it matters: Centralized protection across hybrid estates.
Practical benefit: Unified policies and storage.
Limitations/caveats: Requires stable network and security design (VPN/Express Connect, firewall rules).

10) Multi-vault / tiering approach (design pattern)

What it does: Use different vaults for different retention/cost profiles (for example, short vs long retention).
Why it matters: Storage costs scale with retention.
Practical benefit: Optimize costs while meeting retention rules.
Limitations/caveats: Operational complexity; ensure restore operators know where restore points live.

7. Architecture and How It Works

High-level architecture

Cloud Backup generally works as:

You create a backup vault in a region.
You register a backup source (for example, an ECS server via agent/client).
You create a backup plan (schedule, retention, paths to protect).
The agent performs backup operations and sends data to the vault over the network.
The Cloud Backup control plane records job status and recovery points.
For restore, you select a recovery point and restore data back to a target host/path.

Control flow vs data flow

Control flow: Console/API calls authenticate via RAM → Cloud Backup service creates/updates plans → job orchestration occurs.
Data flow: Backup agent reads local data → transfers encrypted data to Cloud Backup endpoints → vault stores backup data → restore reads from vault → writes to target.

Integrations with related services (common)

RAM: identity, authorization, service-linked roles.
KMS: encryption key management (if configured).
ActionTrail: audit logs for API calls.
CloudMonitor: alarms/metrics for job status (verify exact metrics).
VPC / security groups / NAT Gateway: outbound access from ECS to Cloud Backup endpoints.

Dependency services

Network connectivity from protected resources to Cloud Backup service endpoints.
Time synchronization (NTP) is often critical for TLS and scheduling.
DNS resolution to reach service endpoints.

Security/authentication model

Operators authenticate with Alibaba Cloud identities (RAM users/roles, SSO if configured).
Agents/clients typically authenticate using an activation token/credential issued by Cloud Backup during registration (exact mechanism varies; verify).
Least privilege policies should separate backup plan management from restore and vault deletion.

Networking model

Backups usually require outbound connectivity to Alibaba Cloud service endpoints.
For private subnets, use NAT Gateway or equivalent egress path.
For hybrid, use VPN Gateway or Express Connect (depending on latency and bandwidth needs).

Monitoring/logging/governance considerations

Track:
backup job failures
missed schedules
vault growth rates
restore job activity (especially unexpected restores)
Use ActionTrail to audit administrative operations.
Use tags on vaults/plans/instances for cost allocation and governance.

Simple architecture diagram

flowchart LR
  U[Operator\n(RAM User/Role)] -->|Console/API| CB[Alibaba Cloud Cloud Backup\nControl Plane]
  ECS[ECS Instance\n(Backup Client/Agent)] -->|Backup Data (TLS)| CB
  CB --> V[Backup Vault\n(Region)]
  CB --> AT[ActionTrail\nAudit Logs]
  CB --> KMS[KMS\n(Optional)]

Production-style architecture diagram

flowchart TB
  subgraph ProdVPC[Production VPC]
    ECS1[ECS App Server A\nCloud Backup Agent]
    ECS2[ECS App Server B\nCloud Backup Agent]
    NAT[NAT Gateway / Egress]
  end

  subgraph Mgmt[Management & Security]
    RAM[RAM\nUsers/Roles/Policies]
    AT[ActionTrail]
    CM[CloudMonitor\nAlarms/Dashboards]
    KMS[KMS\nCMK (optional)]
  end

  subgraph BackupRegion[Backup Region]
    CB[Cloud Backup\nControl Plane]
    VAULT1[Vault - Standard\nShort retention]
    VAULT2[Vault - Archive/Long Retention\n(if supported)]
  end

  RAM --> CB
  ECS1 --> NAT --> CB
  ECS2 --> NAT --> CB
  CB --> VAULT1
  CB --> VAULT2
  CB --> AT
  CB --> CM
  CB --> KMS

8. Prerequisites

Before starting, ensure the following.

Account and billing

An active Alibaba Cloud account with billing enabled (pay-as-you-go or subscription as required).
Permissions to create and manage Cloud Backup vaults and backup plans.

Permissions / IAM (RAM)

A RAM user/role for lab administration with permissions for:
Cloud Backup management
ECS (to create an instance for the lab)
VPC/security groups (if you create networking)
(Optional) KMS, ActionTrail, CloudMonitor
If Cloud Backup uses service-linked roles, allow creation of the service-linked role when prompted.

Policy names and required actions can change. Use the official “Authorization” docs for Cloud Backup and prefer Alibaba Cloud managed policies when available (verify in RAM console and docs).

Tools

Access to Alibaba Cloud console.
SSH client for Linux (or Remote connection in ECS console).
Basic Linux shell familiarity.
Optional: Alibaba Cloud CLI if you plan to automate (not required for this tutorial).

Region availability

Choose a region where Cloud Backup is available.
Create the backup vault in the same region as your ECS instance for the lab to avoid cross-region complexity and potential extra costs.

Quotas/limits

Vault and protected instance quotas vary. Check the Cloud Backup console quotas/limits page (if provided) or official documentation.

Prerequisite services

For the hands-on lab below:

ECS instance (Linux) with outbound Internet access (public IP or NAT).
A security group allowing SSH inbound from your IP and outbound HTTPS (typical default outbound allow is sufficient).

9. Pricing / Cost

Cloud Backup pricing is usage-based and depends on what you protect, where you store backup data, and retention.

Because Alibaba Cloud pricing is region-dependent and can change, do not hardcode numbers in design documents. Always confirm current rates in official pricing pages.

Pricing dimensions (common)

Cloud Backup cost typically includes some combination of:

Backup storage usage (GB-month) in the backup vault
– Often the dominant cost driver. – Storage class (for example, Standard vs Archive) may have different rates (verify availability).
Backup data processing / protected instance fees (possible)
– Some backup products charge per protected resource, per client, or per backup type. – Verify in official pricing for your specific backup source type.
Restore and retrieval costs (possible)
– Some archive tiers can have retrieval charges and longer restore times. – Verify vault storage class behavior.
Network egress and cross-region transfer
– Backups inside the same region generally avoid Internet egress. – If you back up across regions or to/from on-prem over the Internet, bandwidth and egress charges may apply.
KMS charges (if using customer-managed keys)
– KMS API calls and key management costs can apply.

Free tier

Alibaba Cloud offerings sometimes include limited free trials or promotional quotas. Verify in official pricing whether Cloud Backup has a free tier or trial in your region.

Key cost drivers (what grows your bill)

Retention length (30 days vs 180 days is a big difference)
Backup frequency (hourly vs daily)
Change rate (databases/logs that churn heavily)
Number of protected hosts and protected path scope
Long-term storage tier selection (if available)
Restore testing frequency (restores can generate traffic and possibly retrieval costs)

Hidden or indirect costs

ECS resource overhead: CPU/disk I/O during backup windows.
NAT Gateway or bandwidth costs if private instances need outbound connectivity.
On-prem network (VPN/Express Connect) costs if using hybrid backups.
Operational overhead of compliance (restore tests, reporting).

How to optimize cost (practical)

Exclude non-essential directories (build caches, temporary files).
Set realistic retention:
Short retention for frequent points (e.g., 7–30 days)
Longer retention for weekly/monthly points only
Align schedules with change rate:
Hourly backups for rapidly changing data only
Daily backups for most workloads
Use separate vaults for environments (dev/test vs prod) to enforce different retention.
Monitor vault growth; alert on unexpected spikes (possible ransomware indicator).

Example low-cost starter estimate (no fabricated prices)

A small lab setup cost is driven by:

A single ECS instance protected with file-level backup
A small data set (for example, a few GB) backed up daily
A short retention period (for example, 7–14 days)
Standard vault storage only

To estimate: 1. Approximate protected data size × expected dedupe/compression benefit (unknown; don’t assume). 2. Multiply by retention recovery points and expected change rate. 3. Apply region-specific GB-month pricing from the official pricing page.

Example production cost considerations (what to model)

For production, model:

Total protected data (TB)
Daily change rate (%)
Backup frequency
Retention (daily/weekly/monthly tiers)
Vault storage class mix (if supported)
Cross-region replication/secondary copy (if used)
Expected restore tests and major incident restore scenarios

Official pricing references

Cloud Backup product page (navigate to Pricing from here): https://www.alibabacloud.com/product/cloud-backup
Cloud Backup documentation home (billing sections are usually linked here): https://www.alibabacloud.com/help/en/cloud-backup/

If you have access to Alibaba Cloud pricing calculator for your account/region, use it. If a calculator is not available for Cloud Backup, build a spreadsheet model using the pricing page dimensions.

10. Step-by-Step Hands-On Tutorial

This lab walks you through a real, low-risk Cloud Backup workflow: protect a directory on a Linux ECS instance with the Cloud Backup client/agent, run a backup, delete a file, and restore it.

Objective

Create a backup vault in Alibaba Cloud Cloud Backup.
Install and register the Cloud Backup client/agent on a Linux ECS instance.
Create a backup plan for a directory.
Execute a backup job and validate a restore.

Lab Overview

You will:

Prepare an ECS instance and a sample directory with test files.
Create a Cloud Backup vault.
Register the ECS instance by installing the Cloud Backup client/agent.
Create a file backup plan targeting your test directory.
Run a backup and verify recovery points.
Delete a file and restore it from Cloud Backup.
Clean up resources to avoid ongoing charges.

Cost safety: Keep the test data small (a few MB) and delete the vault during cleanup.

Step 1: Create (or choose) a Linux ECS instance for the lab

Console actions

Go to ECS in the Alibaba Cloud console.
Create an instance: – Image: a standard Linux distribution (e.g., Alibaba Cloud Linux / CentOS / Ubuntu) – Network: VPC with Internet access (public IP) or private instance with NAT Gateway egress – Security group: allow SSH inbound from your IP; allow outbound HTTPS (usually default)
Note the instance: – Private IP – Public IP (if assigned) – Root/administrator credentials or SSH key

Expected outcome – You can SSH to the instance.

Verify (from your terminal)

ssh <user>@<public-ip>
uname -a
df -h

Step 2: Create sample data to back up

On the ECS instance, create a small directory and a few files:

sudo mkdir -p /lab/cloudbackup-demo
sudo bash -c 'echo "Cloud Backup demo file 1" > /lab/cloudbackup-demo/file1.txt'
sudo bash -c 'echo "Cloud Backup demo file 2" > /lab/cloudbackup-demo/file2.txt'
sudo bash -c 'date > /lab/cloudbackup-demo/timestamp.txt'
sudo ls -la /lab/cloudbackup-demo

Expected outcome – The directory /lab/cloudbackup-demo exists with three small files.

Step 3: Create a backup vault in Cloud Backup

Console actions

Open the Cloud Backup console: – Product entry: Cloud Backup – Documentation home: https://www.alibabacloud.com/help/en/cloud-backup/
Choose a region (same as your ECS instance region for this lab).
Create a backup vault: – Name: vault-lab-demo – Storage class: choose the default/standard option (archive/long-term options vary; verify) – Encryption: use default settings unless you have a KMS requirement (for lab, default is simplest)

If prompted, allow Cloud Backup to create required service-linked roles.

Expected outcome – A vault named vault-lab-demo appears in the Cloud Backup console in your chosen region.

Verification – Vault status shows “Available/Active” (wording varies). – No backup data stored yet (0 or near 0 usage).

Step 4: Install and register the Cloud Backup client/agent on the ECS instance

For file-level server backups, Cloud Backup typically requires installing an agent/client and registering it to your Cloud Backup service using an activation code.

Console actions (recommended because commands can be region-specific)

In Cloud Backup console, navigate to the section for server/ECS file backup (wording varies by console version).
Choose Add Server / Register Client.
Select Linux and copy the installation command shown in the console.

On the ECS instance

Paste and run the copied command.

It often looks like: – download package (wget/curl) – install agent – register with an activation token

Because URLs and tokens are region-specific and change over time, use the command generated by your console rather than a hardcoded example.

Expected outcome – The client installs successfully and the ECS host appears as Registered/Online in Cloud Backup.

Verification – In Cloud Backup console, the host shows “Online” (or similar). – On the server, you can usually confirm the agent process/service is running:

sudo systemctl status <agent-service-name>

If you don’t know the service name, check the installation output or the official Cloud Backup agent installation guide.

If your distribution does not use systemd, use the appropriate service manager (init.d) and verify in official docs.

Step 5: Create a file backup plan for `/lab/cloudbackup-demo`

Console actions

In Cloud Backup console, create a backup plan for your registered server.
Select: – Source: your ECS instance – Paths to back up: /lab/cloudbackup-demo – Vault: vault-lab-demo – Schedule: for the lab, choose a daily schedule or “Run immediately” if supported – Retention: 7 days (short retention for cost control)
Save/enable the plan.

Expected outcome – The backup plan is enabled and shows next run time or ready state.

Verification – The plan appears in the plan list. – The server is linked to the plan and vault.

Step 6: Run a backup job and confirm a recovery point exists

Console actions

If the plan supports manual execution, click Run Now.
Otherwise, wait for the scheduled job to start (for lab, choose a schedule that triggers soon if possible).

Expected outcome – A backup job starts and then completes successfully. – A recovery point/backup version is created.

Verification – In job history: – Status: Succeeded – Data size: small (KB/MB) – In restore points: – You can see a recovery point timestamp for the ECS instance/path.

Step 7: Simulate data loss and restore

On the ECS instance, delete one file:

sudo rm -f /lab/cloudbackup-demo/file2.txt
sudo ls -la /lab/cloudbackup-demo

Expected outcome – file2.txt is missing.

Console actions (restore)

Go to the restore section for the backup plan or the protected server.
Choose the latest successful recovery point.
Select the file or folder to restore: – Restore source path: /lab/cloudbackup-demo/file2.txt (or select the folder and restore all)
Restore target: – For lab, restore to the original path /lab/cloudbackup-demo/ – If you want a safer approach, restore to an alternate path (if supported) like /lab/cloudbackup-restore/

Start the restore task.

Expected outcome – Restore job completes successfully.

Verification (on ECS instance)

sudo ls -la /lab/cloudbackup-demo
sudo cat /lab/cloudbackup-demo/file2.txt

You should see the restored file contents.

Validation

Use this checklist to confirm the lab worked end-to-end:

[ ] Vault vault-lab-demo exists and shows non-zero usage after backup.
[ ] ECS host is registered and shows Online/Connected.
[ ] Backup plan is enabled and has at least one successful job.
[ ] A recovery point exists for the plan.
[ ] Deleted file is restored and readable.

Optional deeper validation (integrity):

sudo sha256sum /lab/cloudbackup-demo/file1.txt /lab/cloudbackup-demo/file2.txt /lab/cloudbackup-demo/timestamp.txt

Record hashes after restore and compare with known-good values if you captured them pre-delete.

Troubleshooting

Common issues and fixes:

Agent shows Offline – Check outbound connectivity (DNS + HTTPS) from ECS. – If in a private subnet, ensure NAT Gateway and routes exist. – Check system time (timedatectl) and NTP sync.
Installation fails – Confirm OS and architecture are supported by the Cloud Backup agent (verify in docs). – Ensure you have root/sudo permissions. – Confirm required dependencies listed by the install guide.
Backup job fails with permission errors – Ensure the agent runs with sufficient permissions to read the target directory. – Check file ownership and permissions under /lab/cloudbackup-demo.
Backup plan cannot find host – Ensure the host is registered in the same region as your vault/plan configuration. – Refresh the console and confirm correct region selection.
Restore completes but file missing – Confirm restore target path. – Check whether the restore writes to an alternate directory by default. – Review restore job logs/details in the console.
Costs higher than expected – Reduce retention. – Exclude large/volatile paths. – Use a separate vault for lab and delete it afterward.

Cleanup

To avoid ongoing charges, delete created resources.

1) Delete the backup plan – Cloud Backup console → Plans → select your plan → Disable/Delete (wording varies)

2) Unregister the server (optional) – If you don’t need Cloud Backup agent on the ECS, remove/unregister it in console. – On ECS, uninstall the agent using the official uninstall procedure (verify in docs).

3) Delete the backup vault – Cloud Backup console → Vaults → vault-lab-demo → Delete
You may need to delete backup data first or confirm permanent deletion.

4) Delete ECS instance (if created only for this lab) – ECS console → Instance → Release

Expected outcome – No backup plans, no vaults, and no ECS instance remain from this lab.

11. Best Practices

Architecture best practices

Design for RPO/RTO explicitly:
RPO determines backup frequency.
RTO determines restore procedure, automation, and testing frequency.
Separate vaults by environment and sensitivity:
vault-prod, vault-nonprod, vault-longretention
Use least-privilege roles for backup operators vs restore operators.
Plan restores as first-class workflows:
Document restore steps and run regular restore drills.

IAM/security best practices

Restrict who can:
delete vaults
change retention
initiate restores
Use RAM policies with scoped resources where possible (verify resource-level permissions).
Enforce MFA and SSO for privileged users.
Use service-linked roles as intended; don’t reuse broad admin keys for automation.

Cost best practices

Right-size retention. Retention is usually the biggest cost multiplier.
Use exclusion lists for:
caches (/var/cache)
temp folders (/tmp)
build outputs you can regenerate
Monitor vault growth rate and set budget alerts in your billing tools.

Performance best practices

Run backups off-peak.
If available, throttle bandwidth or concurrency to reduce impact.
Avoid backing up large numbers of small files too frequently unless needed (metadata overhead).
Place the vault in the same region as the source for best performance and lower transfer complexity.

Reliability best practices

Implement 3-2-1 thinking (conceptually): multiple copies, different media, offsite.
Cloud Backup provides one layer; consider additional layers such as cross-region strategy (verify supported methods).
Ensure you can recover even if the primary environment is impaired:
keep credentials/restore runbooks in a separate secure system
validate alternate restore targets

Operations best practices

Alert on:
job failure
missed schedules
abnormal vault growth
Tag everything:
env=prod, app=payments, owner=platform, costcenter=...
Maintain a monthly restore test schedule and record results for audits.

Governance/tagging/naming best practices

Naming:
Vault: vault-<env>-<region>-<purpose>
Plan: plan-<app>-<data>-<freq>-<retention>
Tag resources consistently and align with cost allocation.

12. Security Considerations

Identity and access model

Use RAM to manage:
admins who create vaults and plans
operators who view job status
security/IR who can perform restores
Treat restore permission as highly privileged (it can exfiltrate data).

Encryption

Use encryption in transit (TLS) as provided by the service/agent.
Prefer encryption at rest options supported by Cloud Backup.
If using KMS customer-managed keys (CMKs):
define key rotation and access controls
plan for key availability and disaster recovery
understand that losing access to keys can block restores

Network exposure

Ensure protected servers can reach Cloud Backup endpoints securely.
For private networks, use NAT/egress control and restrict outbound destinations where feasible.
For hybrid backups, prefer private connectivity (VPN/Express Connect) over public Internet when handling sensitive data.

Secrets handling

Avoid embedding long-lived access keys on hosts.
Use the official registration mechanism for agents (activation code/token) and rotate/revoke if compromise is suspected.
Store operational credentials in a secrets manager (if used) and enforce rotation policies.

Audit/logging

Enable and review ActionTrail logs for:
vault deletion attempts
retention changes
restore job starts
policy modifications
Integrate audit logs with a SIEM if required.

Compliance considerations

Cloud Backup can support compliance objectives such as:

retention enforcement
audit trails for administrative actions
encryption controls

But compliance is shared responsibility. You still must:

define data classification
enforce least privilege
document and test restores
ensure retention meets regulatory requirements

Common security mistakes

Giving too many users restore permissions.
No MFA on privileged accounts.
No alerting on vault deletion or retention reduction.
Backing up sensitive data without encryption controls or without key management governance.
Not testing restore (discovering too late that backups are incomplete).

Secure deployment recommendations

Separate roles:
Backup Admin (create/modify plans)
Restore Operator (perform restores under approval)
Auditor (read-only access)
Enable ActionTrail and keep logs protected.
Use tags and naming to prevent accidental deletes.
Run periodic restore drills into isolated environments.

13. Limitations and Gotchas

These are common patterns; verify the exact constraints for your region, backup type, and current Cloud Backup release.

Region-scoped vaults: backups are tied to the vault region; cross-region recovery requires design (verify supported cross-region features).
Initial backup can be heavy: the first run may consume CPU/disk I/O and bandwidth.
Restore speed varies: depends on data size, vault tier, and network throughput.
Agent compatibility: not all OS versions/architectures may be supported.
Application consistency: file-level backups may not be application-consistent for certain workloads unless explicitly supported.
Retention changes affect cost and recoverability: lowering retention may delete needed restore points.
Permissions complexity: service-linked roles and RAM policies can cause silent failures if incomplete.
Egress/NAT dependency: private subnets need a maintained egress path for backup.
Large numbers of small files: can cause longer backup windows due to metadata overhead.
Archive tiers (if used): may introduce retrieval delay and retrieval costs (verify).

14. Comparison with Alternatives

Cloud Backup sits in the “managed backup” space. Consider alternatives based on workload type and recovery goals.

Alternatives inside Alibaba Cloud

ECS Snapshots / Snapshot policies: great for disk-level rollback; not a substitute for long-term retention or granular file restore.
OSS Versioning + Lifecycle: great for object-level protection; not a full server backup system.
NAS snapshots (if available on your NAS type): fast file system rollback; limited offsite and retention patterns.
Database-specific backup services (for example, managed database backup features): best for databases requiring application-consistent backups.

Alternatives in other clouds (conceptual comparison)

AWS Backup, Azure Backup, Google Backup and DR: similar managed backup platforms but different integration depth, pricing models, and supported sources.

Open-source / self-managed alternatives

restic/borg/duplicity backing up to OSS: flexible and cheap for some cases, but you own scheduling, monitoring, security, and restore reliability.
Enterprise tools (Veeam, Commvault): rich features and broad source support, but higher licensing/ops overhead.

Comparison table

Option	Best For	Strengths	Weaknesses	When to Choose
Alibaba Cloud Cloud Backup	Centralized managed backups for Alibaba Cloud/hybrid workloads	Managed vaults, policy scheduling, restore workflows, console visibility	Feature scope depends on supported sources/regions; may require agent	When you want managed backup with Alibaba Cloud-native integration
ECS Snapshots / Snapshot policies	Fast rollback of disks/instances	Simple, fast, integrates with ECS disks	Not always granular; long-term retention patterns vary	When disk-level recovery is sufficient and you want quick rollback
OSS Versioning + Lifecycle	Object data protection	Native object-level restore and retention	Only for OSS objects; not server files	When your critical data is in OSS and you need object version recovery
NAS snapshots (if supported)	File system rollback	Fast restores, low operational effort	May not satisfy offsite/air-gapped requirements	When your data is primarily on NAS and snapshot retention is enough
Self-managed restic/borg to OSS	DIY backup for small teams	Low cost, flexible	You manage everything; restore reliability risk	When you need custom behavior and accept operational ownership
Enterprise backup (Veeam/Commvault)	Large heterogeneous enterprises	Broad integration, advanced features	Licensing cost, infrastructure overhead	When you already operate enterprise backup across multiple platforms
AWS Backup / Azure Backup / Google Backup & DR	Multi-cloud teams standardized elsewhere	Cloud-native backups in their ecosystems	Not Alibaba Cloud-native; cross-cloud adds complexity	When primary footprint is in another cloud or you need a cross-cloud standard

15. Real-World Example

Enterprise example: regulated fintech protecting ECS fleets

Problem: A fintech runs dozens of ECS instances with strict compliance. They need auditable backups, separation of duties, and predictable restores.
Proposed architecture:
Cloud Backup vaults per environment (vault-prod, vault-nonprod) in-region
Backup plans by application tier:
- daily backups for most servers
- more frequent backups for config/state servers
RAM roles:
- Backup Admin: manage plans
- Restore Operator: can restore only with ticket approval
- Auditor: read-only access + ActionTrail review
ActionTrail enabled and forwarded to a central audit system (implementation-specific)
Why Cloud Backup was chosen:
Central management across many ECS instances
Policy-based retention aligned to compliance
Restore workflows visible and auditable
Expected outcomes:
Reduced recovery time for accidental deletion and incidents
Audit-ready evidence of backup success and administrative actions
Standardized retention across teams with fewer manual scripts

Startup/small-team example: SaaS team protecting critical configs and tenant exports

Problem: A small SaaS team runs 5 ECS instances and periodically exports tenant data to files. They need a simple backup solution without hiring a dedicated backup admin.
Proposed architecture:
Single standard vault in the same region
Backup plan for:
- /etc
- /opt/app/config
- /srv/exports
14–30 day retention
Monthly restore test to a staging instance
Why Cloud Backup was chosen:
Faster to implement than building a custom restic pipeline
Central job monitoring in the console
Expected outcomes:
Lower risk of losing configs or exports
Clear recovery procedure that any engineer can follow
Predictable storage costs controlled by retention

16. FAQ

Is Cloud Backup the same as OSS snapshots or versioning?
No. OSS versioning is object-level protection inside OSS. Cloud Backup is a managed backup service that stores recovery points in backup vaults and provides backup plans and restore workflows. They can complement each other.
Do I need an agent for Cloud Backup?
For server file-level backups, yes—an agent/client is typically required. For other data sources, Cloud Backup may use native integrations instead. Verify per workload type.
Is Cloud Backup regional or global?
Backup vaults are typically region-scoped. You choose a region when creating a vault. Cross-region designs may be possible but must be verified in official docs.
Can I restore to a different server?
Often yes for file-level backups (restore to alternate path/host) depending on the restore workflow and agent registration. Verify the supported restore targets for your backup type.
Does Cloud Backup provide immutable backups (ransomware protection)?
Some backup services offer WORM/immutability options. Whether Cloud Backup supports immutability depends on current product features—verify in official docs and design accordingly.
How do I estimate Cloud Backup storage growth?
Model: initial protected size + daily change rate × retention × backup frequency, then adjust based on dedup/compression behavior (don’t assume). Monitor actual vault growth after rollout.
What’s the difference between backup frequency and retention?
Frequency is how often you create restore points (RPO). Retention is how long you keep restore points. Both drive cost and recoverability.
Does Cloud Backup replace high availability?
No. HA minimizes downtime; backups recover data after loss/corruption. Use both.
What happens if my KMS key is disabled or deleted?
If backups are encrypted with a customer-managed key, losing key access can prevent restores. Treat KMS key governance as critical.
Can backups impact ECS performance?
Yes—especially the first backup and during heavy change periods. Schedule off-peak and use performance controls if available.
How do I monitor failed backups?
Use Cloud Backup job history and integrate with CloudMonitor alerts where supported. Also audit administrative changes in ActionTrail.
Can I back up only specific directories?
Yes for file-level backups. Use include paths and exclusion rules if supported.
How do I protect against accidental vault deletion?
Restrict delete permissions, enforce change approval, use separate admin accounts, and enable ActionTrail alerts on delete operations.
How often should I test restores?
At least monthly for critical workloads, and after major changes (agent upgrades, policy changes, OS changes). Also test a full-scale restore scenario periodically.
Can I use Cloud Backup for on-prem servers?
Cloud Backup has historically supported hybrid scenarios via agents (legacy HBR). Verify current support, connectivity requirements, and region availability.
What’s the best practice for dev/test backups?
Short retention, lower frequency, smaller scope. Avoid backing up reproducible build outputs.
How do I automate Cloud Backup?
Use Alibaba Cloud APIs/SDKs (if available for Cloud Backup) and Infrastructure as Code patterns. Verify API coverage and authentication in official docs.

17. Top Online Resources to Learn Cloud Backup

Resource Type	Name	Why It Is Useful
Official product page	Alibaba Cloud Cloud Backup	Overview, entry point to console and docs: https://www.alibabacloud.com/product/cloud-backup
Official documentation	Cloud Backup documentation	Authoritative feature/workflow reference: https://www.alibabacloud.com/help/en/cloud-backup/
Official pricing	Cloud Backup pricing (from product page)	Region-specific pricing and billing dimensions (verify current): https://www.alibabacloud.com/product/cloud-backup
Getting started	Cloud Backup getting started guides (docs section)	Step-by-step onboarding, agent install, first backup (navigate from docs): https://www.alibabacloud.com/help/en/cloud-backup/
Authorization/IAM	Cloud Backup authorization documentation	Required RAM permissions, service-linked roles, least privilege: https://www.alibabacloud.com/help/en/cloud-backup/
Release notes / updates	Cloud Backup release notes (if available in docs)	Track feature changes and deprecations: https://www.alibabacloud.com/help/en/cloud-backup/
Audit logging	ActionTrail documentation	Auditing backup/restore administrative actions: https://www.alibabacloud.com/help/en/actiontrail/
Key management	KMS documentation	Customer-managed key lifecycle and access controls: https://www.alibabacloud.com/help/en/key-management-service/
Monitoring	CloudMonitor documentation	Alerts and dashboards for operations: https://www.alibabacloud.com/help/en/cloudmonitor/
Community learning	Alibaba Cloud community and blog	Practical write-ups and examples; validate against official docs: https://www.alibabacloud.com/blog

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, cloud engineers	Cloud operations, automation, DevOps practices (check Cloud Backup coverage)	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate DevOps practitioners	SCM/DevOps foundations, tooling, process (check cloud modules)	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud ops teams, platform teams	Cloud operations and reliability practices	Check website	https://cloudopsnow.in/
SreSchool.com	SREs, ops engineers, reliability leads	SRE principles, monitoring, incident response (tie-in with backup/DR)	Check website	https://sreschool.com/
AiOpsSchool.com	Ops and platform teams exploring AIOps	AIOps concepts, automation, operational analytics	Check website	https://aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content (verify offerings)	Beginners to intermediate engineers	https://rajeshkumar.xyz/
devopstrainer.in	DevOps training platform (verify course list)	DevOps engineers and students	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps help/training (verify services)	Teams needing short-term coaching	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support and enablement (verify scope)	Ops teams and small businesses	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify exact services)	Architecture, automation, operations	Backup policy design, operational runbooks, cost controls	https://cotocus.com/
DevOpsSchool.com	DevOps consulting and enablement (verify offerings)	Platform engineering, CI/CD, operations	Standardizing backup/restore processes, SRE-aligned operations	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify exact services)	DevOps adoption and operational maturity	Implementing backup monitoring/alerting, governance and IAM reviews	https://devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Cloud Backup

Alibaba Cloud fundamentals:
Regions vs zones
VPC, security groups, NAT Gateway
ECS basics (Linux admin, SSH, disks)
Storage basics:
file systems, object storage concepts
retention, lifecycle, and durability
Security basics:
RAM identities and policies
encryption fundamentals and KMS concepts
Backup concepts:
RPO, RTO, retention tiers
full vs incremental backups
restore testing and runbooks

What to learn after Cloud Backup

Disaster recovery architectures:
multi-region strategies
workload prioritization and runbooks
Observability and incident response:
CloudMonitor alerting patterns
ActionTrail auditing workflows
Infrastructure as Code:
Terraform (if used in your org)
automated policy enforcement and compliance checks
Data protection hardening:
immutability/WORM patterns (if supported)
privileged access management

Job roles that use Cloud Backup

Cloud Engineer / Cloud Administrator
Site Reliability Engineer (SRE)
DevOps Engineer / Platform Engineer
Security Engineer (backup governance, audit, ransomware recovery)
Solutions Architect (designing DR and data protection)

Certification path (if available)

Alibaba Cloud certifications and learning paths change over time. Check Alibaba Cloud training/certification pages and map Cloud Backup knowledge into:

Cloud fundamentals certifications
Architect or professional-level tracks that include storage, security, and DR

(Verify current Alibaba Cloud certification offerings in official training portals.)

Project ideas for practice

Implement Cloud Backup for a 3-tier ECS app and run monthly restore drills.
Create environment-based retention: dev (7 days), stage (14 days), prod (30/180 days tiered).
Build an alerting workflow: backup failure triggers CloudMonitor alarm + incident ticket.
Run a ransomware simulation on a test host and measure RTO from last safe restore point.
Cost model and optimization: measure vault growth and tune exclusions/retention.

22. Glossary

Backup vault: The Cloud Backup storage container in a region where backups are stored.
Recovery point: A point-in-time backup that you can restore from.
Backup plan/policy: A configuration defining what to back up, how often, and how long to retain recovery points.
Retention: How long backups are kept before expiration.
RPO (Recovery Point Objective): Maximum acceptable data loss measured in time (e.g., 4 hours).
RTO (Recovery Time Objective): Maximum acceptable time to restore service/data.
Incremental backup: Backs up only changes since the last backup (full or incremental), reducing transfer and storage.
Full backup: Initial baseline backup containing all selected data.
Restore task/job: A workflow that recovers data from a vault to a target.
RAM: Alibaba Cloud Resource Access Management for identity and authorization.
Service-linked role: A predefined role that allows a service to access other Alibaba Cloud resources securely.
KMS: Key Management Service used to manage encryption keys.
ActionTrail: Alibaba Cloud auditing service that records API calls and events.
CloudMonitor: Alibaba Cloud monitoring service for metrics and alerts.
VPC: Virtual Private Cloud networking boundary for ECS and other services.
NAT Gateway: Provides outbound Internet access for private instances.

23. Summary

Alibaba Cloud Cloud Backup is a Storage-category managed service for policy-based backups and restores using backup vaults, backup plans, and (for server/file backups) an agent/client. It matters because it reduces data-loss risk, improves recovery readiness, and centralizes backup operations with auditability.

From an architecture standpoint, keep vaults region-aligned with sources, design around explicit RPO/RTO, and treat restore workflows as the primary success criterion. Cost is mainly driven by vault storage growth (size, change rate, retention) plus any workload-specific charges and potential network/KMS costs—so optimize scope, frequency, and retention.

Use Cloud Backup when you want managed, centralized backup/restore in Alibaba Cloud. Don’t rely on it as a substitute for high availability, and don’t skip restore testing.

Next step: read the official Cloud Backup documentation for your exact workload type and implement a production-ready backup policy with monitoring, least-privilege IAM, and scheduled restore drills: https://www.alibabacloud.com/help/en/cloud-backup/

Category

1. Introduction

2. What is Cloud Backup?

Core capabilities (high level)

Major components

Service type

How it fits into the Alibaba Cloud ecosystem

3. Why use Cloud Backup?

Business reasons

Technical reasons

Operational reasons

Security/compliance reasons

Scalability/performance reasons

When teams should choose Cloud Backup

When teams should not choose it

4. Where is Cloud Backup used?

Industries

Team types

Workloads

Architectures and deployment contexts

Production vs dev/test usage

5. Top Use Cases and Scenarios

1) ECS configuration and application file backup (file-level)

2) Ransomware recovery for small servers

3) Compliance retention for operational logs (file backup)

4) Rapid rollback after failed deployments

5) Protecting jump hosts and bastion toolchains

6) Backup for hybrid/edge servers (where supported)

7) Protecting shared content repositories

8) Incident response: forensic snapshot of critical directories

9) Migration safety net during re-platforming

10) Backup standardization across many teams

11) DR drills and restore testing

12) Long-term retention using lower-cost storage class (where supported)

6. Core Features

1) Backup vaults (regional backup storage)

2) Policy-based scheduling (backup plans)

3) Incremental backups (agent-based file backup)

4) Point-in-time restore and selective restore

5) Backup job management and history

6) Access control with RAM and service roles

7) Encryption (in transit and at rest)

8) Bandwidth and performance controls (where available)

9) Hybrid connectivity patterns (where supported)

10) Multi-vault / tiering approach (design pattern)

7. Architecture and How It Works

High-level architecture

Control flow vs data flow

Integrations with related services (common)

Dependency services

Security/authentication model

Networking model

Monitoring/logging/governance considerations

Simple architecture diagram

Production-style architecture diagram

8. Prerequisites

Account and billing

Permissions / IAM (RAM)

Tools

Region availability

Quotas/limits

Prerequisite services

9. Pricing / Cost

Pricing dimensions (common)

Free tier

Key cost drivers (what grows your bill)

Hidden or indirect costs

How to optimize cost (practical)

Example low-cost starter estimate (no fabricated prices)

Example production cost considerations (what to model)

Official pricing references

10. Step-by-Step Hands-On Tutorial

Objective

Lab Overview

Step 1: Create (or choose) a Linux ECS instance for the lab

Step 2: Create sample data to back up

Step 3: Create a backup vault in Cloud Backup

Step 4: Install and register the Cloud Backup client/agent on the ECS instance

Step 5: Create a file backup plan for /lab/cloudbackup-demo

Step 6: Run a backup job and confirm a recovery point exists

Step 5: Create a file backup plan for `/lab/cloudbackup-demo`