Step-by-Step Guide: Configuring Zero Data Loss Autonomous Recovery Services for Oracle DBCS

Ensuring business continuity and data protection in the cloud has become mission-critical. Oracle’s Zero Data Loss Autonomous Recovery Service (ZDLARS) helps organizations protect their Autonomous Databases and DBCS (Database Cloud Services) with minimal manual effort, near-zero data loss, and automated recovery capabilities.

This blog provides a step-by-step walkthrough to configure Autonomous Recovery Services (ARS) with detailed screenshots and explanations.

Prerequisites

Before you begin:

• You must have access to an Oracle Cloud Infrastructure (OCI) account.

• An active DBCS (Oracle Database Cloud Service) instance.

• Necessary permissions to create and assign IAM policies.

• A registered private subnet is in the same region as your database.

Step 1: Create A Protection Policy for the ZDLARS

Creating a Protection Policy for Your Database Compartment in OCI

Best Practice: Use Dedicated Compartments

OCI best practices recommend creating separate compartments for different systems to maintain clean governance, improved access control, and better resource organization. This ensures that each environment—whether for dev, test, or production—is logically isolated and easier to manage.

We’ve set up a dedicated compartment to host our two-node RAC Extreme Edition database. With this structure in place, the next step is configuring a Protection Policy for this compartment.

Steps to Create a Protection Policy

1. Navigate to the Database Backup and Protection Policies Section

   • From the OCI Console, go to Database > Backup & Protection Policies.

2. Create a New Protection Policy

   • Click Create Protection Policy.

   • Provide a clear and descriptive name (e.g.,om_palane_db Protection Policy).

   • Select the compartment where your RAC database resides.

Step 2 : Create a Recovery Subnet for the database 

Enabling Secure Backups with Recovery Service Subnets in OCI

When it comes to protecting your Oracle Cloud databases, network isolation plays a key role in ensuring secure and efficient backup operations. Oracle Cloud Infrastructure (OCI) addresses this through Recovery Service subnets, which establish a dedicated network path between your databases and the OCI Recovery Service.

Best Practice: Use a Private Subnet for  Immutable Backups

For strong security with immutable backup, OCI requires that your database VCN includes a single, private subnet dedicated exclusively to Recovery Service backups. This subnet should not be shared with other services or applications, helping you maintain a clean and controlled environment for backup traffic.

How to Register a Recovery Service Subnet

The process is streamlined through the OCI Console:

[1]The name of the Recovery subnet is used to identify the subnet 

[2]A compartment to be created, preferably in the network compartment  

[3]Choose the Particular VCN that has been associated with the   database; it should be your database private subnet 

