Our platform: Windows Server 2012 R2
Our setup. Physical Hyper1 (Symantec hosted on) & Virtual DC Server, which is our domain controller and stores our shared drives
Package: Symantec System Recovery 2013 R2: V 126.96.36.199477
We are having a very strange problem, which has only been noticed recently.
Each night we have a scheduled backup that backups all our data to a NASDrive in another building. I get email notifications everyday that tells me the backup has been succesful. Recently one of our staff had deleted a file by accident and we needed to retrieve it. When I mounted the drive I noticed all the data was from 3months ago. All our recent folders and files weren't in there. I dismounted it and checked all the other recovery points for the last 2 weeks and every single one was indentical showing the exact same outdated files/folders. I have also noticed that instead of a green tick beside the recovery points it's a blue question mark and the status is set to 'unavailable'. I've tried updating SSR and have restarted the server to see if that may resolve the problem. I have looked extensivley online and on the forums here, but no one seems to have had a similar problem so not sure where to start.
(On a side note, which could may have been the cause in the first place or just a coincdence. 3 months ago when we were doing a restart of the server it froze and was not responsive, which meant we had to forcefully shut it down. When I looked the otherday at our servers runtime, it was 84days. When I counted the days back to when the server would have been restarted. The file within the recovery point seemed to be the day before the restart)
(I've attached some screenshots. You can see the date modified on the Virtual Hard Disk is 12/08/2015, however the vhdx file within is showing 18/05/2015)
SSR does not create vhdx , it creates v2i and iv2i
Also it shows a question mark and status "unavailable" because it is not able to access the destination.
I will request you to check if you are looking in right location to access the recovery points for restore.
Many times it happens the location for backup is changes and unknowingly we check into a different location instead of prescribed destination or the location if external usb is not attached.
send the screen shots of recovery points of SSR under \\188.8.131.52\backup
Thanks for your reply.
I have restarted our NASdrive and the status for all the backups has changed to green 'availablle'. However, the problem is still consistent. I have tried manually backing up to a different folder on the NAS in case it was a path problem with that folder. The same thing is occuring.
We are indeed getting v2i and iv2i files from SSR (See attached for our drive location). The backup takes an image of our entire server, we mount the iv2i file (Which has our Hyper1 on it), and then we mount the Hyper V to get access to our shared drive. However, when we mount it all the data inside the Hyper V is from 3 months ago and not recent.
Ive added some additional screenshots of what our company shared drive should look like, and what the backup shows.
I think if it shows 3 months old data, that means the data is not changing so frequently.
The incremental will backup only the changes made to the files and to me it seems there are no changes made to the files and so it shows 3 months old data.
There are changes made to a lot of the files everyday. Also we run a base recovery point every Monday then Tue-Fri it runs inceremental backups. If you compare the previous two screenshots that show the folders within our company shared drive, you can see the following folders/files are missing
I have since tried backing up to the desktop of the server instead of the NAS and the same thing is happening. However, I have also tried using another program called 'R-image' to see if that would work and the same problem is happening with that, which may suggest something else on the server is affecting it? I don't understand what would cause it being able to record new data if it is backing up a base recovery point? :s
I've installed all latest Windows updates on the physical and dc server and performed a restart. Now the status has changed back to 'unavailable' and I'm receiving an error. (Also restarted the nas as well. I am able to ping the nas and receive a reply)
“Description: Error EC8F17B7: Cannot create recovery points for job: Backup to NAS Drive.
Error EC8F03ED: Cannot create the recovery point.
Error E7D10041: Unable to establish a network connection to \\192.168.1.33\backup.
Error EBAB03F1: Following Operating System error occurred while performing requested operation: 'Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.'
Update: I managed to get it connecting to the NAS again and it is back to where I was before, where it will run a succesful backup. However the contents of hyper V contains old data.
In the mean time I have resulted to running R-Drive Image from the Hyper V to take a backup of our Company Shared drive and save to our NAS so we have an up to date backup of our data.
(As I mentioned before the SSR is run on our physical server Hyper1, tthis takes a full image including our Hyper V, which is our DC and contains our shared drive with all our company files on it.)
One thing I've noticed is that the contents of the backup that SSR is taking is actually up to date. However, our Hyper V .vdhx file when mounted is all old data with nothing recent. It shows last date modified 18/05/2015. I don't understand why the Hyper V contains outdated information? SSR was working fine for 9 months. Another thing I noticed, I don't know if this can effect how the hyper V is saved. Our last checkpoint on our VM is 18/05/2015. Does a new checkpoint need to be created each night before the hyper V can be successfully saved with up to date data? Or should this not effect it? (I will be creating a new checkpoint tonight after hours before it backup to test this, as well so we have a more up to date checkpoint.)