Azure Database for MySQL의 백업 및 복원Backup and restore in Azure Database for MySQL

Azure Database for MySQL은 자동으로 서버 백업을 만들어 사용자가 로컬로 구성한 중복 스토리지 또는 지역 중복 스토리지에 저장합니다.Azure Database for MySQL automatically creates server backups and stores them in user configured locally redundant or geo-redundant storage. 백업을 사용하여 특정 시점의 서버를 복원할 수 있습니다.Backups can be used to restore your server to a point-in-time. 백업 및 복원은 실수로 인한 손상이나 삭제로부터 데이터를 보호하므로 비즈니스 연속성 전략의 필수적인 부분입니다.Backup and restore are an essential part of any business continuity strategy because they protect your data from accidental corruption or deletion.

BackupBackups

Azure Database for MySQL는 데이터 파일과 트랜잭션 로그의 백업을 수행 합니다.Azure Database for MySQL takes backups of the data files and the transaction log. 지원 되는 최대 저장소 크기에 따라 전체 및 차등 백업 (4-TB의 최대 저장소 서버) 또는 스냅숏 백업 (최대 16TB의 최대 저장소 서버)을 수행 합니다.Depending on the supported maximum storage size, we either take full and differential backups (4-TB max storage servers) or snapshot backups (up to 16-TB max storage servers). 이러한 백업을 사용하면 서버를 구성된 백업 보존 기간 내의 특정 시점으로 복원할 수 있습니다.These backups allow you to restore a server to any point-in-time within your configured backup retention period. 기본 백업 보존 기간은 7일입니다.The default backup retention period is seven days. 필요에 따라 최대 35 일을 구성할 수 있습니다.You can optionally configure it up to 35 days. 모든 백업은 AES 256비트 암호화를 사용하여 암호화됩니다.All backups are encrypted using AES 256-bit encryption.

이러한 백업 파일은 사용자에 게 노출 되지 않으므로 내보낼 수 없습니다.These backup files are not user-exposed and cannot be exported. 이러한 백업은 Azure Database for MySQL 복원 작업에만 사용할 수 있습니다.These backups can only be used for restore operations in Azure Database for MySQL. Mysqldump 를 사용 하 여 데이터베이스를 복사할 수 있습니다.You can use mysqldump to copy a database.

Backup 주기Backup frequency

최대 2TB 저장소를 포함 하는 서버Servers with up to 4-TB storage

최대 5TB의 저장소를 지 원하는 서버의 경우 전체 백업은 매주 한 번 수행 됩니다.For servers which support up to 4-TB maximum storage, full backups occur once every week. 차등 백업은 하루에 두 번 발생 합니다.Differential backups occur twice a day. 트랜잭션 로그 백업은 5 분 마다 발생 합니다.Transaction log backups occur every five minutes.

최대 16TB의 저장소를 포함 하는 서버Servers with up to 16-TB storage

Azure 지역의하위 집합에서 새로 프로 비전 된 모든 서버는 최대 16tb의 저장소를 지원할 수 있습니다.In a subset of Azure regions, all newly provisioned servers can support up to 16-TB storage. 이러한 대량 저장소 서버에 대 한 백업은 스냅숏 기반입니다.Backups on these large storage servers are snapshot-based. 첫 번째 전체 스냅숏 백업은 서버를 만든 후 즉시 예약 됩니다.The first full snapshot backup is scheduled immediately after a server is created. 첫 번째 전체 스냅숏 백업은 서버의 기본 백업으로 유지 됩니다.That first full snapshot backup is retained as the server's base backup. 후속 스냅숏 백업은 차등 백업만 수행 합니다.Subsequent snapshot backups are differential backups only.

