Ripristino di un'istanza RDS Custom per SQL Server in un determinato momento

Puoi ripristinare un'istanza database in un punto temporale specifico (PITR), creando una nuova istanza database. Per supportare il PITR, è necessario che nelle istanze database sia abilitata la conservazione dei backup.

L'ultimo orario ripristinabile di un'istanza database RDS Custom per SQL Server dipende da diversi fattori, ma generalmente è entro 5 minuti dall'orario attuale. Per determinare l'ultima ora di ripristino per un'istanza database, utilizza il comando AWS CLI describe-db-instances e verifica il valore restituito nel campo LatestRestorableTime per l'istanza database. Per visualizzare l'ora di ripristino più recente per ogni istanza del DB nella console Amazon RDS, scegliere Backup automatici.

Puoi eseguire il ripristino point-in-time durante il periodo di retention dei backup. Per visualizzare il tempo di ripristino più breve per ogni istanza del DB, scegliere Backup automatici nella console Amazon RDS.

Per informazioni generali su PITR, consulta Ripristino di un’istanza database a un punto temporale specifico per Amazon RDS.

Considerazioni PITR per RDS Custom per SQL Server

In RDS Custom per SQL Server, PITR differisce secondo le seguenti importanti modalità da PITR in Amazon RDS:

• PITR ripristina solo i database nell'istanza database. Non ripristina il sistema operativo o i file sull'unità C:.

• Per un'istanza DB RDS Custom per SQL Server, viene eseguito automaticamente il backup di un database ed è idoneo per PITR solo alle seguenti condizioni:

  • Il database è online.

  • Il suo modello di ripristino è impostato su FULL.

  • È scrivibile.

  • Ha i suoi file fisici sull'unità D:.

  • Non è elencato nella tabella rds_pitr_blocked_databases. Per ulteriori informazioni, consulta Rendere i database non idonei per PITR.

• I database idonei per il PITR sono determinati in base all’ordine del loro ID database. RDS Custom per SQL Server consente fino a 5.000 database per istanza database. Tuttavia, il numero massimo di database ripristinati da un’operazione PITR per un’istanza database RDS Custom per SQL Server dipende dal tipo di classe dell’istanza. Per ulteriori informazioni, consulta Numero di database idonei per il PITR per tipo di classe di istanza.

  Altri database che non fanno parte del PITR possono essere ripristinati dagli snapshot di database, inclusi i backup automatici utilizzati per il PITR.

• L'aggiunta di un nuovo database, la rinominazione di un database o il ripristino di un database idoneo per PITR avvia uno snapshot dell'istanza database.

• Il numero massimo di database idonei per PITR cambia quando l’istanza database viene sottoposta a un’operazione di calcolo del dimensionamento, a seconda del tipo di classe dell’istanza di destinazione. Se l’istanza viene aumentata verticalmente, consentendo così a più database sull’istanza di essere idonei per il PITR, viene acquisito un nuovo snapshot.

• I database ripristinati hanno lo stesso nome dell’istanza database di origine. Non puoi specificare un nome diverso.

• AWSRDSCustomSQLServerIamRolePolicy richiede l’accesso ad altri servizi AWS. Per ulteriori informazioni, consulta Aggiungi una politica di accesso a AWSRDSCustom SQLServer InstanceRole.

• Le modifiche al fuso orario non sono supportate per RDS Custom per SQL Server. Se si modifica il fuso orario dell’istanza database o del sistema operativo, PITR (o un’altra automazione) non funziona.

Numero di database idonei per il PITR per tipo di classe di istanza

La tabella seguente mostra il numero massimo di database idonei per PITR in base al tipo di classe di istanza.

Tipo di classe di istanza	Numero massimo di database idonei per il PITR
db.*.large	100
Da db.*.xlarge a db.*.2xlarge	150
Da db.*.4xlarge a db.*.8xlarge	300
Da db.*.12xlarge a db.*.16xlarge	600
db.*.24xlarge, db.*32xlarge	1000

* Rappresenta tipi di classi di istanza differenti.

Il numero massimo di database idonei per il PITR su un’istanza database dipende dal tipo di classe dell’istanza. Il numero varia da 100 nei tipi di classe di istanza più piccoli a 1000 in quelli più grandi supportati da RDS Custom per SQL Server. I database di sistema SQL Server (master, model, msdb, tempdb) non sono inclusi in questo limite. Quando un’istanza database viene aumentata o ridotta verticalmente, a seconda del tipo di classe dell’istanza di destinazione, RDS Custom aggiorna automaticamente il numero di database idonei per il PITR. RDS Custom per SQL Server invierà RDS-EVENT-0352 quando il numero massimo di database idonei per il PITR cambia su un’istanza database. Per ulteriori informazioni, consulta Eventi di versioni personalizzate del motore.