[4] The recovery subnet that will be used for the immutable backups (you should have created a subnet in the compartment before this registration here we are registering that subnet as the recovery service subnet.

Step 3: Create the IAM Policies for Autonomous Recovery services 

To enable secure and streamlined management of Autonomous Recovery Services, you need to define the right IAM policies at both the tenancy and compartment levels. These policies grant the necessary permissions to the designated group responsible for managing backup and recovery operations.

Define Policies in the OCI Console

1. Navigate to Identity & Security > Policies in the OCI Console.

2. Create a new policy (or edit an existing one) with a clear name like AUTONOMOUS_RECOVERY_SERVICES_POLICY.

3. Assign the policy at the tenancy level to ensure broad access for service operations.

Example Policy Statements

Here are some recommended statements,

Allow service database to manage recovery-service-family in tenancy

Allow service database to manage tagnamespace in tenancy

Allow service rcs to manage recovery-service-family in tenancy

Allow service rcs to manage virtual-network-family in tenancy

Allow group <your-admin-group> to manage recovery-service-family in tenancy

Step 4: Creating the Protection Policy 

Create the Protection Policy for the backup based on the number of days specified, and the backups will be retained  for the specified number of days

[1]Provide the Name of the Protection Policy

[2]Database compartment

[3] Specify the number of days the backup is to be retained 

Click enable retention lock so no one can go and delete the backups. There are methods to keep the backup for 10 years.  Depending on your requirements, LTR Recovery Service can retain your LTR backups for anywhere between 90 days and 10 years. Will see about the LTR in a separate blog post 

Step 5: Enabling the Autonomous Recovery Section in DBCS

Navigate to the DBCS instance in OCI. Under the Autonomous Recovery section, click Enable. This will protect the database instance under the Oracle-managed recovery service. It starts by preparing the infrastructure for protection with Zero Data Loss.

1. Enable automatic backups. The Checkbox must be checked to enable backup functionality.

• OCI will automatically perform scheduled backups when enabled according to the chosen configuration.

2. Backup destination: A dropdown field to select where the backups will be stored. To enable the Autonomous Recovery Service, we need to choose  the Autonomous Recovery Service

3. Protection policy: Displays the current policy selected for backup retention and recovery. In this example:

• _AUTONOMOUS_RECOVERY_SERVICES_PROTECTION_POLICY -- the policy that we had created in the earlier steps, which has a 31-day recovery window 

4. Real-time data protection

• Select this checkbox to enable real-time redo log backups, ensuring that changes are continuously backed up between scheduled backups,, and with near-zero lag,, the logs will be applied to the backups

5. Deletion options after database termination

Two radio buttons to define what happens to backups after the source database is deleted:

Retain backups according to the protection policy retention period
Backups follow the full policy period (e.g., 31 days).
Retain backups for 72 hours, then delete
Backups are kept for a short period after termination and then removed.

 6. Scheduled time for daily backup (UTC)

• Dropdown to define the daily backup time window.

 Take the first backup immediately . When this checkbox is selected, OCI initiates the first backup as soon as the configuration is saved. Useful for getting a baseline backup without waiting for the scheduled time.

Step 6:  Check the database with the protection summary 

 

How to Get OCI Region and Instance Metadata from a Linux Server

When working with Oracle Cloud Infrastructure (OCI), there are times when you need to quickly fetch instance-level metadata — like the region, availability domain, shape, and other details — directly from the server. Fortunately, OCI exposes a handy metadata service that makes this easy to access from the command line.

In this post, I’ll show you how to pull just the region using curl, and also explain what other information is available if you query the full metadata endpoint.

Fetching the Region of an OCI Instance

To retrieve the region (like me-dubai-1) of an instance running on OCI, you can use:

curl -s http://169.254.169.254/opc/v1/instance/ | grep '"region":' | awk -F '"' '{print $4}'

[root@<Servername> <foldername>]# curl -s http://169.254.169.254/opc/v1/instance/ |grep region

  "region": "me-dubai-1",

  "regionInfo": {

    "regionIdentifier": "me-dubai-1",

    "regionKey": "DXB"

}

Another method to use is JQ

curl -s http://169.254.169.254/opc/v1/instance/ | jq -r '.region'

To get the complete instance metadata  

You’ll get the entire instance metadata in JSON format. Here’s a trimmed sample of what that might look like:

{

  "availabilityDomain": "",

  "compartmentId": "OCID",

  "displayName": "instance Name",

  "faultDomain": "FAULT-DOMAIN-1",

  "hostname": "Hostname of the Instance ",

  "id": "ocid ..",

  "image": "which version of O/S image had been used,

  "region": "me-dubai-1",

  "regionInfo": {

    "regionIdentifier": "me-dubai-1",

    "regionKey": "DXB"

  },

  "shape": "Type of VM",  like VM standard flexe4

  "state": "Running",

  "timeCreated": ",

  "metadata": {

    "ssh_authorized_keys": "SSH keys associated with the instance "

  }

}

Some key fields 

Field	Description
region	The region where the instance is running
availability Domain	Availability Domain (e.g., ME-DUBAI-1-AD-1)
compartment Id	OCID of the compartment
shape	Instance shape (e.g., VM.Standard.E4.Flex)
display Name	Name of the instance
hostname	Hostname of  the instance
id	OCID of the instance
state	Instance lifecycle state (e.g., Running)

Formatting JSON Output (Without jq)

If jq isn’t installed, you can still format the JSON nicely using Python:

curl -s http://169.254.169.254/opc/v1/instance/ | python3 -m json.tool

Notes:

The instance metadata service is local and does not require any credentials or internet access. It’s a super handy tool for automation scripts, configuration checks, or logging environment info in multi-region deployments.

 Monitoring Protected  Databases with Oracle Autonomous Recovery Service

After configuring automatic backups for your Oracle Cloud Infrastructure (OCI) databases, the next critical step is to verify and monitor the protection status. Oracle makes this easy through the Protected Databases dashboard in the Autonomous Recovery Service.

This post explains what each column means and how to interpret the information so you can confidently manage backup health and recovery readiness.

Navigation : 

Navigate to the Autonomous Recovery Service dashboard, then select your compartment—in this example, it’s PROD_DB_RAC_COMP. You’ll be presented with a table listing all protected databases under this compartment.

 Breakdown of the Protected Databases Table

Here's a detailed explanation of what each column in the table represents:

Column 1 Name

Column 2 State

• Value: Active/inactive 

• This indicator indicates the database's registration and protection state within the Recovery Service. An “Active” status confirms that the protection is up and running.

Column 3 Health

• Value : Protected/unprotected.

• Reflects the current health status of backup coverage.

• A "Protected" status means backups are compliant with the defined policy.

• If present, an info icon (ⓘ) may provide further context or health alerts.

Column 4 Source Database : 

• A unique identifier or name of the actual database is being protected. This is helpful in matching databases in other OCI services like Database Systems or Exadata Cloud.

Column 5 Real-Time Protection

• Value : Enabled/Disabled 

• Indicates whether real-time redo log backup is active.

• When enabled, the logs are continuously sent to the Recovery Service, like DR log shipping, minimizing data loss during unexpected failures.

Column 6 Data Loss Exposure

• Value : 0  to XXX....... seconds.

• Shows the amount of potential data loss in case of recovery. Zero seconds confirms full real-time protection is functioning properly. If there is a number, for example, 600, then the last 600 seconds of data will be lost during the recovery process 

Column 7 Current Recovery Window

• Value:  h  m  s 

• This displays how far back in time you can restore your database. It grows until it reaches the maximum retention period defined by your protection policy (e.g., 31 days).

Column 8 Recovery Window Space Used

• Value :  GB

• Total storage space is used to maintain recovery data across the current window. This includes incremental backups, redo logs, and metadata.

Column 9 Protection Policy

• Value:  the recovery policy that we had selected during the configuration of the autonomous recovery service eg: AUTONOMOUS_RECOVERY_SERVICES_PROTECTION_POLICY 

• It identifies the retention and recovery rules applied to the database. Clicking the link provides detailed policy configurations, such as recovery window length, backup frequency, and redundancy.

Column 10 Database Size

• Value shown:  GB

• Displays the current total size of the database being protected.

• Useful for understanding storage consumption and planning for backup window usage.

Why This Matters

Monitoring this dashboard is key to:

• Verifying backup and recovery readiness

• Ensuring compliance with data protection policies

• Planning for storage and recovery performance

The ability to see real-time protection, data loss exposure, and current recovery windows at a glance offers transparency and confidence in your data resilience strategy.

 

Resolving RPM Database Corruption Before Package Upgrades

Issue: During system maintenance on the OCI Linux environment, we encountered an issue where the RPM database became corrupted, causing dnf upgrade to fail with the following error:

 

[root@omdmz ~]# dnf upgraade

error: rpmdb: BDB0113 Thread/process 590272/140176820012928 failed: BDB1507 Thread died in Berkeley DB library

error: db5 error(-30973) from dbenv->failchk: BDB0087 DB_RUNRECOVERY: Fatal error, run database recovery

error: cannot open Packages index using db5 -  (-30973)
error: cannot open Packages database in /var/lib/rpm
Error: Error: rpmdb open failed

Step 1: Clean Up Stale RPM Database Files

To fix the issue, I first removed all temporary __db.* files:  as this clears out incomplete or orphaned transactions that may have caused the corruption.

[root@omapps01 rpm]# rm -f __db.*

D: adding 1 entries to Installtid index.

D: adding 1 entries to Sigmd5 index.

D: adding "7ab75f337467cc17322ec627c0f5525bcd83a735" to Sha1header index.

D:  read h#    2707

Header SHA256 digest: OK

Header SHA1 digest: OK

D: adding "flatpak" to Name index.

D: adding 129 entries to Basenames index.

D: adding "Unspecified" to Group index.

D: adding 78 entries to Requirename index.

D: adding 2 entries to Providename index.

D: adding 1 entries to Conflictname index.

D: adding 58 entries to Dirnames index.

D: adding 1 entries to Installtid index.

D: adding 1 entries to Sigmd5 index.

D: adding "453cd6fb88f9b42a07e8f9ab047f0e8e94e2fda8" to Sha1header index.

D: adding 2 entries to Recommendname index.

D:  read h#    2201

Header SHA256 digest: OK

Header SHA1 digest: OK

D: adding "swtpm-tools" to Name index.

D: adding 34 entries to Basenames index.

D: adding "Unspecified" to Group index.

D: adding 36 entries to Requirename index.

D: adding 3 entries to Providename index.

D: adding 15 entries to Dirnames index.

D: adding 1 entries to Installtid index.

D: adding 1 entries to Sigmd5 index.

D: adding "53d49b3bac3d0da69c55add54e90f2c33c3c5c95" to Sha1header index.

D:  read h#     667

Header SHA256 digest: OK

Header SHA1 digest: OK

D: adding "libXres" to Name index.

D: adding 8 entries to Basenames index.

D: adding "System Environment/Libraries" to Group index.

D: adding 11 entries to Requirename index.

D: adding 3 entries to Providename index.

D: adding 6 entries to Dirnames index.

D: adding 1 entries to Installtid index.

D: adding 1 entries to Sigmd5 index.

D: adding "6c7e1dc63b857095258408c570cc9ce6c15b8ec8" to Sha1header index.

D: closed   db index       /var/lib/rpm/Packages

D: closed   db environment /var/lib/rpm

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Packages

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Enhancename

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Supplementname

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Suggestname

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Recommendname

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Transfiletriggername

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Filetriggername

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Sha1header

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Sigmd5

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Installtid

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Dirnames

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Triggername

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Obsoletename

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Conflictname

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Providename

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Requirename

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Group

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Basenames

D: closed   db index       /var/lib/rpmrebuilddb.1125429/Name

D: closed   db environment /var/lib/rpmrebuilddb.1125429

==

Step 2:  check the location of  /var/lib/rpm 

[root@omdmz ~]# cd /var/lib/rpm

[root@omdmz rpm]# ls

Basenames     __db.001  __db.003  Enhancename      Group       Name          Packages     Recommendname  Sha1header  Suggestname     Transfiletriggername

Conflictname  __db.002  Dirnames  Filetriggername  Installtid  Obsoletename  Providename  Requirename    Sigmd5      Supplementname  Triggername

[root@omdmz rpm]#

Step 3: Rebuild the RPM db

rpm -vv --rebuilddb

This command reindexes the RPM database and ensures all package metadata is intact. The verbose flag -vv provides detailed output for troubleshooting, showing progress on database index handling.

Result

After successfully rebuilding the database, the dnf upgrade worked without errors, and the package system went back to normal.

This is a common issue on systems where RPM operations are interrupted (e.g., forced reboots, crashes). If you notice package-related errors, it’s always good practice to rebuild the RPM database after such events.

Setting a Persistent Hostname in Oracle Cloud (Oracle Linux )

When deploying virtual machines in Oracle Cloud Infrastructure (OCI), the cloud metadata service often manages hostname configuration. This can overwrite any manual hostname changes made on the instance after a reboot.

In this blog post, we'll walk through setting a custom hostname on an OCI instance running Oracle Linux 8.7 and ensuring it persists across reboots. 

Manually set the hostname of your OCI instance and configure it so that your changes aren't lost during reboots or restarts.

Step 1: Set the Static Hostname

Use the hostnamectl command to define your new hostname:

[root@omoicsso ~]# hostnamectl set-hostname omoicsso.oasiserp.com

You can verify the change by running:

[root@omoicsso ~]# hostnamectl

   Static hostname: omoicsso.oasiserp.com

         Icon name: computer-vm

           Chassis: vm

        Machine ID: e0251ef691f54fe7b98d3354af266d31

           Boot ID: 333e7d37ec2b45d6942b50a9bf180b11

    Virtualization: kvm

  Operating System: Oracle Linux Server 8.7

       CPE OS Name: cpe:/o:oracle:linux:8:7:server

            Kernel: Linux 5.15.0-100.96.32.el8uek.x86_64

      Architecture: x86-64

[root@omoicsso ~]#

At this point, the hostname has been changed — but it may not be persistent across reboots due to OCI's metadata-based management.

Step 2: Configure Hostname Persistence

OCI instances come with a special configuration file: /etc/oci-hostname.conf.

Edit or verify the following setting:

[root@omoicsso ~]# cat /etc/oci-hostname.conf

# This configuration file controls the hostname persistence behavior for Oracle Linux

# compute instance on Oracle Cloud Infrastructure (formerly Baremetal Cloud Services)

# Set PRESERVE_HOSTINFO to one of the following values

#   0 -- default behavior to update hostname, /etc/hosts and /etc/resolv.conf to

#        reflect the hostname set during instance creation from the metadata service

#   1 -- preserve user configured hostname across reboots; update /etc/hosts and

#           /etc/resolv.conf from the metadata service

#   2 -- preserve user configured hostname across instance reboots; no custom

#        changes to /etc/hosts and /etc/resolv.conf from the metadata service,

#        but dhclient will still overwrite /etc/resolv.conf

#   3 -- preserve hostname and /etc/hosts entries across instance reboots;

#        update /etc/resolv.conf from instance metadata service

PRESERVE_HOSTINFO=2

What Does This Do?

• PRESERVE_HOSTINFO=2 tells the system to preserve your manually configured hostname even after a reboot.

• It prevents the OCI metadata service from overwriting your hostname, while still allowing it to update /etc/resolv.conf.

Final Check

After setting PRESERVE_HOSTINFO=2, your instance will retain the hostname even after a reboot.

You can test by rebooting:

[root@omoicsso ~]# reboot

[root@omoicsso ~]# hostnamectl

Static hostname: omoicsso.oasiserp.com

Conclusion

Oracle Linux on OCI provides flexibility in hostname configuration — but only when you know where to look. Setting PRESERVE_HOSTINFO=2 ensures that your manual hostname configuration stays intact, avoiding surprises after restarts.

This is particularly useful in environments where:

• Hostnames are used for licensing, monitoring, or DNS registration.

• Manual management of infrastructure is part of your architecture.

How to Create and Manage LVM  Oracle Linux 8 on OCI

In enterprise Linux environments, Logical Volume Manager (LVM) provides flexibility in managing disk space by allowing dynamic resizing and better abstraction of physical storage devices.

In this post, we'll walk through adding a new disk, creating a volume group (VG), and then creating a logical volume (LV) on an Oracle Linux 8 server, specifically in an OCI (Oracle Cloud Infrastructure) environment.

Senerio

We want to:

1. Initialize a new disk (/dev/sdb) for use with LVM.

2. Create a new volume group vg_data.

3. Create a logical volume lv_data with 350 GB of space.

Step 1: Create a Physical Volume (PV)

Before we can use a new disk with LVM, it must be initialized as a Physical Volume.

 [root@omoicsso opc]# pvcreate /dev/sdb

  Physical volume "/dev/sdb" successfully created.

/dev/Sdb is the hardware partition created in the OCI console as the block volume and assigned to the Linux server. It is raw storage from the OCI

[root@omoicsso opc]# pvs

  PV         VG        Fmt  Attr PSize   PFree

  /dev/sda3  ocivolume lvm2 a--   45.47g      0

  /dev/sdb             lvm2 ---  400.00g 400.00g

PVS lists all the physical volumes that are associated with this server 

Step 2: Create a Volume Group (VG)

Next, we group one or more physical volumes into a Volume Group:

[root@omoicsso opc]# vgcreate vg_data /dev/sdb

  Volume group "vg_data" successfully created

We had created the   volume group in the physical volume as vg_data -- it can be any name 

[root@omoicsso opc]# vgdisplay

  --- Volume group ---

  VG Name               vg_data

  System ID

  Format                lvm2

  Metadata Areas        1

  Metadata Sequence No  1

  VG Access             read/write

  VG Status             resizable

  MAX LV                0

  Cur LV                0

  Open LV               0

  Max PV                0

  Cur PV                1

  Act PV                1

  VG Size               <400.00 GiB

  PE Size               4.00 MiB

  Total PE              102399

  Alloc PE / Size       0 / 0

  Free  PE / Size       102399 / <400.00 GiB

  VG UUID               iWc996-XIO2-M3WL-oFxr-1LtR-ndXf-KxM0bL

  --- Volume group ---

  VG Name               ocivolume

  System ID

  Format                lvm2

  Metadata Areas        1

  Metadata Sequence No  23

  VG Access             read/write

  VG Status             resizable

  MAX LV                0

  Cur LV                2

  Open LV               2

  Max PV                0

  Cur PV                1

  Act PV                1

  VG Size               45.47 GiB

  PE Size               4.00 MiB

  Total PE              11641

  Alloc PE / Size       11641 / 45.47 GiB

  Free  PE / Size       0 / 0

  VG UUID               Hu90og-5IAx-0g5d-Q272-rmZL-L5fw-Z4R7lw

Here we have two volume groups,, so two groups have been displayed 

Step 3: Create a Logical Volume (LV)

Now, we need to created  a Logical Volume of 350 GB from vg_data:

[root@omoicsso opc]#  lvcreate -n lv_data -L 350G vg_data

  Logical volume "lv_data" created.

Once the volume group is created with the required size, you can format the logical volume using your preferred file system, such as XFS or ext4, and then mount it on the Linux system.

[root@omoicsso opc]# lvdisplay

  --- Logical volume ---

  LV Path                /dev/vg_data/lv_data

  LV Name                lv_data

  VG Name                vg_data

  LV UUID                mkJZtP-E5k6-vsmN-4lNf-9Qcg-DrIl-U5bKhe

  LV Write Access        read/write

  LV Creation host, time omoicsso, 2023-05-11 11:57:00 +0000

  LV Status              available

  # open                 0

  LV Size                350.00 GiB

  Current LE             89600

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     4096

  Block device           252:2

  --- Logical volume ---

  LV Path                /dev/ocivolume/oled

  LV Name                oled

  VG Name                ocivolume

  LV UUID                nLXc2g-VyUO-dcUo-u1R1-HFOA-znRZ-PYAeBu

  LV Write Access        read/write

  LV Creation host, time localhost.localdomain, 2023-01-17 19:39:46 +0000

  LV Status              available

  # open                 1

  LV Size                10.00 GiB

  Current LE             2560

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     4096

  Block device           252:1

  --- Logical volume ---

  LV Path                /dev/ocivolume/root

  LV Name                root

  VG Name                ocivolume

  LV UUID                0MG24k-y6uq-CJo6-75bH-Qfak-Glvd-U2E9YK

  LV Write Access        read/write

  LV Creation host, time localhost.localdomain, 2023-01-17 19:39:47 +0000

  LV Status              available

  # open                 1

  LV Size                35.47 GiB

  Current LE             9081

  Segments               1

  Allocation             inherit

  Read ahead sectors     auto

  - currently set to     4096

  Block device           252:0

We have three LVs, so the lvdisplay command displays all the LV in the server 

[root@omoicsso opc]#

At this point:

• /dev/sdb is being used as an LVM physical volume.

• You've grouped it into a volume group called vg_data.

• A 350 GB logical volume (lv_data) is ready for formatting and mounting.

Create the file system 

mkfs.xfs /dev/vg_data/lv_data

Create A directory and Mount the lv 

mkdir /data

mount /dev/vg_data/lv_data /data

And optionally, add it to /etc/fstab for persistent mounting.

 Conclusion

Using LVM makes your Linux server storage much more flexible, especially in cloud environments like OCI where disks can be resized or replaced frequently. You can simplify expansion, backups, and migration by structuring your storage into volume groups and logical volumes.

Stay tuned for future posts on resizing volumes and taking LVM snapshots!