차등 스냅숏 백업은 하루에 한 번 이상 발생 합니다.Differential snapshot backups occur at least once a day. 차등 스냅숏 백업은 고정 일정에서 발생 하지 않습니다.Differential snapshot backups do not occur on a fixed schedule. 차등 스냅숏 백업은 마지막 차등 백업 이후 트랜잭션 로그 (MySQL의 binlog)가 50를 초과 하지 않는 한 24 시간 마다 발생 합니다.Differential snapshot backups occur every 24 hours unless the transaction log (binlog in MySQL) exceeds 50-GB since the last differential backup. 하루에 최대 6 개의 차등 스냅숏이 허용 됩니다.In a day, a maximum of six differential snapshots are allowed.

트랜잭션 로그 백업은 5 분 마다 발생 합니다.Transaction log backups occur every five minutes.

백업 보존Backup retention

백업은 서버의 백업 보존 기간 설정에 따라 보존 됩니다.Backups are retained based on the backup retention period setting on the server. 7 일에서 35 일의 보존 기간을 선택할 수 있습니다.You can select a retention period of 7 to 35 days. 기본 보존 기간은 7 일입니다.The default retention period is 7 days. Azure Portal 또는 Azure CLI를 사용 하 여 백업 구성을 업데이트 하 여 서버를 만드는 동안 또는 나중에 보존 기간을 설정할 수 있습니다.You can set the retention period during server creation or later by updating the backup configuration using Azure portal or Azure CLI.

백업 보존 기간은 사용 가능한 백업을 기반으로 하기 때문에 특정 시점 복원을 검색할 수 있는 시간을 제어합니다.The backup retention period governs how far back in time a point-in-time restore can be retrieved, since it's based on backups available. 백업 보존 기간은 복원 관점에서 복구 기간으로 처리 될 수도 있습니다.The backup retention period can also be treated as a recovery window from a restore perspective. 백업 보존 기간 내에 지정 시간 복원을 수행 하는 데 필요한 모든 백업은 백업 저장소에 유지 됩니다.All backups required to perform a point-in-time restore within the backup retention period are retained in backup storage. 예를 들어 백업 보존 기간을 7 일로 설정 하면 복구 기간이 최근 7 일로 간주 됩니다.For example, if the backup retention period is set to 7 days, the recovery window is considered last 7 days. 이 시나리오에서는 지난 7 일 동안 서버를 복원 하는 데 필요한 모든 백업이 유지 됩니다.In this scenario, all the backups required to restore the server in last 7 days are retained. 백업 보존 기간을 7 일로 바꿉니다.With a backup retention window of seven days:

  • 최대 2TB 저장소를 포함 하는 서버는 최대 2 개의 전체 데이터베이스 백업, 모든 차등 백업 및 가장 이른 전체 데이터베이스 백업 이후에 수행 된 트랜잭션 로그 백업을 유지 합니다.Servers with up to 4-TB storage will retain up to 2 full database backups, all the differential backups, and transaction log backups performed since the earliest full database backup.
  • 최대 16TB의 저장소를 포함 하는 서버는 지난 8 일간 전체 데이터베이스 스냅숏, 모든 차등 스냅숏 및 트랜잭션 로그 백업을 유지 합니다.Servers with up to 16-TB storage will retain the full database snapshot, all the differential snapshots and transaction log backups in last 8 days.

백업 중복 옵션Backup redundancy options

Azure Database for MySQL은 범용 및 메모리 최적화 계층에서 로컬로 중복되거나 지리적으로 중복된 백업 스토리지 중에서 선택할 수 있는 유연성을 제공합니다.Azure Database for MySQL provides the flexibility to choose between locally redundant or geo-redundant backup storage in the General Purpose and Memory Optimized tiers. 백업이 지역 중복 백업 스토리지에 저장되면 서버가 호스팅되는 지역에 저장될 뿐만 아니라 쌍으로 연결된 데이터 센터에도 복제됩니다.When the backups are stored in geo-redundant backup storage, they are not only stored within the region in which your server is hosted, but are also replicated to a paired data center. 이렇게 하면 재해 발생 시 다른 지역에서 서버를 복원하는 데 더 효율적인 보호와 기능을 제공합니다.This provides better protection and ability to restore your server in a different region in the event of a disaster. 기본 계층은 로컬 중복 백업 스토리지만 제공합니다.The Basic tier only offers locally redundant backup storage.

