IT Log & 期權賠錢全記錄: commvault

顯示具有 commvault 標籤的文章。顯示所有文章

2026/06/09

commvault Alert: Index State Type: Custom Rules - Index State

環境:

commvault

異常狀況:

突然每天都會收到這個警告信，但備份工作都正常，不知是哪邊有問題。

後來發現這個backupset底下的所有虛擬機備份，在這警告信出現前的備份都可以正常還原。

在開始發出警告信後的備份，還原時都會出現錯誤:Could not perform the operation as Log restore failed for Job 161471. Please check Index Server log for more details。

解決過程:

參考ai上的作法，在commvault主機上的C:\Program Files\Commvault\ContentStore\IndexCache，底下有CvIdxDB跟CvIdxLogs資料夾

在裡面找到跟上面DbName相同名稱的資料夾，把他們改名。

重新建立還原工作，系統就會重建裡面的內容，恢復正常~~但試過沒用。

後來重新啟動完整備份，還是一樣的錯誤。

最後解法就是，建一個新的backupset，在裡面對虛擬機建立新的備份工作，備份完測試，可正常還原。

Environment:

Commvault

Issue:

An alert email suddenly started appearing every day, although all backup jobs were completing successfully and no obvious issues were found.

Further investigation showed that:

Backups of all virtual machines under this Backupset that were created before the alert emails started could be restored normally.
Backups created after the alerts began failed during restore with the following error:

Error:
Could not perform the operation as Log restore failed for Job 161471. Please check Index Server log for more details.

Troubleshooting Process:

Based on suggestions found online, the following method was attempted:

On the Commvault server, navigate to:
C:\Program Files\Commvault\ContentStore\IndexCache
Locate the folders under CvIdxDB and CvIdxLogs that have the same name as the DbName shown in the error.
Rename those folders.
Create a new restore job so the system can rebuild the index data.

However, this method did not resolve the issue.

A Full Backup was then executed again, but the restore error still occurred.

Final Resolution:

The issue was resolved by:

Creating a new Backupset.
Creating a new backup job for the virtual machines within that Backupset.
Running the backup again.

After the new backup completed, restore tests were performed and the restore worked normally.

2026/05/26

Backup exec 備份MS SQL時只能完整備份

環境:

Backup exec

Commvault

MS SQL

異常狀況:

Backup exec 備份MS SQL時，，設定差異備份，還是只會執行完整備份

解決過程:

Commvault 虛擬機備份設定中，如果選擇了File System and Application Consistent，就會把之前Backup exec 對MS SQL備份的備份鏈資訊重置，造成Backup exec之後備份必須做完整備份。

所以要把Commvault 虛擬機備份設定改成下面的Crash Consisten。

Environment:

Backup Exec

Commvault

Microsoft SQL Server

Issue:

When using Backup Exec to back up MS SQL Server, the job is configured for Differential Backup, but it always performs a Full Backup instead.

Resolution:

In the Commvault virtual machine backup settings, if “File System and Application Consistent” is enabled, it resets the SQL backup chain information previously created by Backup Exec.

As a result, Backup Exec is forced to perform a new Full Backup before Differential Backups can continue.

To avoid this issue, change the Commvault VM backup setting from:

File System and Application Consistent

to:

Crash Consistent

2026/04/29

COMMCAULT DR備份 Error Code [34:53] [34:53]

環境:

COMMCAULT

異常狀況:

存放DR備份的網路資料夾密碼有變更，之後DR備份就會有錯誤訊息

Error Code [34:53] [34:53]

Failure Reason CommServeDR: Destination Directory [\\sharefolder\commvault\CVDRBackup] does not exist or is inaccessible

CommServeDR: Destination Directory [\\sharefolder\commvault\CVDRBackup] does not exist or is inaccessible

解決過程:

到commvault console裡的"控制台"，找到"DR Backup"，裡面可以變更網路資料夾的帳號與密碼，修改正確後就可以正常備份。

2026/04/08

環境:

commvault

掛載nas共用資料夾，當作媒體櫃，存放備份資料。

異常狀況:

nas密碼變更後，commvault無法掛載共用資料夾

解決過程:

在控制台，裡面有credentials manager，裡面有目前使用的帳號密碼設定，可以從這邊去修改。

