Types
| Type of Account | Services Supported | Types of Blobs supported |
|---|---|---|
| General Purpose Standard | Blob, File, Queue services | Block blobs, Page blobs and Append blobs |
| General Purpose Premium | Blob service | Page blobs |
| Blob Storage (hot and cool access tiers) | Blob service | Block blobs and Append blobs |
| Setting | Individual blobs and their properties can be accessed | Blobs can be enumerated |
|---|---|---|
| Container | ✔️ | ✔️ |
| Blob | ✔️ | ❌ |
| Off | ❌ | ❌ |
https://[account].blob.core.windows.net/pictures/profile.jpg?sv=2012-02-12&st=2009-02-09&se=2009-02-10&sr=c&sp=r&si=YWJjZGVmZw%3d%3d&sig=dD80ihBh5jfNpymO5Hg1IdiJIEvHcJpCMiCMnN%2fRnbI%3d
Provides read-only access to primary location on top of GRS.
| Replication | LRS | ZRS | GRS | RA-GRS |
|---|---|---|---|---|
| Data stored in multiple datacenters | No | Yes | Yes | Yes |
| Data read from secondary & primary location | No | No | No | Yes |
| No of copies of data stored in separate nodes | 3 | 3 | 6 | 6 |
Features:
| Disk Type | Description | 💡 Suggested Use |
|---|---|---|
| Azure Files | SMB 3.0 interface, client libraries and a REST interface access from anywhere to stored files. | Application lift and shift using native file system API, Windows File Shares. |
| Azure Blobs | Client libraries, REST interface, for unstructured data stored in Block blobs | Streaming and random access, access application data from anywhere. |
| Azure Disks | Client libraries, REST interface for persistent data accessed from a VHD, | Access to data inside a Virtual machine on a VHD, lift and shift file system API apps that write to persistent disks. |
Sizing and pricing
| Type | Allowed disks | Pricing |
|---|---|---|
| Premium | P4 (32 GB) -> P50 (4 TB) | Pay for allocated size without transaction charges |
| Standard | S4 (32 GB) -> S5 (4 TB) | Billed only for the number of transactions performed |
sudo mounthttps://[account].file.core.windows.net/<share>/<directory/directories>/
http://[account].file.core.windows.net/logs/CustomLogs/Log1.txtGracePeriodWithDataLossHours, you can control how long the system waits before initiating the failover that is likely to result data loss.http://<storage account>.table.core.windows.net/<table>PartitionKey & RowKey properties
null values are not.Azure Site Recovery is used to replicate the configuration and data of a system to another datacenter, then you would use.
| Concept | Explanation | Backup | Disaster Recovery (DR) |
|---|---|---|---|
| Recovery point objective (RPO) | The amount of acceptable data loss if a recovery needs to be done. | Wide variability in their acceptable RPO. E.g. VM backups usually 1 day, DB backups 15 minutes. | Low RPOs. The DR copy can be behind by a few seconds or a few minutes. |
| Recovery time objective (RTO) | The amount of time that it takes to complete a recovery or restore. | Larger RPO -> the amount of data needed to process is much higher -> leads to longer RTOs. E.g. days to restore data from tapes, depending on the time it takes to transport the tape from an off-site location. | Smaller RTOs because they are more in sync with the source. Fewer changes need to be processed. |
| Retention | How long data needs to be stored | For scenarios that require operational recovery (e.g. data corruption, inadvertent file deletion, OS failure), backup data is typically retained for 30 days or less. 💡 From a compliance standpoint, data might need to be stored for months or even years. Backup data is ideally suited for archiving in such cases. | Needs only operational recovery data, which typically takes a few hours or up to a day. 💡 Because of the fine-grained data capture used in DR solutions, using DR data for long-term retention is not recommended. |
| Product | Use cases |
|---|---|
| Azure Backup | • Accidental deletion • Patch Testing • Alternative location recovery • Security • Long-term data retention |
| Azure Site Recovery | • Disaster Recovery with quick failover • Migration • Dev/Test Environment (e.g. test failover) |