중요

백업을 위한 로컬 중복 또는 지역 중복 스토리지를 구성하는 것은 서버를 만드는 동안에만 허용됩니다.Configuring locally redundant or geo-redundant storage for backup is only allowed during server create. 서버가 프로비전되면 백업 스토리지 중복 옵션을 변경할 수 없습니다.Once the server is provisioned, you cannot change the backup storage redundancy option.

백업 스토리지 비용Backup storage cost

Azure Database for MySQL은 추가 비용 없이 최대 100%의 프로비전된 서버 스토리지를 백업 스토리지로 제공합니다.Azure Database for MySQL provides up to 100% of your provisioned server storage as backup storage at no additional cost. 사용 되는 추가 백업 저장소는 매달 GB 단위로 요금이 청구 됩니다.Any additional backup storage used is charged in GB per month. 예를 들어 250 GB의 저장소로 서버를 프로 비전 한 경우 추가 비용 없이 서버 백업에 250 GB의 추가 저장소를 사용할 수 있습니다.For example, if you have provisioned a server with 250 GB of storage, you have 250 GB of additional storage available for server backups at no additional charge. 250 GB 보다 많은 백업에 사용 된 저장소는 가격 책정 모델에 따라 요금이 청구 됩니다.Storage consumed for backups more than 250 GB is charged as per the pricing model.

Azure Portal를 통해 사용할 수 있는 Azure Monitor 백업 저장소 사용 메트릭을 사용 하 여 서버에서 사용 하는 백업 저장소를 모니터링할 수 있습니다.You can use the Backup Storage used metric in Azure Monitor available via the Azure portal to monitor the backup storage consumed by a server. 백업 저장소 사용 메트릭은 서버에 설정 된 백업 보존 기간에 따라 유지 되는 모든 전체 데이터베이스 백업, 차등 백업 및 로그 백업에서 사용 하는 저장소의 합계를 나타냅니다.The Backup Storage used metric represents the sum of storage consumed by all the full database backups, differential backups, and log backups retained based on the backup retention period set for the server. 백업 빈도는 서비스에서 관리 되며 앞에서 설명한 것입니다.The frequency of the backups is service managed and explained earlier. 서버에서 많은 트랜잭션 작업을 수행 하면 전체 데이터베이스 크기에 관계 없이 백업 저장소 사용량이 증가할 수 있습니다.Heavy transactional activity on the server can cause backup storage usage to increase irrespective of the total database size. 지역 중복 저장소의 경우 백업 저장소 사용량이 로컬 중복 저장소의 두 배가 됩니다.For geo-redundant storage, backup storage usage is twice that of the locally redundant storage.

백업 저장소 비용을 제어 하는 기본적인 방법은 적절 한 백업 보존 기간을 설정 하 고 원하는 복구 목표를 충족 하는 올바른 백업 중복성 옵션을 선택 하는 것입니다.The primary means of controlling the backup storage cost is by setting the appropriate backup retention period and choosing the right backup redundancy options to meet your desired recovery goals. 7 일에서 35 일 사이의 보존 기간을 선택할 수 있습니다.You can select a retention period from a range of 7 to 35 days. 범용 및 메모리 액세스에 최적화 된 서버는 백업에 대 한 지역 중복 저장소를 선택할 수 있습니다.General Purpose and Memory Optimized servers can choose to have geo-redundant storage for backups.

복원Restore

Azure Database for MySQL 복원 작업을 수행 하면 원래 서버의 백업에서 새 서버가 만들어지고 서버에 포함 된 모든 데이터베이스가 복원 됩니다.In Azure Database for MySQL, performing a restore creates a new server from the original server's backups and restores all databases contained in the server.

