Question:
Why do I receive an error while backing up the Kaseya database of the form:
System database backup failed.
Check Data and Index Linkage - [Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID 0, index ID 0, page ID (1:76056). The Page Id in the page header = (0:0).
[Microsoft][ODBC SQL Server Driver][SQL Server]Object ID 1790629422, index ID 0: Page (1:76056) could not be processed. See other errors for details.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation errors and 1 consistency errors not associated with any single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
- OR-
You run a DBCC CHECKDB on the Kaseya database and it reports 1 or more consistency errors.
The built in Kaseya backup is failing because of an inconsistency in the database - hopefully just the index files. However, the database may require a data loss in order to repair this correctly.
Answer:
In order to backup the Kaseya database until this issue is resolved, you'll need to manually run an online backup of the database from within SQL Enterprise Manager or SQL Management Console. Depending on the time this issue takes to resolve, you may wish to schedule a backup this way temporarily. Note that until the database consistency issues are resolved, these backups should be marked as 'bad' because of the inconsistency contained in them.
Then, run a "DBCC CHECKDB" on the database as outlined in the MSDN article http://msdn2.microsoft.com/en-us/library/ms176064.aspx Just run the "DBCC CHECKDB" without specifying a repair option to start with. Check the last four lines of the output to assess which repair level to use.
If you receive an error of the form "repair allow data loss is the minimum repair level for the errors found by DBCC CHECKDB (ksubscribers)". The database has experienced corruption to the point where it requires data loss in order to repair. At this point, you should check to ensure that you have a good backup of the Kaseya database in which to recover to in the event of the database repair failing to resolve the issue.
You'll want to immediately backup the database using the database backup method in SQL Enterprise Manager or SQL Management Console. You should note that this is a 'bad' backup in the sense that the database is inconsistent.
Because you've experienced data loss, you'll need to check the integrity of the file system of the volume or volumes that the SQL database and database log files reside on.
You'll need to run "CHKDSK" to assess whether there are any on disk errors and "CHKDSK /F" to repair them. "CHKDSK /F" may result in a requirement to reboot the server.
Disk corruption may be a consequence of hardware issues on the machine hosting the SQL database so you should use whatever utility your hardware vendor supplies to check the integrity of the hard disks and/or RAID controllers and/or disk/RAID cache memory and/or cabling and/or other hardware on the machine.
Once you have repaired any on disk issues and replaced any faulty hardware, you can proceed with the database repair.
We recommend you create another 'bad' backup immediately before running the repair.
To repair the database with data loss, you must put the database into single user mode. Then repair the database, then set it back to multi-user mode.
To do this, use the following SQL commands:
"ALTER DATABASE KSUBSCRIBERS SET SINGLE_USER WITH ROLLBACK IMMEDIATE"
"DBCC CHECKDB ('KSUBSCRIBERS', REPAIR ALLOW DATA LOSS) WITH ALL ERRORMSGS"
"ALTER DATABASE KSUBSCRIBERS SET MULTI_USER"
After running the repair, rerun "DBCC CHECKDB" to see if you have completely recovered from the inconsistency.
You may have to run multiple "DBCC CHECKDB" checks and multiple repairs in order to resolve all inconsistencies discovered.
If, once you have resolved the inconsistencies, you continue to experience further issues with the Kaseya installation, your only option is to recover from a consistent backup. This should be the last successful backup from within Kaseya, as we check the database consistency before executing any backup.
Applies to:
All VSA versions.