Solved

Acronis Backup and Recovery 11.5

Posted on 2016-08-01
13
106 Views
Last Modified: 2016-10-27
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
0
Comment
Question by:jsarinana
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 5
  • 3
13 Comments
 
LVL 40

Expert Comment

by:Adam Brown
ID: 41738264
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
 
LVL 47

Expert Comment

by:noxcho
ID: 41738537
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
 
LVL 1

Author Comment

by:jsarinana
ID: 41739137
noxcho
chkdsk during a boot?
0
Comprehensive Backup Solutions for Microsoft

Acronis protects the complete Microsoft technology stack: Windows Server, Windows PC, laptop and Surface data; Microsoft business applications; Microsoft Hyper-V; Azure VMs; Microsoft Windows Server 2016; Microsoft Exchange 2016 and SQL Server 2016.

 
LVL 47

Expert Comment

by:noxcho
ID: 41739359
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
 
LVL 40

Expert Comment

by:Adam Brown
ID: 41739386
Don't run chkdsk if you're set up with a striped RAID configuration, FYI. It can cause problems.
0
 
LVL 1

Author Comment

by:jsarinana
ID: 41739414
The disk I'm referring to is a RAID6
I thought you were not suppose to chkdsk a RAID?
0
 
LVL 40

Expert Comment

by:Adam Brown
ID: 41739431
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
 
LVL 1

Author Comment

by:jsarinana
ID: 41739445
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
 
LVL 40

Expert Comment

by:Adam Brown
ID: 41739464
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
 
LVL 47

Expert Comment

by:noxcho
ID: 41739601
CHKDSK is running on a file system level. It does not know about the RAID existence. How can it affect the RAID configuration?
0
 
LVL 1

Author Comment

by:jsarinana
ID: 41739780
logs are 53GB
0
 
LVL 40

Accepted Solution

by:
Adam Brown earned 500 total points
ID: 41739805
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
 
LVL 1

Author Closing Comment

by:jsarinana
ID: 41739819
thanks
0

Featured Post

Simplifying Server Workload Migrations

This use case outlines the migration challenges that organizations face and how the Acronis AnyData Engine supports physical-to-physical (P2P), physical-to-virtual (P2V), virtual to physical (V2P), and cross-virtual (V2V) migration scenarios to address these challenges.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Adoption of Microsoft’s Enterprise Mobility and Security solution and Office 365 will re-order the File Sync and Share market Microsoft has stated that its Enterprise Mobility + Security (EMS) is the fastest growing product in the history of the …
A Stored Procedure in Microsoft SQL Server is a powerful feature that it can be used to execute the Data Manipulation Language (DML) or Data Definition Language (DDL). Depending on business requirements, a single Stored Procedure can return differe…
This tutorial will walk an individual through the process of installing of Data Protection Manager on a server running Windows Server 2012 R2, including the prerequisites. Microsoft .Net 3.5 is required. To install this feature, go to Server Manager…
This tutorial will walk an individual through setting the global and backup job media overwrite and protection periods in Backup Exec 2012. Log onto the Backup Exec Central Administration Server. Examine the services. If all or most of them are stop…

734 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question