사용할 수 있는 두 가지 유형의 복원이 있습니다.There are two types of restore available:

  • 지정 시간 복원은 백업 중복성 옵션과 함께 사용할 수 있으며 전체 및 트랜잭션 로그 백업의 조합을 활용 하 여 원본 서버와 동일한 지역에 새 서버를 만듭니다.Point-in-time restore is available with either backup redundancy option and creates a new server in the same region as your original server utilizing the combination of full and transaction log backups.
  • 지역 복원은 지역 중복 저장소에 대해 서버를 구성 하 고 가장 최근에 수행한 백업을 사용 하 여 다른 지역으로 서버를 복원할 수 있는 경우에만 사용할 수 있습니다.Geo-restore is available only if you configured your server for geo-redundant storage and it allows you to restore your server to a different region utilizing the most recent backup taken.

예상 복구 시간은 데이터베이스 크기, 트랜잭션 로그 크기, 네트워크 대역폭 및 동일한 지역에서 동시에 복구되는 데이터베이스의 총 수를 포함한 여러 요소에 따라 달라집니다.The estimated time of recovery depends on several factors including the database sizes, the transaction log size, the network bandwidth, and the total number of databases recovering in the same region at the same time. 복구 시간은 일반적으로 12시간 미만입니다.The recovery time is usually less than 12 hours.

중요

삭제된 서버는 복원할 수 없습니다.Deleted servers cannot be restored. 서버를 삭제하면 해당 서버에 속한 모든 데이터베이스도 삭제되고 복구할 수 없습니다.If you delete the server, all databases that belong to the server are also deleted and cannot be recovered. 배포 후에 실수로 인한 삭제 또는 예기치 않은 변경에서 서버 리소스를 보호하려면 관리자는 관리 잠금을 활용할 수 있습니다.To protect server resources, post deployment, from accidental deletion or unexpected changes, administrators can leverage management locks.

지정 시간 복원Point-in-time restore

백업 중복 옵션과는 별도로 백업 보존 기간 내의 특정 시점으로 복원을 수행할 수 있습니다.Independent of your backup redundancy option, you can perform a restore to any point in time within your backup retention period. 새 서버가 원본 서버와 동일한 Azure 지역에 만들어집니다.A new server is created in the same Azure region as the original server. 이 경우 가격 책정 계층, 컴퓨팅 세대, vCore 수, 스토리지 크기, 백업 보존 기간 및 백업 중복 옵션에 대한 원래 서버의 구성으로 만들어집니다.It is created with the original server's configuration for the pricing tier, compute generation, number of vCores, storage size, backup retention period, and backup redundancy option.

참고

복원 작업 후 기본 값으로 다시 설정 되 고 주 서버에서 복사 되지 않는 두 개의 서버 매개 변수가 있습니다.There are two server parameters which are reset to default values (and are not copied over from the primary server) after the restore operation

  • time_zone-기본값 시스템 으로 설정 하려면이 값을 설정 합니다.time_zone - This value to set to DEFAULT value SYSTEM
  • event_scheduler-복원 된 서버에서 event_scheduler OFF 로 설정 됩니다.event_scheduler - The event_scheduler is set to OFF on the restored server

서버 매개 변수 를 다시 구성 하 여 이러한 서버 매개 변수를 설정 해야 합니다.You will need to set these server parameters by reconfiguring the server parameter

특정 시점 복원은 여러 시나리오에서 유용합니다.Point-in-time restore is useful in multiple scenarios. 예를 들어 사용자가 실수로 데이터를 삭제하거나 중요한 테이블 또는 데이터베이스를 삭제하는 경우, 또는 애플리케이션의 결함으로 인해 우연히 적절한 데이터를 잘못된 데이터로 덮어쓰는 경우가 있습니다.For example, when a user accidentally deletes data, drops an important table or database, or if an application accidentally overwrites good data with bad data due to an application defect.

