Acronis Backup and Recovery 11.5

I have a SBS 2011 server
C and D drive, D drive is a shared file server and Exchange storage; C drive is the O.S. and apps
I created a backup plan for the C drive and it works just fine
When I try to backup my D drive I get the following error:

Type: Warning
Date: 7/31/2016 11:36:16 AM
Backup Plan: D to F eSata Backup 7/31/2016 11:26:35 AM (I stopped it at 7:32 am
Task: Simple backup (Full)
Code: 5,701,632(0x570000)
Module: 87
Owner: administrator@DOMAIN
Microsoft SQL database 'master' of instance 'MICROSOFT##SSEE' has not been backed up since the database files are not included in the single-pass backup.

I'm looking at my plan and I see:
In the Acronis plan under Single-pass disk and application backup I have "Single-pass backup" enabled.

I also have an option to select in "For single-pass backup, it is recommended to select machine entirely rather than their disks or volumes. Otherwise, application data may be backed up incompletely"

? did I need to select the C drive as well?

thanks
LVL 1
jsarinanaI.T. ManagerAsked:
Who is Participating?
 
Adam BrownConnect With a Mentor Sr Solutions ArchitectCommented:
All the data in a RAID goes through the RAID controller. RAID controllers perform their own integrity checks for physical issues, but not all the time. It is a rare thing, but it is entirely possible for both chkdsk and RAID integrity checks to find corruption due to physical issues at the same time and attempt to move the same data to two different physical locations, resulting in chkdisk and/or the RAID controller losing track of the actual data, resulting in file loss.

Chkdsk may only function against the logical disk, but it's still utilizing the RAID controller to access the data it needs, and if the RAID controller is designed to do live integrity checks (which is common) the two can end up in competition with one another in regards to solving any corruption that is found. Since Chkdsk doesn't actually communicate with the RAID controller (and vice versa), there's a real risk of more severe data corruption.

Now, if you run CHKDSK as a scan only, that shouldn't be a problem, but using chkdsk to repair file integrity introduces significant risk, depending on the features of the RAID controller.
0
 
Adam BrownSr Solutions ArchitectCommented:
Only if you need to backup the windows server integrated database. That is to say, if anything on that server is using the Integrated SQL instance, you'll need to include C: in the backup. Otherwise, you can ignore that error because the database isn't used.
1
 
noxchoGlobal Support CoordinatorCommented:
Yes, perform chkdsk on all the drives on the server. This can be even done as a part of weekly maintenance of the server.
0
 
jsarinanaI.T. ManagerAuthor Commented:
noxcho
chkdsk during a boot?
0
 
noxchoGlobal Support CoordinatorCommented:
Yes, if your server policy allows this, weekly or monthly check is good practice, perform the CHKDSK x:/f on each volume where X: is a drive letter of your volumes.
If the volume is not locked by some process it will run without reboot. Only system partitions require reboot for exclusive access to file system for check operation.
0
 
Adam BrownSr Solutions ArchitectCommented:
Don't run chkdsk if you're set up with a striped RAID configuration, FYI. It can cause problems.
0
 
jsarinanaI.T. ManagerAuthor Commented:
The disk I'm referring to is a RAID6
I thought you were not suppose to chkdsk a RAID?
0
 
Adam BrownSr Solutions ArchitectCommented:
Raid 6 is a striped configuration, so don't chkdsk it. As I mentioned earlier, you can most likely ignore this particular error that you're getting because it's referencing the Windows Integrated database, which exists on all Windows Servers. It's a SQL instance that is very low capability and generally only used for simple applications that still need database capabilities. What are you running on this server?
0
 
jsarinanaI.T. ManagerAuthor Commented:
All I'm running is Exchange 2010
I started the backup to a eSATA storage at 7:30 pm last night and this morning at 7:30 am it was at 27% completed so I stopped it because I thought maybe it was stuck because of this error. the data is 2.9TBs
0
 
Adam BrownSr Solutions ArchitectCommented:
How much of that data is transaction logs? If you have a lot of Exchange transaction logs on the server, it will take a *very* long time to truncate them, since the server has to compare the data in the database with what is in the logs. Truncation happens during full backups that run on exchange database volumes, so you'll want to determine how much of the data you are backing up is Logs vs. the actual database.

If there are more than 100GB of transaction logs, take a VSS copy backup of the log files only (this will prevent truncation) so you have them for restore purposes, then delete the log files that are older than 2-3 days old (It's safe to do this, since the data is written to the database as well). You can then run a VSS full backup that will truncate the remaining logs and that shouldn't take nearly as long.

For information, log truncation on 100GB+ of logs can take several *days* to complete, so unless you want to negatively impact performance on the exchange server for an extended period, running a copy backup and manually purging the logs is your best bet.

Finally, if you're only running Exchange on this server, you can safely ignore the notice that you're getting above. That particular database does nothing for Exchange server.
0
 
noxchoGlobal Support CoordinatorCommented:
CHKDSK is running on a file system level. It does not know about the RAID existence. How can it affect the RAID configuration?
0
 
jsarinanaI.T. ManagerAuthor Commented:
logs are 53GB
0
 
jsarinanaI.T. ManagerAuthor Commented:
thanks
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.