Nota

Il supporto PITR per più di 100 database è disponibile solo sulle istanze database create dopo il 26 agosto 2023. Per le istanze create prima del 26 agosto 2023, il numero massimo di database idonei per il PITR è 100, indipendentemente dalla classe di istanza. Per abilitare il supporto PITR per più di 100 database su istanze database create prima del 26 agosto 2023, puoi eseguire la seguente azione:

• Aggiorna la versione del motore di database a 15.00.4322.2.v1 o versioni successive

Durante un’operazione PITR, RDS Custom ripristinerà tutti i database che facevano parte di PITR sull’istanza database di origine al momento del ripristino. Una volta che l’istanza database di destinazione ha completato le operazioni di ripristino, se la conservazione dei backup è abilitata, l’istanza database inizierà il backup in base al numero massimo di database idonei per il PITR sull’istanza database di destinazione.

Ad esempio, se l’istanza database viene eseguita su un’istanza db.*.xlarge con 200 database:

1. RDS Custom per SQL Server sceglierà i primi 150 database, ordinati in base all’ID database, per il backup PITR.

2. Tu modifichi l’istanza aumentandola verticalmente fino a db.*.4xlarge.

3. Al termine dell’operazione di calcolo del dimensionamento, RDS Custom per SQL Server sceglierà i primi 300 database, ordinati in base all’ID database, per il backup PITR. Ciascuno dei 200 database che soddisfano i requisiti PITR sarà ora idoneo per il PITR.

4. A questo punto modifichi l’istanza riducendola verticalmente a db.*.xlarge.

5. Al termine dell’operazione di calcolo del dimensionamento, RDS Custom per SQL Server selezionerà nuovamente i primi 150 database, ordinati in base all’ID database, per il backup PITR.

Rendere i database non idonei per PITR

Puoi decidere di escludere singoli database dal PITR. Per fare questo, metti i loro valori database_id in una tabella rds_pitr_blocked_databases. Utilizza il seguente script SQL per creare la tabella.

Per creare la tabella rds_pitr_blocked_databases

• Esegui il seguente script SQL.

  create table msdb..rds_pitr_blocked_databases
  (
  database_id INT NOT NULL,
  database_name SYSNAME NOT NULL,
  db_entry_updated_date datetime NOT NULL DEFAULT GETDATE(),
  db_entry_updated_by SYSNAME NOT NULL DEFAULT CURRENT_USER,
  PRIMARY KEY (database_id)
  );
  

Per l'elenco dei database idonei e non idonei, consulta il file RI.End nella directory RDSCustomForSQLServer/Instances/DB_instance_resource_ID/TransactionLogMetadata nel bucket Amazon S3 do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier. Per ulteriori informazioni sul file RI.End, consulta Log sulle transazioni in Amazon S3.

Puoi anche definire l’elenco dei database idonei per il PITR utilizzando il seguente script SQL. Imposta la variabile @limit sul numero massimo di database idonei per il PITR per la classe di istanza. Per ulteriori informazioni, consulta Numero di database idonei per il PITR per tipo di classe di istanza.

Per definire l’elenco dei database idonei per il PITR su una classe di istanza database