2026/03/26

Commvault 備份虛擬機突然變的很慢

環境:

Commvault 備份虛擬機

異常狀況:

對新的虛擬機做第一次備份，可能容量比較大，過程中又有其他的備份，造成效能問題，最後就停住多個小時後，手動取消。

但後來要重新備份時，傳輸速度變超級慢，速度大概只剩之前的1/7~8，重開機也一樣。

解決過程:

後來發現之前備份失敗後，虛擬機上有一份snapshot沒被移除，先在esxi上，把那份snapshot刪除後，重新備份，就正常了。

Environment:

Commvault (VM Backup)

Issue:

When performing the first backup of a new virtual machine, the data size was relatively large. During the process, other backup jobs were also running, causing performance issues. Eventually, the job became unresponsive and was manually canceled after several hours.

After that, when attempting to run the backup again, the transfer speed became extremely slow, dropping to about 1/7–1/8 of the original speed. Restarting the system did not resolve the issue.

Resolution:

It was later discovered that after the failed backup, a snapshot remained on the virtual machine and was not removed.

By logging into ESXi and deleting the leftover snapshot, then running the backup again, the performance returned to normal.

2026/03/03

commvault 備份時會當機

環境:

commvault

x3650m3

win2012

異常狀況:

已經運作多年的備份主機，突然開始在備份時會當機，備份比較大的資料才會當機，只是少量的就不會，不執行備份放一整個晚上也都沒問題。

當機後通常會進到藍底白字畫面，搜尋相關錯誤資訊，但未有任何進度就會直接重開機。

沒有memory dump檔，事件檢視器也沒有任何可參考的資訊，只會有意外當機的事項。

IMM 的log裡也沒有任何的異常。

raid程式裡，硬碟與raid卡都健康。

用內建的記憶體測試，正常。

解決過程:

關閉防毒->無效

調低備份的Maximum number of parallel data transfer operations->無效

關機拔電後重開->無效

拔掉六條記憶體擦一擦，只插回基本的兩條->無效

在找不到任何方法下，先把記憶體全部插回，再試試，居然就正常了....

但過了一週，又開始發生備份會當機的狀況，大概兩天後主機的raid跟pci就亮橘燈了。

更換raid卡後終於恢復正常。

Environment:

Commvault
IBM x3650 M3
Windows Server 2012

Issue:

A backup server that had been running normally for many years suddenly began crashing during backup operations.
The crash only occurred when backing up large amounts of data. Backups with small amounts of data completed normally, and the server could remain powered on overnight without issues if no backup jobs were running.

After the crash, the system usually entered a blue screen. When attempting to view the error details, the system rebooted before any useful information could be collected.

Additional observations:

No memory dump files were generated.
Event Viewer only recorded an unexpected shutdown with no useful details.
IMM logs showed no abnormalities.
RAID management reported that the disks and RAID controller were healthy.
The built-in memory diagnostic test passed without errors.

Troubleshooting Process:

Disabled antivirus → No effect
Reduced Maximum number of parallel data transfer operations in Commvault → No effect
Powered off the server and unplugged power before restarting → No effect
Removed six memory modules, cleaned them, and left only two installed → No effect

With no other solutions available, all memory modules were reinstalled again.
Unexpectedly, after reinstalling all the RAM, the system returned to normal operation and the backup jobs completed successfully.

However, about one week later, the backup server began to crash again during backup jobs.

After approximately two more days, the RAID and PCI indicator lights on the server turned orange.

The RAID controller was then replaced, and after replacing the RAID card, the system finally returned to stable operation and the backup crashes stopped.

2026/02/26

commvault備份虛擬機失敗 There are too many existing backup snapshots on virtual machine

環境:

commvault

異常狀況:

備份失敗

錯誤碼： [91:148] 描述： There are too many existing backup snapshots on virtual machine [xx]. Backup snapshots are being cleaned up, but manual intervention may be required to ensure that all snapshots are removed. This may indicate that the storage is unable to keep up with the I/O activity of the virtual machine during a backup. Source: backupserver, Process: vsbkp

解決過程:

主要是因為備份虛擬機時，會先建立快照，但因為備份程式當掉，當成快照沒被清除。

