일반적으로 백업 및 DR 서비스는 데이터베이스의 초기 전체 처리 백업에는 시간이 많이 걸리지만 이후의 모든 백업은 훨씬 더 빠른 증분 백업입니다. 증분 백업은 현재 스냅샷과 이전 스냅샷의 비트맵을 비교하고 증분 변경사항만 적용합니다.
낮은 플래시 백업은 이전 백업 작업의 일부 시스템 오류로 인해 비트맵 이미지가 불안정해지거나 비트맵을 읽을 수 없게 되었을 때 발생하는 특수한 유형의 백업 작업입니다. 비트맵을 읽는 서비스는 Linux 환경에서는 cbt_server이고 Windows 환경에서는 AAMService입니다.
플래시가 적은 백업은 안정적인 비트맵을 다시 만들기 위해 전체 처리를 다시 실행해야 하므로 정상적인 조건에서 실행된 백업보다 시간이 더 많이 걸립니다. 그러면 전체 이미지를 교체하지 않고도 증분 변경사항을 적용할 수 있습니다.
낮은 플래시 백업을 일으키지 않는 요소
커넥터 업그레이드
단계적 시스템 재부팅
백업 시 서비스가 여전히 실행 중이라고 가정하여 cbt_server 또는 AAMService를 조용히 다시 시작합니다.
신뢰할 수 없는 비트맵을 유발하는 오류가 발생하지 않은 페일오버
신뢰할 수 없는 비트맵의 원인
다음을 비롯한 어떤 이유로든 백업 작업이 중단되면 신뢰할 수 없는 비트맵이 발생합니다.
호스트의 비정상 종료
정상 종료가 이루어지지 않으면 비트맵의 불안정성으로 인해 스플래시가 낮아집니다.
여기에는 물리적 머신의 전원을 끄거나 정상 종료 또는 블루스크린 오류를 거치지 않고 Windows를 끄는 다른 방법이 포함됩니다. 이는 클러스터의 한 머신에서 페일오버를 트리거하는 파란색 화면 오류가 발생하더라도 마찬가지입니다. 실패한 머신의 비트맵은 신뢰할 수 없기 때문입니다.
이전 백업 이후 데이터베이스를 호스팅한 클러스터의 모든 Windows 서버를 사용할 수 없고 Actifio 서비스를 실행하고 있지 않은 경우 이전 백업 이후 데이터베이스를 호스팅한 각 클러스터 호스트에서 비트맵을 가져와 변경사항을 찾습니다. 모든 비트맵이 없으면 데이터 무결성을 유지하기 위해 로우 스플래시를 실행해야 합니다. 데이터베이스를 호스팅하는 클러스터 호스트가 BSOD를 발생시키는 경우 비트맵은 백업 시 사용할 수 있지만 여전히 신뢰할 수 없으므로 플래시가 낮습니다.
커널 모듈 업데이트 실패
사용자 모드 데몬의 비정상 종료 또는 다시 시작
백업을 실행하는 동안 발생한 지문 오류 백업 및 DR 서비스는 각 백업 작업에 대해 '디지털 지문 확인'을 실행하여 오류를 확인합니다.
OS 종료 중에 스토리지 디스크가 가득 차고 시스템이 보관소에 모든 데이터를 쓸 수 없는 경우 보관소에 저장하는 중에 발생하는 오류입니다.
SAP HANA 노드 장애 조치로 인해 백업이 다른 노드로 리디렉션됨
커널 모듈을 로드할 수 없어 성능이 저하된 모드로 백업이 실행됩니다.
이 문제는 일반적으로 OS가 지원되지 않는 버전인 경우 발생합니다.
백업 중에 cbt_server 또는 AAMService가 중지되면 비트맵을 가져올 수 없으며 백업 작업이 낮은 플래시 모드로 실행됩니다.
AAMService가 오래 다운되지 않은 경우 AAMService를 시작하면 비트맵을 정상적으로 백업할 수 있습니다.
cbt_server 또는 AAMService가 드라이버에 의해 몇 기가바이트의 이벤트가 대기열에 추가될 만큼 충분히 오래 중지되면 비트맵을 다시 만들 수 없으며 백업이 낮은 플래시 모드로 전환됩니다. 이 작업에 걸리는 시간은 데이터베이스에서 발생하는 디스크 I/O의 양에 따라 다릅니다. 이 경우 일반적으로 AAMService가 다운되는 데 며칠이 걸립니다.
cbt_server 또는 AAMService가 정상적으로 종료되지 않으면 현재 로드된 비트맵에 비트맵이 더 이상 안정적으로 표시되지 않을 수 있습니다. 추적된 파일이 지난 15분 동안 작성된 경우 비트맵이 로드되므로 일반적으로 사용량이 많은 데이터베이스에서는 플래시가 적게 발생합니다.
추적된 파일 (예: SQL Server .mdf 파일)이 포함된 볼륨이 호스트에서 마운트 해제된 후 다시 마운트되면 비트맵은 신뢰할 수 없습니다. 마운트 해제된 동안 파일에 무엇이 쓰여졌는지 알 수 있는 방법이 없기 때문입니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003eLow-splash backups are a type of backup job triggered by system errors in the preceding backup, resulting in unreliable or unreadable bitmap images.\u003c/p\u003e\n"],["\u003cp\u003eUnlike normal incremental backups, low-splash backups require a full ingest to recreate a reliable bitmap, making them more time-consuming.\u003c/p\u003e\n"],["\u003cp\u003eUnclean shutdowns, failed kernel module updates, crashes in user mode daemons, or any interruptions that cause bitmap unreliability during a backup job can trigger a low-splash backup.\u003c/p\u003e\n"],["\u003cp\u003eGraceful system reboots, connector upgrades, and graceful restarts of cbt_server or AAMService will not cause low-splash backups, as long as the service is running during the backup.\u003c/p\u003e\n"],["\u003cp\u003eIf cbt_server (Linux) or AAMService (Windows) is stopped during a backup, bitmaps cannot be retrieved, resulting in a low-splash backup, and depending on how long it was stopped, it may also result in low splash after being started again.\u003c/p\u003e\n"]]],[],null,["# Causes of low-splash database backups\n\nWhat is a low-splash backup?\n----------------------------\n\nUnder normal circumstances, Backup and DR Service takes a time-consuming initial\nfull-ingest backup of a database, and then all subsequent backups are much\nfaster incremental backups. An incremental backup compares bitmaps of the current\nsnapshot and the preceding snapshot and applies only the incremental changes.\n\nA low-splash backup is a special type of backup job that occurs when some system\nerror in the preceding backup job results in an unreliable bitmap image or an\ninability to read the bitmap. The service that reads the bitmap is cbt_server\nin a Linux environment and AAMService in a Windows environment.\n\nLow-splash backups are more time consuming than backups made under normal\nconditions because they must perform a full ingest again to recreate a reliable\nbitmap. It can then apply the incremental changes without having to replace the\nfull image.\n| **Note:** Low-splash backups don't occur for Oracle databases on Linux or on Windows.\n\nThings that do not cause low-splash backups\n-------------------------------------------\n\n- Connector upgrades\n- Graceful system reboots\n- Graceful restarts of cbt_server or AAMService assuming that the service is still running at the time of backup\n- Failovers that did not experience the errors that cause unreliable bitmaps.\n\nCauses of unreliable bitmaps\n----------------------------\n\nAn unreliable bitmap occurs when something interrupts the backup job, including\nthe following:\n\n- An unclean shutdown of the host\n - A non-graceful shutdown causes low-splash due to unreliability of bitmaps. This includes pulling power on a physical machine or any other method of turning off Windows without going through a graceful shutdown, or a blue screen error. This is true even if one machine in a cluster hits a blue screen error that triggers failover, since the bitmap from the failed machine is unreliable.\n - If all Windows servers in a cluster that have hosted the database since the previous backup are not available and running Actifio services. We pull bitmaps from each cluster host which hosted the database since the previous backup to find changes, and without all bitmaps, we have to run low-splash to maintain data integrity. Note that if a cluster host that hosted a database hits a BSOD, the bitmap might be available at backup but still be unreliable, so low-splash.\n- A failed kernel module update\n- A crash or a restart in the user mode daemon\n- A fingerprint error while running a backup. (Backup and DR Service performs a \"fingerprint check\" on each backup job to check for errors.)\n- Error during vaulting, if during OS shutdown the storage disk is full and the system cannot write all data into the vault.\n- SAP HANA node failover, causing the backup to be redirected to a different node.\n- Backup running in degraded mode due to inability to load the kernel module. This typically occurs when the OS is an unsupported version.\n- If cbt_server or AAMService is stopped during the backup, then bitmaps cannot be fetched and the backup job runs in low-splash mode. If AAMService is not down for very long, then starting AAMService will result in bitmaps being available for a normal backup.\n - If cbt_server or AAMService is stopped for long enough that some gigabytes of events are queued by the driver, then the bitmaps cannot be recreated and the backup will be in low-splash mode. How long this takes depends on how much disk I/O happens on the database. This typically require days of AAMService downtime.\n- Non-graceful shutdown of the cbt_server or AAMService can cause bitmaps to become unreliable for any currently-loaded bitmaps. Bitmaps are loaded if the tracked file has been written to in the last 15 minutes, so generally for a busy database this would cause low-splash.\n- If a volume containing a tracked file (e.g. a SQL Server .mdf file) is unmounted on the host and then re-mounted, the bitmaps are unreliable since there is no way to know what was written to the file while it was unmounted."]]