• Esegui il seguente script SQL.

  DECLARE @Limit INT;
  SET @Limit = (insert-database-instance-limit-here);
  
  USE msdb;
  IF (EXISTS (SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'dbo' AND  TABLE_NAME = 'rds_pitr_blocked_databases'))
      WITH TABLE0 AS (
          SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable
          FROM sys.dm_hadr_database_replica_states hdrs
          INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id
          WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0) 
          OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY')
      ),
      TABLE1 as (
              SELECT dbs.database_id as DatabaseId, sysdbs.name as DatabaseName, 'OPTOUT' as Reason,
              CASE WHEN dbs.database_name = sysdbs.name THEN NULL ELSE dbs.database_name END AS DatabaseNameOnPitrTable
              FROM msdb.dbo.rds_pitr_blocked_databases dbs
              INNER JOIN sys.databases sysdbs ON dbs.database_id = sysdbs.database_id
              WHERE sysdbs.database_id > 4
              ),
      TABLE2 as (
              SELECT
              db.name AS DatabaseName,
              db.create_date AS CreateDate,
              db.state_desc AS DatabaseState,
              db.database_id AS DatabaseId,
              rs.database_guid AS DatabaseGuid,
              rs.last_log_backup_lsn AS LastLogBackupLSN,
              rs.recovery_fork_guid RecoveryForkGuid,
              rs.first_recovery_fork_guid AS FirstRecoveryForkGuid,
              db.recovery_model_desc AS RecoveryModel,
              db.is_auto_close_on AS IsAutoClose,
              db.is_read_only as IsReadOnly,
              NEWID() as FileName,
              CASE WHEN(db.state_desc = 'ONLINE'
                      AND db.recovery_model_desc != 'SIMPLE' 
                      AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1)) 
                      AND db.is_read_only != 1
                      AND db.user_access = 0
                      AND db.source_database_id IS NULL
                      AND db.is_in_standby != 1
                      THEN 1 ELSE 0 END AS IsPartOfSnapshot,
              CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot
              FROM sys.databases db
              INNER JOIN sys.database_recovery_status rs
              ON db.database_id = rs.database_id
              WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND
              db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE1) AND
              db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0)
          ),
          TABLE3 as(
              Select @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE2 where TABLE2.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb')
          )
          SELECT TOP(SELECT TotalNumberOfDatabases from TABLE3)  DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE2 where TABLE2.IsPartOfSnapshot=1
          ORDER BY TABLE2.DatabaseID ASC
  ELSE
      WITH TABLE0 AS (
          SELECT hdrs.database_id as DatabaseId, sdb.name as DatabaseName, 'ALWAYS_ON_NOT_WRITABLE_REPLICA' as Reason, NULL as DatabaseNameOnPitrTable
          FROM sys.dm_hadr_database_replica_states hdrs
          INNER JOIN sys.databases sdb ON sdb.database_id = hdrs.database_id
          WHERE (hdrs.is_local = 1 AND hdrs.is_primary_replica = 0) 
          OR (sys.fn_hadr_is_primary_replica (sdb.name) = 1 AND DATABASEPROPERTYEX (sdb.name, 'Updateability') = 'READ_ONLY')
      ),
      TABLE1 as (
              SELECT
              db.name AS DatabaseName,
              db.create_date AS CreateDate,
              db.state_desc AS DatabaseState,
              db.database_id AS DatabaseId,
              rs.database_guid AS DatabaseGuid,
              rs.last_log_backup_lsn AS LastLogBackupLSN,
              rs.recovery_fork_guid RecoveryForkGuid,
              rs.first_recovery_fork_guid AS FirstRecoveryForkGuid,
              db.recovery_model_desc AS RecoveryModel,
              db.is_auto_close_on AS IsAutoClose,
              db.is_read_only as IsReadOnly,
              NEWID() as FileName,
              CASE WHEN(db.state_desc = 'ONLINE'
                      AND db.recovery_model_desc != 'SIMPLE' 
                      AND((db.is_auto_close_on = 0 and db.collation_name IS NOT NULL) OR db.is_auto_close_on = 1)) 
                      AND db.is_read_only != 1
                      AND db.user_access = 0
                      AND db.source_database_id IS NULL
                      AND db.is_in_standby != 1
                      THEN 1 ELSE 0 END AS IsPartOfSnapshot,
              CASE WHEN db.source_database_id IS NULL THEN 0 ELSE 1 END AS IsDatabaseSnapshot
              FROM sys.databases db
              INNER JOIN sys.database_recovery_status rs
              ON db.database_id = rs.database_id
              WHERE DB_NAME(db.database_id) NOT IN('tempdb') AND
              db.database_id NOT IN (SELECT DISTINCT DatabaseId FROM TABLE0)
          ),
          TABLE2 as(
              SELECT @Limit+count(DatabaseName) as TotalNumberOfDatabases from TABLE1 where TABLE1.IsPartOfSnapshot=1 and DatabaseName in ('master','model','msdb')
          )
          select top(select TotalNumberOfDatabases from TABLE2)  DatabaseName,CreateDate,DatabaseState,DatabaseId from TABLE1 where TABLE1.IsPartOfSnapshot=1
          ORDER BY TABLE1.DatabaseID ASC                   
  

Nota

Anche i database che sono solo link simbolici vengono esclusi dai database idonei per le operazioni PITR. La query precedente non filtra in base a questi criteri.

Log sulle transazioni in Amazon S3

Il periodo di retention dei backup determina se i log sulle transazioni per le istanze database RDS Custom per SQL Server vengono automaticamente estratti e caricati su Amazon S3. Un valore diverso da zero significa che vengono creati backup automatici e che l'agente RDS Custom carica i log sulle transazioni su S3 ogni 5 minuti.

I file di log delle transazioni su S3 sono crittografati mentre sono inattivi tramite AWS KMS key che hai fornito quando hai creato l'istanza database. Per ulteriori informazioni, consulta Protezione dei dati con la crittografia lato server nella Guida per l'utente di Amazon Simple Storage Service.

I log delle transazioni per ciascun database vengono caricati in un bucket S3 denominato do-not-delete-rds-custom-$ACCOUNT_ID-$REGION-unique_identifier. La directory RDSCustomForSQLServer/Instances/DB_instance_resource_ID nel bucket S3 contiene due sottodirectory:

