Prezzi del servizio di backup e RE
Questo documento illustra i dettagli dei prezzi per backup e RE su Cloud.
Panoramica
Il servizio di backup e RE offre un modello di fatturazione basato sul consumo e la fatturazione si basa sui seguenti componenti:
Addebito per spazio di archiviazione di backup. La quantità di spazio di archiviazione utilizzato per le immagini di backup.
Addebito per utilizzo backup. La quantità di utilizzo per l'orchestrazione e la gestione dei backup.
Addebito per spazio di archiviazione di backup
Il servizio di backup e RE consente agli utenti di sfruttare la ricchezza delle offerte Cloud Storage per allinearsi meglio all'archiviazione di backup alla criticità aziendale del carico di lavoro protetto.
Il servizio di backup e RE supporta tipi di disco permanente, archiviazione standard, Nearline Storage, Coldline Storage e Archive Storage. Paghi per la quantità di spazio di archiviazione consumata dalle immagini di backup in ogni tipo. Per ulteriori dettagli sui prezzi di Cloud Storage, consulta Prezzi di Cloud Storage.
Addebito dell'appliance di backup/ripristino
L'appliance di backup/ripristino viene eseguita su una VM di un'istanza Compute in esecuzione in un progetto selezionato dal cliente e si applicano i costi standard per le istanze di Compute Engine. Il servizio di backup e RE supporta i tipi di macchine Compute Engine elencati in Configurare e pianificare il deployment di un servizio di backup e RE.
Addebito per utilizzo backup
Ogni progetto in Google Cloud ha un account di fatturazione che viene utilizzato per definire chi paga l'utilizzo delle risorse e delle API Google Cloud nel progetto. Quando il servizio di backup e RE viene attivato in un progetto, qualsiasi utilizzo dei quattro SKU descritti di seguito verrà fatturato a quel progetto. Questo avviene indipendentemente dalle zone o dai progetti in cui si trovano le appliance di backup/ripristino.
Nella tabella seguente sono elencati gli SKU e i prezzi consigliati quando utilizzi backup e RE.
Prodotti / SKU - Backup | Modello di determinazione del prezzo | Meter | Prezzo di listino |
---|---|---|---|
Dati delle VM: VM di Compute Engine, VM on-premise, file system | In base all'utilizzo | Per GiB/mese di capacità di origine (front-end) coperta | 0,03 $ per GiB al mese |
SAP HANA, Oracle, SAP ASE, SAP IQ, SAP MaxDB, IBM Db2 | In base all'utilizzo | Per GiB/mese di capacità di origine (front-end) coperta | 0,24 $ per GiB al mese |
Microsoft SQL Server, MySQL, PostgreSQL, MongoDB, MariaDB | In base all'utilizzo | Per GiB/mese di capacità di origine (front-end) coperta | 0,09 $ per GiB al mese |
Copie virtuali (gestione dei dati di test) | In base all'utilizzo | Per GiB/mese di capacità clonata virtuale totale | 0,03 $ per GiB al mese |
1 Sono inclusi gli scenari in cui vengono utilizzati montaggi virtuali per i test e/o i ripristini dei backup.
I prezzi per il backup di Google Cloud VMware Engine si basano sul consumo e sulla durata dell'impegno; le opzioni includono sconti per impegno di utilizzo o on demand per periodi di uno o tre anni.
Nella tabella seguente sono elencati gli SKU e i prezzi consigliati per la protezione dei nodi ve1-standard-72 e dei nodi di solo archiviazione di Google Cloud VMware Engine.
Prodotti / SKU - Backup | Modello di determinazione del prezzo | Meter | Regione | Località | Prezzo di listino (on demand) | Impegno di 1 anno (pagamenti mensili in $) | Impegno di 1 anno (pagamento anticipato in $) | Impegno di 3 anni (pagamenti mensili in $) | Impegno di 3 anni (pagamento anticipato in $) |
---|---|---|---|---|---|---|---|---|---|
Dati VM: Google Cloud VMware Engine | Basato su nodi | all'ora per nodo | asia-northeast1 | Tokyo | 0,53 $ | 0,40 $ | 0,37 $ | $ 0,30 | $ 0,27 |
Basato su nodi | all'ora per nodo | asia-south1 | Mumbai | 0,51 $ | $ 0,39 | $ 0,36 | $ 0,29 | $ 0,26 | |
Basato su nodi | all'ora per nodo | asia-southeast1 | Singapore | 0,51 $ | $ 0,39 | $ 0,36 | $ 0,29 | $ 0,26 | |
Basato su nodi | all'ora per nodo | australia-southeast1 | Sydney | 0,51 $ | $ 0,39 | $ 0,36 | $ 0,29 | $ 0,26 | |
Basato su nodi | all'ora per nodo | europe-west2 | Londra | 0,53 $ | 0,40 $ | 0,37 $ | 0,31 $ | $ 0,27 | |
Basato su nodi | all'ora per nodo | europe-west3 | Francoforte | 0,53 $ | 0,40 $ | 0,37 $ | 0,31 $ | $ 0,27 | |
Basato su nodi | all'ora per nodo | europe-west4 | Paesi Bassi | 0,53 $ | 0,40 $ | 0,37 $ | 0,31 $ | $ 0,27 | |
Basato su nodi | all'ora per nodo | europe-west6 | Zurigo | 0,58 $ | $ 0,44 | 0,40 $ | $ 0,33 | $ 0,29 | |
Basato su nodi | all'ora per nodo | Europa-west8 | Milano | $ 0,54 | 0,41 $ | 0,38 $ | 0,31 $ | $ 0,27 | |
Basato su nodi | all'ora per nodo | northamerica-northeast1 | Montreal, Qubec, Nord America | 0,51 $ | $ 0,39 | $ 0,36 | $ 0,29 | $ 0,26 | |
Basato su nodi | all'ora per nodo | northamerica-northeast2 | Toronto, Ontario, Nord America | 0,51 $ | $ 0,39 | $ 0,36 | $ 0,29 | $ 0,26 | |
Basato su nodi | all'ora per nodo | southamerica-east1 | San Paolo | 0,66 $ | 0,50 $ | 0,46 $ | 0,38 $ | $ 0,33 | |
Basato su nodi | all'ora per nodo | us-central1 | Council Buffs, Iowa, Nord America | 0,46 $ | $ 0,35 | $ 0,33 | $ 0,27 | 0,23 $ | |
Basato su nodi | all'ora per nodo | us-east4 | (Ashburn) | 0,46 $ | $ 0,35 | $ 0,33 | $ 0,27 | 0,23 $ | |
Basato su nodi | all'ora per nodo | us-west2 | Los Angeles | 0,50 $ | 0,38 $ | $ 0,35 | $ 0,29 | 0,25 $ | |
Basato su nodi | all'ora per nodo | southamerica-west1 | Santiago | 0,64 $ | $ 0,48 | $ 0,45 | 0,37 $ | 0,32 $ | |
Basato su nodi | all'ora per nodo | asia-south2 | Delhi | 0,51 $ | $ 0,39 | $ 0,36 | $ 0,29 | $ 0,26 | |
Basato su nodi | all'ora per nodo | me-ovest-1 | Tel Aviv | 0,51 $ | $ 0,39 | $ 0,36 | $ 0,29 | $ 0,26 | |
Basato su nodi | all'ora per nodo | Europa-west-12 | Torino | $ 0,54 | 0,41 $ | 0,38 $ | 0,31 $ | $ 0,27 |
Come viene misurato l'utilizzo di backup ed RE?
Backup e RE misura l'utilizzo in base alle dimensioni effettive del carico di lavoro al frontend o alle dimensioni del carico di lavoro che sta gestendo. L'unità di misura è gibibyte (GiB). Un gibibyte = 1024 * 1024 * 1024 byte.
Se il carico di lavoro in gestione riporta la dimensione del volume dei dati, backup e RE tengono conto della dimensione del volume segnalata (ad esempio, il calcolo dell'utilizzo per VMware sarà coerente con le dimensioni della VM segnalate in vCenter).
Se gestisci 10 TiB di dati Oracle distribuiti in più database, l'utilizzo dei dati per backup e RE è pari a 10 * 1024 GiB di utilizzo dei dati.
Misurazione dell'utilizzo per Compute Engine senza agente
Backup e RE misura l'utilizzo per il backup delle VM di Compute Engine in base alla quantità di spazio di archiviazione DP collegato a una VM di Compute Engine al momento del backup. Backup e RE consentono di escludere i volumi DP dal backup. In questi casi, per misurare l'utilizzo vengono utilizzati solo i volumi identificati di cui eseguire il backup.
Ad esempio, se due volumi DP di un TiB e due TiB sono collegati a una VM di Compute Engine e configuri l'SLT di backup in modo da escludere il volume da 2 TiB, l'utilizzo della VM sarà misurato in un TiB.
Inoltre, se la VM da 1 TiB aumenta o si riduce, backup e RE misurano l'utilizzo in base alle dimensioni del volume al momento dell'ultimo backup.
Misurazione dell'utilizzo per Google Cloud VMware Engine senza agente
Il prezzo per Google Cloud VMware Engine è calcolato in base ai nodi ve1 di Google Cloud VMware Engine e al nodo di solo archiviazione di Google Cloud VMware Engine ve1.
Per il nodo ve1 di Google Cloud VMware Engine
I prezzi vengono calcolati in base al numero di nodi ESXi protetti. Un nodo ESXi è considerato protetto se una o più VM associate sono protette dal servizio di backup e RE.
Di seguito è riportato un esempio che dimostra il processo di fatturazione per Google Cloud VMware Engine:
Prezzo per il backup di un singolo nodo Google Cloud VMware Engine (solo backup delle VM) nella regione us-central1 per un mese =
(Prezzo di listino per il backup del nodo/ ora) X (Numero di ore in un nodo giorno attivo) X (Numero di giorni in un mese).
Considerando che il nodo Google Cloud VMware Engine è attivo per 24 ore, ci sono 30 giorni in un mese e il prezzo per il backup di un nodo sarà 0, 46 $x 24 x 30 = 331$.
I prezzi riguardano solo la protezione di Google Cloud VMware Engine, i backup di intere VM. Non include gli addebiti per la gestione dei backup per backup basati su agente, ad esempio per backup coerenti con l'applicazione per SAP HANA, SQL Server, MySQL, Postgres, agenti file system e così via. Per stimare gli addebiti per i backup basati su agente, consulta Misurazione dell'utilizzo per il backup basato su agente.
Per nodo di solo archiviazione ve1 di Google Cloud VMware Engine
I prezzi per la protezione di un nodo di solo archiviazione di Google Cloud VMware Engine ve1 sono determinati dal numero di nodi di solo archiviazione di Google Cloud VMware Engine ve1 aggiunti a un cluster con almeno uno o più nodi protetti da ve1 di Google Cloud VMware Engine.
Se hai un cluster con nodi di solo archiviazione di Google Cloud VMware Engine ve1 e aggiungi nodi di solo archiviazione di Google Cloud VMware Engine ve1 allo stesso cluster, tutti i nodi di solo archiviazione nel cluster saranno considerati protetti per impostazione predefinita e ti sarà addebitata la protezione di tutti. Non puoi escludere la protezione per i nodi di solo archiviazione di Google Cloud VMware Engine ve1 in un cluster che ha almeno uno o più nodi protetti da Google Cloud VMware Engine ve1.
Ad esempio, supponiamo di avere un cluster esistente di 20 nodi di cui stai proteggendo 10 utilizzando il servizio di backup e RE. Se aggiungi al cluster tre nodi di solo archiviazione, tutti e tre i nodi di solo archiviazione verranno considerati protetti e ti verrà addebitato un costo per la protezione di 10 + 3 = 13 nodi ve1 di Google Cloud VMware Engine.
Se non proteggi alcun nodo ve1 di Google Cloud VMware Engine su un cluster, i nodi di solo archiviazione di Google Cloud VMware Engine v1 non possono essere protetti in questo caso.
Misurazione dell'utilizzo per il backup basato su agente
Backup e RE misura l'utilizzo per il backup basato su agente in base alle dimensioni effettive del carico di lavoro. Ad esempio, se il backup di un database SQL Server utilizza l'agente di backup e RE e se la somma dei file di dati di un server SQL è di 5 TiB su un volume di 7 TiB, l'utilizzo viene misurato come 5 TiB.
Misurazione dell'utilizzo per il backup dei database basato su agente
Per i carichi di lavoro Oracle e SQL Server, solo i database protetti vengono conteggiati ai fini dell'utilizzo. Non prende in considerazione i file di log:
- Oracle. La dimensione allocata dei file di database protetti viene conteggiata ai fini dell'utilizzo. Le dimensioni allocate includono file di dati e file di controllo.
- Microsoft SQL Server. Le dimensioni totali di tutti i file di database, inclusi i file .MDF, .LDF e .NDF protetti, vengono conteggiate ai fini dell'utilizzo.
Protezione del database con il Change Block Tracking (CBT) di Linux. Backup e RE supportano il backup efficiente di diversi database con il monitoraggio dei blocchi delle modifiche. Questa modalità di backup si basa sul log del database e sui file di dati per risiedere sui volumi gestiti LVM (Logical Volume Manager). Per questa classe di carichi di lavoro, l'utilizzo viene misurato come dimensione effettiva utilizzata del database sotto protezione, utilizzando le seguenti query:
Db2: chiama get_dbsize_info(?,?,?,-1);
MariaDB: SELECT SUM(data_length + index_length) FROM information_schema.TABLES where table_schema='
'; MySQL: SELECT SUM(data_length + index_length) FROM information_schema.TABLES where table_schema='
'; PostgreSQL: SELECT pg_database_size('$db");
SAP ASE: sp_spaceused;
SAP IQ: sp_iqdbsize * block_size;
SAP HANA: seleziona somma(TOTAL_SIZE) da sys_databases.M_VOLUME_FILES dove file_type='DATA'
SAP MaxDB: dbmcli -d $DBSID $MAXDB_KEY informazioni DATA
Protezione basata sul dump SQL senza CBT di Linux. Backup e RE supportano i backup tradizionali basati su dump SQL. In questa modalità, l'utilizzo viene misurato come la dimensione del database riportata dal database al momento del backup.
Misurazione dell'utilizzo per le copie virtuali
Backup e RE misura l'utilizzo delle copie virtuali a partire dal momento in cui viene creata una copia virtuale di un carico di lavoro. La quantità di utilizzo si basa sulle dimensioni dell'applicazione al momento dell'ultimo backup. Man mano che vengono eseguiti nuovi backup, la quantità di utilizzo viene aggiornata in base alle dimensioni attuali dell'applicazione. Il modo più comune per creare copie virtuali è con i job di montaggio. Esistono anche altri tipi di job, come prep-mount e riprovisioning, che possono creare una copia virtuale. I costi di utilizzo vengono ripartiti proporzionalmente in base al tempo di utilizzo della copia virtuale (dal momento dell'installazione successo a quello dello smontaggio, misurato in incrementi di 1 ora).
Considera l'esempio di un database SQL Server di 500 GiB. I backup di questo database comportano un addebito di utilizzo dei backup di 500 GiB. Inoltre, tieni presente che a mezzogiorno del primo giorno del mese viene eseguito il provisioning di una copia virtuale di questo database a partire dal backup più recente. Il 10 del mese il database di origine si riduce a 400 GiB. Il 20 del mese, la copia virtuale viene smontata dal server di test alle 11:00. In questo scenario, viene addebitato un addebito per l'utilizzo di una copia virtuale di 500 GiB per 12 ore il primo giorno e 24 ore al giorno tutti i giorni dal secondo all'ora del backup il 10. L'addebito per l'utilizzo delle copie virtuali passa a 400 GiB il 10 (al momento del backup) e continua fino al 20 del mese. L'utilizzo della copia virtuale per il giorno 20 verrà conteggiato solo per 11 ore e non per l'intera giornata. L'importo di utilizzo non cambia con i dati aggiuntivi scritti nella copia virtuale.
Fattori che influenzano la misurazione dell'utilizzo
Fattori che influenzano la misurazione dell'utilizzo in scenari fuori banda:
- Volumi compressi. Se la compressione è abilitata, l'utilizzo conteggia i valori post-compressione. Ad esempio, se un volume a due TiB ha 2,5 TiB di dati compressi in 1,8 TiB, il conteggio di utilizzo sarà 1,8 TiB e non 2,5 TiB.
- Volumi ottimizzati per Windows. Per i volumi ottimizzati di Windows, Backup e RE reidrata il volume per il backup e il numero di utilizzo corrisponderà al valore di reidratazione. Ad esempio, se un volume ottimizzato per Windows da un TiB contiene 800 GiB di dati, quando reidratato per il backup risulta di 1,1 TiB, l'utilizzo è di 1,1 TiB.
- Dimensioni blocco. Per i dischi temporanei, backup e RE misurano l'utilizzo in base alla dimensione del blocco del disco gestione temporanea. Se la dimensione del blocco del volume di origine e quella del disco gestione temporanea corrispondono, i valori di utilizzo corrisponderanno esattamente al volume di origine. Se la dimensione del blocco utilizzata sul disco di gestione temporanea è diversa da quella del volume di origine, ci sarà una piccola differenza perché il calcolo dell'utilizzo viene eseguito sul disco di gestione temporanea.
- Gruppi di coerenza. Il conteggio di utilizzo per un gruppo di coerenza è la somma di tutte le dimensioni dei carichi di lavoro nel gruppo di coerenza. I carichi di lavoro vengono misurati singolarmente e sommati.
Passaggi successivi
Per qualsiasi domanda relativa ai prezzi, consulta le Domande frequenti.