An Azure backup service that provides built-in management at scale.
For your scenario, I would separate db recovery, long-term retention, and business-data archiving because they solve different problems.
The key point is that a BACPAC is useful as an independent copy of your database, but it should not be viewed as a replacement for Azure SQL Database's built-in backup and recovery capabilities. Microsoft specifically states that BACPAC files are intended for portability, migration and archiving scenarios, not backup-and-restore operations.
1. Can I take a complete local copy of an Azure SQL Database?
Yes.
The most common approach is to export the database as a BACPAC file.
A BACPAC contains:
- Database schema
- Table data
- Metadata required to recreate the database during import
It can later be imported into Azure SQL Database, Azure SQL Managed Instance, or SQL Server.
A useful point to understand is that Azure SQL Database does not expose its internal automatic backup files for download. If you want a customer-controlled copy outside Azure's managed backup system, a BACPAC export is the standard option.
2. What should I use for long-term recovery?
If your concern is recovering data months or years later, consider enabling Long-Term Retention (LTR) in addition to keeping independent exports.
LTR stores selected automated backups for up to 10 years and allows those backups to be restored as a new database. Azure SQL Database also supports immutable LTR backups for additional protection against accidental or malicious deletion.
Therefore:
- PITR (Point-in-Time Restore) = short-term operational recovery
- LTR = long-term Azure-managed recovery
- BACPAC = independent archive/export copy
3. How do I create the independent copy?
Using Azure Portal:
Azure Portal → SQL Databases → Select Database → Export
You will be prompted for:
- Storage account
- Storage container
- Authentication details
The export creates a .bacpac file in Azure Storage, which can then be downloaded and stored on company-controlled storage.
One recommendation: periodically import an archived BACPAC into a test database to confirm it can still be successfully restored.
4. What about Excel or CSV exports?
This is a separate requirement from database backup.
A BACPAC is intended for database reconstruction, not business review.
For finance, audit, or compliance purposes, it is often better to export important business tables separately, such as:
- Customer master
- Vendor master
- Product master
- Chart of accounts
- Sales transactions
- Purchase transactions
- Inventory
- Invoices
- Payments
For large datasets, CSV is generally more practical than Excel because Excel has row limits and can become difficult to manage.
5. What costs are involved?
There is no separate "BACPAC licence fee".
Typical costs are:
- Azure Storage used to hold the exported BACPAC
- Storage used for any CSV exports
- Any local storage where copies are retained
- Potential network transfer costs depending on how the files are downloaded and stored
The export operation itself also consumes database resources while it runs.
6. Practical approach
A common pattern is:
- Azure SQL automatic backups for day-to-day recovery
- LTR for longer retention requirements
- Periodic BACPAC exports for an independent customer-controlled archive
- CSV exports of key business tables for finance and audit review
- Periodic restore testing to validate archived copies
If the database becomes large, Microsoft recommends using SqlPackage rather than relying solely on portal-based export operations.
Bottom line: Use Azure SQL's built-in backup capabilities (PITR and, where required, LTR) for recovery, and use BACPAC exports plus selected CSV exports as your independent archive strategy. Do not treat BACPAC as a substitute for Azure SQL's native backup system.
Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.