none
Ignoring "System Volume Information" RRS feed

  • Question

  • Hi,

    I am working on a backup application which has an upper volume filter driver based on diskperf and one user app. My driver actually monitors the sectors that are modified and sets the respective blocks in a bitmap.

    I have a drive which is of 50 Gb and the used space is around 200 Mb.
    My problem is when my user application backup this drive, the size of the backed up data is 2Gb though only 200 Mb is occupied. I am assuming that folder "System Volume Information" is occupying those major space because when I checked it, I saw a file of around 1.5 Gb inside it.

    Can anyone tell me that whether its safe not to backup the "System Volume Information" folder? Does it will create any issue while restoring the data?

    Also how can I know which all blocks or sectors are being used by the "System Volume Information" folder, so that I can ignore those blocks? I tried to use "FSCTL_GET_RETRIEVAL_POINTERS" but was not successful, didn't got the desired result.

    Awaiting a positive response.
    Thanks in advance.
    Monday, April 28, 2014 9:56 AM

All replies

  • The SystemVolumeInformation directory stores the data for system restore.  I don't know what your backup is supposed to do but I would be bothered if your backup did not allow me to do everything on the system I normally would have done.

    You state you cannot get the retrieval pointers for the folder, what user are you running as?  The items in that folder and the folder itself are owned by the system, so if your user space application is running as a service with the system user you should be able to access them.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, April 28, 2014 10:40 AM
  • Hi,

    As we are actually backing up the data so is it possible if we exclude the "System Volume Information" folder as it actually stores the data for system restore, some indexes, volume snapshot, etc. Does it relates to any files?

    For eg: If we are backing up 100s of files and folders from D: drive and not the "System Volume Information" folder, so will there be any issue when restoring those 100s of files and folders into D:, is there any link?

    Note: We will be giving an option to backup the "System Volume Information" folder to the admin

    Actually why we are considering not to backup that folder is due to the backup data size, which is huge, I explained it in my original post too. We are actually backing up the data from a volume snapshot, so every time before backup, a snapshot is created, so that is why the size of the "System Volume Information" folder increases.

    For eg. if there are only 2-3 blocks modified, so the data size should be (3*4096) but every time the backed data size will be around 15-25 Mb. So that is why we are planning to give an option to avoid the complete folder.

    >You state you cannot get the retrieval pointers for the folder, what user are you running as?  The items in that folder and the folder itself are owned by the system, so if your user space application is running as a service with the system user you should be able to access them.

    Actually at present the user app is not running as a service but with admin rights. So is it necessary to run it as a service?

    • Edited by PeterHaskin Monday, April 28, 2014 11:34 AM
    Monday, April 28, 2014 11:31 AM
  • The application needs to be run with the system account.  The easiest way to do this is a service.  The System Volume Information folder contains data about registry changes, and file changes.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, April 28, 2014 11:49 AM
  • Hi, Thanks.

    So can we skip the "System Volume Information" folder? is it possible to skip at the kernel level or it should be done at the user side?

    And the "FSCTL_GET_RETRIEVAL_POINTERS" will give only starting sector and block no., not all the blocks occupied by the files/folders, is there any function for the same?

    And actually where the volume snapshot gets stored? I am assuming that every time the snapshot is taken, its respective blocks are set in our bitmap and we backup data from those blocks too. Can those blocks be skipped and how?

    Monday, April 28, 2014 12:01 PM
  • Hi,

    @ Pavel A: We are working on a block based backup app which is capable to restore the data to the same disk and also on other disk.

    Monday, April 28, 2014 1:01 PM
  • What do you mean only the starting sector and block number.  FSCTL_GET_RETRIEVAL_POINTERS gives a list of segments, i.e. starting block number for N blocks of data, followed by another such segment to describe the file.  I.E.  It gives the information on every block in the file.

    I would process System Volume Information in a standard manner because:

    1.  It is not the only file that has system as its owner / only accessible by owner

    2.  If the user is not doing something that impacts a restore point (normal case) then there is no harm in doing it.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Monday, April 28, 2014 1:07 PM
  • Hi,

    @Don Burn: Yes, its mistake in understanding "FSCTL_GET_RETRIEVAL_POINTERS ", it does gives all the blocks.

    Now there is a problem, I am running my App under SYSTEM account and traversing the "System Volume Information" folder completely to retrieve all the blocks, but I am unable to successfully obtain handles on certain files (though I am able to obtain certain handles and get their blocks.), I am getting error 5(ERROR_ACCESS_DENIED). What can be the possible cause?

    Note: The files are "{77f0b013-d2b2-11e3-93dd-08002787ce8e}{3808876b-c176-4e48-b7ae-04046e6cc752}" and its size is 2.3 gb and the other file is "{3808876b-c176-4e48-b7ae-04046e6cc752}" which is of 64 kb.

    Saturday, May 3, 2014 12:18 PM
  • There is a decent chance the files are opened exclusively.  One approach is to provide helper support in the driver for the app.  The driver can do a:

    ZwOpen with access SYNCHRONIZE

    Then ObReferenceObjectByHandle to get the pointer

    Then ObOpenObjectByPointer with the access you need


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Saturday, May 3, 2014 12:28 PM
  • >One approach is to provide helper support in the driver for the app

    Do you mean I need to add the above functions that you suggested in my upper volume filter driver?

    If yes, then how it would be helpful to give my user app the required permissions to open the handles successfully for those files?

    >ZwOpen with access SYNCHRONIZE

    Also, for "ZwOpenFile" what file name I need to pass in the "ObjectAttributes"?

    And is their any other possible solution which can be done at the user side?

    Saturday, May 3, 2014 12:51 PM
  • Either add them to the uppoer volume filter or provide a second driver.  You can create a request that will successfully open the file for your application,  you would pass in the file name that you would normally use.

    Depending on what you are doing with the handle, you can do the open in user space with the access being SYNCHRONIZE, this may or may not work.


    Don Burn Windows Filesystem and Driver Consulting Website: http://www.windrvr.com Blog: http://msmvps.com/blogs/WinDrvr

    Saturday, May 3, 2014 1:05 PM