之後要再備份就會出現此錯誤。

這時就連上esxi，到該虛擬機的快照管理中，把快照"全部刪除"，然後就可以正常備份了。

Environment:

Commvault

Issue:

Backup failed with the following error:

Error Code: [91:148]
Description:
There are too many existing backup snapshots on virtual machine [xx]. Backup snapshots are being cleaned up, but manual intervention may be required to ensure that all snapshots are removed. This may indicate that the storage is unable to keep up with the I/O activity of the virtual machine during a backup.
Source: backupserver
Process: vsbkp

Resolution:

This issue occurs because when backing up a virtual machine, the system first creates snapshots. However, if the backup process crashes or fails, the snapshots may not be removed properly.

When attempting the next backup, this error will appear.

To resolve the issue:

Log in to the ESXi host.
Open the Snapshot Manager for the affected virtual machine.
Select Delete All snapshots.

After removing all snapshots, the backup should run normally again.

2026/01/06

commvault Oracle 資料庫還原看不到資料表

環境:

用commvault 備份Oracle 資料庫，要還原時，在裡面都只看到dbf檔，無法顯示裡面的資料表。

解決過程:

commvault 備份Oracle 資料庫的設定，如果沒勾選"啟用表格瀏覽"，就看不到裡面的資料表，這邊的表格，就是指資料表Table的意思。

如果沒有勾選這個功能，還原就會變的很麻煩

1. 沒啟用 Enable Table Browse

若您過去的備份沒有啟用此功能，當有人誤刪資料時：

還原邏輯： 您無法在 Commvault 介面看到「表」的清單，只能看到「資料庫」。
必須全機還原： 您必須像現在一樣選擇 RMAN Duplicate DB，把整個資料庫（數百 GB 或 TB）還原，變成一個資料庫。
手動撈取： 您得自己連進資料庫，下 SQL 或用 expdp 撈出那張表，再手動匯入回。
缺點： 極度消耗磁碟空間，且還原時間很長（因為要搬動所有資料檔）。

2. 啟用 Enable Table Browse 後的差別 (未來的狀況)

如果您現在勾選並完成了一次新的完整備份：

還原邏輯： 在「瀏覽」視窗切換到 Table View，您可以直接看到裡面的所有使用者與資料表清單。
精準還原： 您只需要勾選「被誤刪的那張表」。
自動化輔助實例： Commvault 會自動在Staging Path 建立一個「最小化」的臨時實例。它只會還原必要的系統檔案和該表所在的 Tablespace，而不是整個資料庫。
優點： 節省大量磁碟空間（可能只需還原 10% 的資料量），且 Commvault 會自動完成匯出與匯入的動作。

下面這篇文件有更仔細的說明

https://itnoesis.com/2020/09/20/oracle-rac-table-restore-using-commvault/

Environment:

When using Commvault to back up an Oracle database, during restore operations only .dbf files are visible, and the tables inside the database cannot be displayed.

Resolution Process:

In the Commvault Oracle database backup settings, if “Enable Table Browse” is not selected, database tables will not be visible.
Here, “Table” refers to database tables.

If this option is not enabled, restoration becomes very complicated.

1. Without enabling Enable Table Browse

If past backups were performed without this option enabled and a table is accidentally deleted:

Restore logic:
You cannot see a list of tables in the Commvault interface. You can only see the database as a whole.
Full database restore required:
You must perform an RMAN Duplicate DB, restoring the entire database (hundreds of GBs or even TBs) as a separate database instance.
Manual data extraction:
You must manually connect to the database, run SQL queries, or use expdp to export the required table, then manually import it back.
Drawbacks:
Extremely high disk space consumption and very long restore times, since all data files must be restored.

2. Difference after enabling Enable Table Browse (future scenario)

If you enable this option now and complete a new full backup:

Restore logic:
In the Browse window, switch to Table View, and you can directly see all users and their tables.
Precise restore:
You only need to select the specific table that was accidentally deleted.
Automated auxiliary instance:
Commvault will automatically create a minimal temporary instance in the Staging Path.
It restores only the required system files and the tablespace containing the selected table, rather than the entire database.
Advantages:
Significant disk space savings (possibly restoring only around 10% of the data), and Commvault automatically handles the export and import process.