[[["容易理解","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 (世界標準時間)。"],[[["\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."]]
