2 Replies Latest reply on Oct 20, 2010 9:39 AM by thomasseidler

    Occasional performance degradation during scheduled backup verification

    thomasseidler

      Title

      Occasional performance degradation during scheduled backup verification

      Your post

      Dear all,

       

      I am using FMSA 11, on 10.5.8 (java version: 1.5.0_13), 4GB RAM, on a Mac Pro with a Boot RAID 0 on two discs (on to which backup data goes), and FMP Data RAID 0 on two other discs.

       

      The DB I schedule a backup for every 20 minutes is about 900MB, it takes under 10 seconds to back up. It takes 5 minutes to verify.

       

      Throughout this verification process (w/o which I have found backups to be pointless), we have noticed significant performance degradation on occasion - though by no means consistently. For instance a query on an indexed field across 100k records takes 2 minutes, whereas after verification is complete it takes but a milli-second.

       

      It is worth noting that the same query performed via ODBC worked w/o degradation.

       

      If there is a known fix/understanding of this issue, please let me know. Else FileMaker please fix (though I will post as a bug if no response in a month)....

       

      Thank you,

       

      Tom

       

       

      Thomas Seidler

      The Good Book Company Ltd

      www.thegoodbook.co.uk

        • 1. Re: Occasional performance degradation during scheduled backup verification
          philmodjunk

          Filemaker recommends that you not enable verification for hourly or more frequent back ups because the verification process can degrade performance.


          What we do is use two schedules:

           

          One schedule backs up hourly and does not verify. These hourly back ups are not retained more than 48 hours as hourly backups cycle through and  are replaced. They are used only in the case of a crash for the purpose of importing data into a known good clone.

           

          A second schedule backs up and verifies each evening during minimum traffic hours. These files are retained for one month, with one copy each month copied to an archive folder for indefinite storage.

          • 2. Re: Occasional performance degradation during scheduled backup verification
            thomasseidler

            @PhilModJunk - thanks for that.

            I also read your response to http://forums.filemaker.com/posts/55e14298bf as I continue to consider this problem. I believe it should be added to the bug list, as the ODBC comparison I state (but forgot about till now) does indicate there is an issue of coding.

            i used to do no verificaiton on my 20 minutely backups, then they died two or three times during day, and lost data. Losing a days worth of data is a pain. So I'd like to verify all the time. But not possible really for performance degradation noted.

            I haven't had it corrupt though since I stopped working on schema via WAN, I now just do it over LAN, and much more stable... I think for usesability am going to have to do as u've done and switch to verifying only daily backups, as opposed to my 20 minute backups. If only there were an offline tool that we could run on another computer to check the integrity of the 20 minute back up files, then i'd never lose more than an hours data or so, which is an easily survivable experience! Though I see why it has to be on FMS computer since the KB article says it is comparing it with live file.

            The performance degradation does surprise me however, it now takes 6 minutes to do the verificaiton of a 900MB db (admittedly now very complex). However, the processors even during initial backup are running at no more than 40%. Running on Quad 2Ghz Xeon Mac Pro, copying raptor striped RAID to decent striped RAID. 4GB RAM is only thing that is fully consumed. Disk activity during process is totally underwhelming... i was expecting it at least to burn up its energy and get the task done fast, but I get seriously degraded performance from a machine that is still tootling/ambling along - as it appears from an analysis of its vital signs via Activity Monitor. This is not expected/good surely?

            Some sort of non-FMServer tool that just did a basic file integrity test would be appreciated as a piece of mind for backups during the day. One wants to catch total failure as soon as possible! ;)

            Cheers, T