locked
Files reverting to previous versions overnight RRS feed

  • Question

  • Hello There,

    OpSys: WHS
    This is a WHS file share issue. Don't mark the question answered saying it's a general or access question.
    I suspect it has something to do with volume shadow copy or the file balance functions.

    I have an access database that is stored on my 'public' share. I can modify the file through the day and everything is fine. I goto bed and the next day, the file reverts back to a previous version. How can I prevent this from happening? You may need more information than that provided but I am unsure what to give you. Please help as this is costing me valuable time.

    Also, this happens with text files as well. I was working on some ASP files earlier today, I just went to work on them some more and they all reverted to previous versions and I lost all my changes.

    I am seriously considering redoing my drives in a normal raid fashion to correct this if I can't figure out what WHS is doing. The volume shadow copy is all I can see that may be causing this.

    Could someone point me to a whitepaper regarding volume shadow copy and how it functions on WHS? If I can read a bit about it, I will probably find my trouble.

    Thank You,
    Steven Harvey
    • Edited by Hexcellent Thursday, September 3, 2009 2:08 AM
    Thursday, September 3, 2009 1:56 AM

Answers

  • It only seems to happen to previously existing files. I have been backing up my work in a sub folder and it'll remain after the files revert.

    There is something i'm doing that isn't WHS normal. I have a script to copy all files from the shares to an external drive. I'm doing this because I don't fully trust the JBOD setup. I am now thinking that it is part of the problem. My script simply copies the files to the external drive after a comparison of the dates. If the date is newer, it copies to external. Basically my own little duplication process. It doesnt modify the archive bit to my knowledge. I can post the script if neccessary.


    The issue ended up being my script.
    • Marked as answer by Hexcellent Monday, September 7, 2009 10:22 PM
    • Edited by Hexcellent Monday, September 7, 2009 10:23 PM The issue ended up being my script
    Thursday, September 3, 2009 2:17 AM

All replies

  • Hello There,

    OpSys: WHS
    This is a WHS file share issue. Don't mark the question answered saying it's a general or access question.
    I suspect it has something to do with volume shadow copy or the file balance functions.

    I have an access database that is stored on my 'public' share. I can modify the file through the day and everything is fine. I goto bed and the next day, the file reverts back to a previous version. How can I prevent this from happening? You may need more information than that provided but I am unsure what to give you. Please help as this is costing me valuable time.

    Thank You,
    Steven Harvey

    That is definitely not normal.  Have you tried making a couple modifications, closing the database, then opening it again right afterwards to see if the modifications are still there?  What add-ins/apps do you have installed on your server?  Have you tried storing the file in a different share?
    Thursday, September 3, 2009 2:07 AM
    Moderator
  • It only seems to happen to previously existing files. I have been backing up my work in a sub folder and it'll remain after the files revert.

    There is something i'm doing that isn't WHS normal. I have a script to copy all files from the shares to an external drive. I'm doing this because I don't fully trust the JBOD setup. I am now thinking that it is part of the problem. My script simply copies the files to the external drive after a comparison of the dates. If the date is newer, it copies to external. Basically my own little duplication process. It doesnt modify the archive bit to my knowledge. I can post the script if neccessary.


    The issue ended up being my script.
    • Marked as answer by Hexcellent Monday, September 7, 2009 10:22 PM
    • Edited by Hexcellent Monday, September 7, 2009 10:23 PM The issue ended up being my script
    Thursday, September 3, 2009 2:17 AM
  • That is definitely not normal.  Have you tried making a couple modifications, closing the database, then opening it again right afterwards to see if the modifications are still there?  What add-ins/apps do you have installed on your server?  Have you tried storing the file in a different share?

    I can work on the files through the day without issues. To make a change, then open again right after or even an hour later, changes remain. I read somewhere that the volume shadow service does its snapshot every 6 hours. It would appear to me that this is the time the files revert.

    I have tried a couple addons but the only one I'm running right now is the power managment 'Grid Junction' addon.

    My public share is my 'working share. The other shares are, for the most part, static stores. I'll do a test on them to see what results I get.


    Additional info:
    I have 4 500GB drives
    One is the standard SYS and DATA partition
    The other three are additional added to the JBOD through the console.
    Disk managment reports I have 220GB available on the drives so I doubt it's a lack of space issue.
    My external drive is also a 500GB and isn't part of the JBOD array.

    Thanks for your replies.
    Steven Harvey
    Thursday, September 3, 2009 2:27 AM
  • I can work on the files through the day without issues. To make a change, then open again right after or even an hour later, changes remain. I read somewhere that the volume shadow service does its snapshot every 6 hours. It would appear to me that this is the time the files revert.

    Actually, it's every 12 hours (or, more precisely, noon and midnight).  However, it only happens if you have the OEM RTM version of WHS.  If you have an HP MSS or even a OEM license with PP1 slipstreamed, VSS doesn't run at all.

    I have tried a couple addons but the only one I'm running right now is the power managment 'Grid Junction' addon.

    Which ones did you install before?  Have you ever installed any apps on your server from the server desktop?  Is it just databases, or other file types as well?  Does it always happen (or just sometimes)?

    My public share is my 'working share. The other shares are, for the most part, static stores. I'll do a test on them to see what results I get.


    Additional info:
    I have 4 500GB drives
    One is the standard SYS and DATA partition
    The other three are additional added to the JBOD through the console.
    Disk managment reports I have 220GB available on the drives so I doubt it's a lack of space issue.
    My external drive is also a 500GB and isn't part of the JBOD array.

    Thanks for your replies.
    Steven Harvey

    Thursday, September 3, 2009 2:44 AM
    Moderator
  • Does this happen for all files or only for such in duplicated folders?
    If the later, it could eventually be, that the disks are out of sync and the next duplication brings the older copy back.
    Anything related in the server event log?
    Did you ever copy files directly to d:\shares instead of using the UNC patch?
    Which version is shown in the console under Settings/Ressources?
    Best greetings from Germany
    Olaf
    Thursday, September 3, 2009 7:11 AM
    Moderator
  • Have you also tried turning off you script to see if this may be causing an issue.

    Josh
    Thursday, September 3, 2009 2:37 PM
  • I still think your issue is an Office/Access issue, rather than a Windows Home Server issue. You should try the test that kariya21 has suggested; if the issue is related to leaving the file open for an extended period of time that will help to narrow things down. However, you should be aware that keeping files on your server open for long periods is not really supported; after 24 hours Windows Home Server will begin to complain if it can't access a file (due to locks held by other programs such as Access).

    And yes, you should post your script.

    I'm not on the WHS team, I just post a lot. :)
    Thursday, September 3, 2009 3:58 PM
    Moderator