• TransactionLogs – Contiene i log delle transazioni per ciascun database e i rispettivi metadati.

  Il nome del file di log delle transazioni segue il pattern yyyyMMddHHmm.database_id.timestamp, ad esempio:

  202110202230.11.1634769287

  Lo stesso nome del file con il suffisso _metadata contiene informazioni sul log delle transazioni come numeri di sequenza di log, nome del database e RdsChunkCount. RdsChunkCount determina quanti file fisici rappresentano un singolo file di log delle transazioni. Potresti vedere file con suffissi _0001, _0002 e così via, il che significa i pezzi fisici di un file di log delle transazioni. Se si desidera utilizzare un file di log delle transazioni a blocchi, assicurarsi di unire i blocchi dopo averli scaricati.

  Considera uno scenario in cui hai i seguenti file:

  • 202110202230.11.1634769287

  • 202110202230.11.1634769287_0001

  • 202110202230.11.1634769287_0002

  • 202110202230.11.1634769287_metadata

  Il valore del campo RdsChunkCount è 3. L'ordine di unione dei file è il seguente: 202110202230.11.1634769287, 202110202230.11.1634769287_0001, 202110202230.11.1634769287_0002.

• TransactionLogMetadata – Contiene informazioni sui metadati su ogni iterazione dell'estrazione del log delle transazioni.

  Il file RI.End contiene informazioni per tutti i database a cui sono stati estratti i log delle transazioni e per tutti i database esistenti ma che non hanno i log delle transazioni estratti. Il nome del file RI.End segue il pattern yyyyMMddHHmm.RI.End.timestamp, ad esempio:

  202110202230.RI.End.1634769281

Ripristino PITR utilizzando la Console di gestione AWS, la AWS CLI o l’API RDS.

Puoi ripristinare un'istanza database RDS Custom per SQL Server a un punto temporale tramite Console di gestione AWS, AWS CLI o l'API di RDS.

Console

Per ripristinare un'istanza database RDS Custom un punto temporale specifico

1. Accedi a Console di gestione AWS e apri la console Amazon RDS all'indirizzo https://console.aws.amazon.com/rds/.

2. Nel riquadro di navigazione, selezionare Automated backups (Backup automatici).

3. Scegli l'istanza database RDS Custom da ripristinare.

4. In Actions (Operazioni), scegli Restore to point in time (Ripristina a un istante temporale).

   Viene visualizzata la finestra Restore to point in time (Ripristina a un istante temporale).

5. Scegliere Latest restorable time (Ultimo orario di ripristino) per eseguire il ripristino in base al momento più recente oppure scegliere Custom (Personalizzato) per scegliere una data e un'ora.

   Se scegli Personalizzato, specifica la data e l'ora in cui desideri ripristinare l'istanza.

   Gli orari vengono visualizzati nel fuso orario locale, indicato come un offset dell'ora UTC (Coordinated Universal Time). Ad esempio, UTC-5 è l'orario standard degli Stati Uniti orientali/ora legale degli Stati Uniti centrali.

6. Per DB Instance Identifier (Identificatore istanze database), inserire il nome dell'istanza database RDS Custom di destinazione ripristinata. Il nome deve essere univoco.

7. Scegli altre opzioni in base alle esigenze, ad esempio la classe di istanza database.

8. Scegli Restore to point in time (Ripristina per punto nel tempo).

AWS CLI

Si ripristina un'istanza database a un'ora specifica utilizzando il comando restore-db-instance-to-point-in-time AWS CLI per creare una nuova istanza database RDS Custom.

Utilizzare una delle opzioni seguenti per specificare il backup da cui effettuare il ripristino:

• --source-db-instance-identifier mysourcedbinstance

• --source-dbi-resource-id dbinstanceresourceID

• --source-db-instance-automated-backups-arn backupARN

L'opzione custom-iam-instance-profile è obbligatoria.

Il seguente esempio ripristina my-custom-db-instance a una nuova istanza database denominata my-restored-custom-db-instance, a partire dal tempo specificato.

Per Linux, macOS o Unix:

aws rds restore-db-instance-to-point-in-time \
    --source-db-instance-identifier my-custom-db-instance\
    --target-db-instance-identifier my-restored-custom-db-instance \
    --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance \
    --restore-time 2022-10-14T23:45:00.000Z

Per Windows:

aws rds restore-db-instance-to-point-in-time ^
    --source-db-instance-identifier my-custom-db-instance ^
    --target-db-instance-identifier my-restored-custom-db-instance ^
    --custom-iam-instance-profile AWSRDSCustomInstanceProfileForRdsCustomInstance ^
    --restore-time 2022-10-14T23:45:00.000Z