마지막 5분 내의 특정 시점으로 복원하려면, 다음 트랜잭션 로그 백업이 완료될 때까지 기다려야 할 수도 있습니다.You may need to wait for the next transaction log backup to be taken before you can restore to a point in time within the last five minutes.

지역 복원Geo-restore

지역 중복 백업을 위해 서버를 구성한 경우 서비스를 사용할 수 있는 다른 Azure 지역으로 서버를 복원할 수 있습니다.You can restore a server to another Azure region where the service is available if you have configured your server for geo-redundant backups. 최대 4tb의 저장소를 지 원하는 서버는 지리적으로 쌍을 이루는 지역 또는 최대 16TB의 저장소를 지 원하는 지역으로 복원할 수 있습니다.Servers that support up to 4 TB of storage can be restored to the geo-paired region, or to any region that supports up to 16 TB of storage. 최대 16tb의 저장소를 지 원하는 서버의 경우 16 TB 서버를 지 원하는 모든 지역에서 지역 백업을 복원할 수 있습니다.For servers that support up to 16 TB of storage, geo-backups can be restored in any region that support 16 TB servers as well. 지원 되는 지역 목록에 대 한 Azure Database for MySQL 가격 책정 계층 을 검토 합니다.Review Azure Database for MySQL pricing tiers for the list of supported regions.

지역 복원은 서버가 호스팅되는 지역에 사고가 발생하여 서버를 사용할 수 없는 경우에 대비한 기본 복구 옵션입니다.Geo-restore is the default recovery option when your server is unavailable because of an incident in the region where the server is hosted. 지역에서 발생한 대규모 사고로 인해 데이터베이스 애플리케이션을 사용할 수 없는 경우 지역 중복 백업에서 다른 지역에 있는 서버로 서버를 복원할 수 있습니다.If a large-scale incident in a region results in unavailability of your database application, you can restore a server from the geo-redundant backups to a server in any other region. 지리적 복원은 서버의 최신 백업을 활용 합니다.Geo-restore utilizes the most recent backup of the server. 백업을 수행할 때와 다른 지역으로 복제할 때 사이에 지연이 있습니다.There is a delay between when a backup is taken and when it is replicated to different region. 재해가 발생한 경우 최대 1시간 동안의 데이터가 손실되므로 이 지연은 최대 1시간일 수 있습니다.This delay can be up to an hour, so, if a disaster occurs, there can be up to one hour data loss.

지역 복원 중에 변경할 수 있는 서버 구성으로는 컴퓨팅 생성, vCore, 백업 보존 기간 및 백업 중복 옵션이 있습니다.During geo-restore, the server configurations that can be changed include compute generation, vCore, backup retention period, and backup redundancy options. 가격 책정 계층(기본, 범용 또는 메모리 최적화) 또는 스토리지 크기는 지역 복원 중에 변경할 수 없습니다.Changing pricing tier (Basic, General Purpose, or Memory Optimized) or storage size during geo-restore is not supported.

복원 후 작업 수행Perform post-restore tasks

복구 메커니즘에서 복원한 후에 다음 작업을 수행하여 사용자 및 애플리케이션이 다시 백업 및 실행되도록 해야 합니다.After a restore from either recovery mechanism, you should perform the following tasks to get your users and applications back up and running:

  • 새 서버가 원래 서버를 교체하기 위한 것이라면 클라이언트와 클라이언트 애플리케이션을 새 서버로 리디렉션합니다.If the new server is meant to replace the original server, redirect clients and client applications to the new server
  • 사용자가 연결할 수 있도록 적절 한 VNet 규칙이 준비 되어 있는지 확인 합니다.Ensure appropriate VNet rules are in place for users to connect. 이러한 규칙은 원래 서버에서 복사 되지 않습니다.These rules are not copied over from the original server.
  • 적절한 로그인 및 데이터베이스 수준 권한이 있는지 확인합니다.Ensure appropriate logins and database level permissions are in place
  • 필요에 따라 경고를 구성합니다.Configure alerts, as appropriate

다음 단계Next steps