Can an image based backup potentially corrupt data? – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.
But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about windows, backup, image, acronis, .
I’m considering doing image based backups (Acronis) on production Windows systems during non-peak hours. I’m just wondering if they can potentially lead to application data corruption. Lets say that I have a database that is getting hit pretty hard. Could I potentially have the beginning blocks of the database be commit ed to the image, data inserted into the db (which changes the beginning blocks of the DB on the server but not the image), then the blocks of data committed to the image (leading to an inconsistent state).
Here’s an example of what I’m trying to illustrate. Imagine a simple data structure which has a number in the front which represents the number of “a”s in a file. The number and data are delimited by a “-“. For example:
If an “a” is changed, the datastructure resets the number in the begining of the file such as:
I assume acronis writes block by block being a straight up image so here is what i’m invisioning happening with my database
t0: 4-ajjjjjjjajuuuuuuuaoffffa ^pointer is here t1: 4-ajjjjjjjajuuuuuuuaoffffa ^pointer is here (all data before this is comitted to the image) t2: 4-ajjjjjjjajuuuuuuuboffffa ^pointer is here (all data before this is comitted to the image) Also notice how one of the "a"s change to a b. There are only 3 "a"s now t3: 4-ajjjjjjjajuuuuuuuboffffa ^pointer is here (all data before this is comitted to the image)
The final image now reads “4-ajjjjjjjajuuuuuuuboffffa”, while the true data is “3-ajjjjjjjajuuuuuuuboffffa” leading to a corrupt “database”.
Basically changes further down the blockchain could be reflected in the image, while important header and synchronization could already be committed. The out of date header information doesn’t accurately reflect the structure of the blocks to come.
What happens here is for acronis and almost all backup software is the use of the volume shadow service. Various applications like SQL and exchange server have their own VSS writer as well.
http://blog.macrium.com/2012/11/backup-internals-what-is-vss-how-does-it-work-and-why-do-we-use-it/ has a pretty good overview of how it works.
Basically acronis will tell windows do create a snapshot. From then on when a program changes a file the original data is saved to shadow storage. When acronis gets to that part of the file vss gives it the original version from the shadow storage instead of the updated one all the regular programs see.
When it all works properly you end up with a copy of exactly what you would have gotten if you pulled the plug on the server and did the backup offline. VSS aware applications like SQL get a chance before the snapshot is created to save anything that needs saving to help avoid inconsistent data. Other programs could have corrupt data in the backup if they were right in the middle of writing a file, but since the snapshot happens quickly that is rare, and no worse than if power was lost and the server rebooted.