Database backups are vital for disaster recovery and business continuity. As data grows, so do your backup files—making storage costs rise fast. What if you could shrink those files without losing any information? That’s where compressed backup sets come into play for Oracle databases. In this guide, we’ll break down what they are, why they matter, and how you can use them step by step.
What Is a Compressed Backup Set?
A compressed backup set is a special type of database backup where data gets reduced in size using built-in algorithms before being saved to disk or tape. In Oracle environments, this happens at the block level through Recovery Manager (RMAN) when you use the AS COMPRESSED BACKUPSET option.
Block-level compression means only actual database blocks get processed—empty space isn’t stored—so it’s much more efficient than simply zipping up files after the fact (Oracle Documentation). When you restore from these backups later on, RMAN automatically decompresses everything behind the scenes.
Compressed backup sets contain all your critical data but take up less space than regular backups or image copies. This makes them ideal for large databases or environments with limited storage capacity.
Why Use Compressed Backup Sets?
Using compressed backup sets helps save valuable disk space and reduces network load during transfers—a big win if you’re working with tight storage budgets or slow connections.
Compression can shrink your backups by 20% to 80%, depending on your data mix. However, there’s a trade-off: compressing data uses more CPU power during the creation of each backup set because every block must be analyzed and reduced before writing to disk.
The extra CPU load mostly affects the backup process itself; restores usually see less impact since decompression is faster than compression. For most organizations, these savings far outweigh any temporary increase in processor usage—especially when storage costs are high or when you need to move backups offsite quickly.
Method 1: Creating Compressed Backups Manually (File-Level Compression)
While “backup as compressed backupset” refers specifically to Oracle RMAN’s built-in feature, sometimes you may need to compress exported database dumps or other files outside of RMAN—for example, when handling logical exports or image copies.
In these cases, manual file-level compression tools like tar/gzip on Linux or WinRAR/7-Zip on Windows come in handy:
First create your uncompressed database dump or file-based copy using standard export tools or OS commands. Then compress those files:
On Linux:
tar -cvf mydb_backup.tar /path/to/backup/files
gzip mydb_backup.tar
This produces a single archive named mydb_backup.tar.gz containing all selected files in compressed form.
On Windows:
Right-click your folder of exported files > choose Add to archive... > select ZIP format with maximum compression enabled.
Manual file-level compression works well for moving large exports between servers or archiving old backups that don’t need frequent restores. However, it lacks database-awareness: there’s no block-level optimization nor integration with Oracle catalogs.
Tip: Always verify integrity after manually compressing important database files by generating checksums before and after decompression—this ensures nothing was lost during transfer or extraction.
Remember: Manual methods do not replace RMAN’s optimized approach but can supplement it for certain scenarios like logical exports or copying archived image copies between systems.
Method 2: Creating Compressed Backup Sets Using Built-in System Tools (Oracle RMAN)
For true Oracle-native protection—and full catalog integration—you should use RMAN’s built-in ability to create compressed backup sets directly from live databases.
Start by connecting to your target system:
rman target /
To back up an entire database as a compressed set:
BACKUP AS COMPRESSED BACKUPSET DATABASE;
Want archived logs included? Run:
BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG;
You can also back up specific tablespaces:
BACKUP AS COMPRESSED BACKUPSET TABLESPACE users;
Or individual datafiles:
BACKUP AS COMPRESSED BACKUPSET DATAFILE 4;
If you want every future disk-based backup set created with compression by default:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
To revert this setting later:
CONFIGURE DEVICE TYPE DISK BACKUP TYPE CLEAR;
Specifying Compression Algorithms
RMAN supports several levels of compression algorithms: BASIC (default), LOW, MEDIUM, HIGH (Oracle Documentation). The syntax looks like this:
BACKUP AS COMPRESSED BACKUPSET DATABASE COMPRESSION ALGORITHM 'HIGH';
BASIC uses standard ZLIB routines; available without extra licensing.
LOW, MEDIUM, and HIGH offer different balances between speed and space savings but may require an Advanced Compression Option license (check your Oracle agreement).
Choose an algorithm based on your needs: HIGH gives maximum reduction but uses more CPU; LOW is faster but saves less space; BASIC strikes a balance suitable for most workloads.
Validating and Listing Compressed Backups
After running backups with compression enabled, always confirm that they were created correctly:
Use this command inside RMAN:
LIST BACKUP SUMMARY;
Look at the “Compressed” column—it should say YES next to each relevant entry. For even deeper checks run queries against V$BACKUP_SET where COMPRESSED = 'YES'.
This quick review ensures that your policies are working as intended—and helps catch misconfigurations early before they cause problems during recovery testing!
Compressed backup sets provide strong protection while saving resources—but remember that higher levels of compression mean longer processing times during creation due to increased CPU demand.
How to Protect Oracle Database with Vinchin?
Beyond manual checks and scripts, organizations seeking robust enterprise-level protection should consider Vinchin Backup & Recovery—a professional solution supporting today’s leading databases including Oracle, MySQL, SQL Server, MariaDB, PostgreSQL, PostgresPro, and TiDB—with advanced features tailored especially well for Oracle environments. Among its capabilities are advanced source-side compression and incremental backup options designed specifically for Oracle workloads alongside batch database backup management, flexible GFS-based retention policies, and comprehensive integrity checks—all working together seamlessly so administrators maximize efficiency while ensuring reliable recoverability across complex infrastructures.
With Vinchin Backup & Recovery's intuitive web console interface protecting an Oracle database typically involves four straightforward steps:
Step 1 – Select the Oracle database to back up;
Step 2 – Choose the desired storage location;
Step 3 – Define custom strategies such as schedules or retention rules;
Step 4 – Submit the job.
Recognized globally among enterprise IT professionals—with thousands of satisfied customers worldwide—Vinchin Backup & Recovery consistently earns top industry ratings. Experience complete peace of mind risk-free with their 60-day full-featured free trial—just click download below!
Backup as Compressed Backupset FAQs
Q1: Can I restore a compressed backup set without extra steps?
A1: Yes—RMAN automatically decompresses during restore so no manual action is needed.
Q2: How do I check if my RMAN backup set used compression?
A2: Use LIST BACKUP SUMMARY inside RMAN—the “Compressed” column shows YES if applied—or query V$BACKUP_SET where COMPRESSED = 'YES'.
Q3: Can I automate scheduled compressed backups?
A3: Yes—use OS schedulers with scripted RMAN commands or leverage Vinchin's built-in job scheduler for automated runs.
Q4: Does RMAN support creating compressed image copies?
A4: No—as compressed backups only apply to “backupsets”; image copies remain uncompressed unless manually zipped afterward.
Conclusion
Compressed backup sets help save storage space while making disaster recovery easier—even across large Oracle deployments. Whether using native tools like RMAN or advanced solutions such as Vinchin (with its free trial), adopting smart data reduction strategies keeps operations lean without sacrificing safety.
