[FX.php List] Do RackSpace "Snapshots" conform to Best Practices?

[Jonathan Schwartz]

Here's a Post Mortem....

The memory upgrade process was successful using SnapShots, with a few 
bumps in the road.

- The process took about 20 minutes for each machine, not 2.5 hours. 
We spent more time checking the system over after the fact than the 
process itself took.

- FMS Console was hosed after the process.  Web Publishing was 
working but FMS Console said it wasn't.  A quick re-deployment of Web 
Publishing on the FMS Master machine solved that.

- The FileMaker db files opened without incident, even though they 
were copied live during the snapshot process.  A contributing factor: 
The web traffic was minimal at 3AM. Plus there were no writes to the 
files going on. Just reads.  Nevertheless, the files were tossed and 
replaced with files taken as backup just before the process started. 
The IT staff challenged the need for this one more time, since things 
appeared to be working OK.

- I have requested this new India IT team to test the assumption that 
snapshots of FileMaker virtual instances will actually be usable 
immediately in the case they are needed for recovery.  Based on this 
experience, I would say not.  At least, not without some expert FM 
Developer supervision to fix broken stuff.

Hope that is helpful to you all.

Thanks again for the help.

Jonathan


>Agreed.
>
>Jonathan
>
>
>At 2:12 PM -0600 3/9/12, Anders Monsen wrote:
>>If I had a nickle for every time I've spoke with IT departments who 
>>want to manage servers their way with no idea of the impact on 
>>FileMaker...and then go ahead and do what they want without 
>>listening anyway.
>>
>>Closing the dbs and shutting down the server prior to the snapshot 
>>should not take them more than 5-10 minutes. Is saving that time 
>>worth the cost of potential db corruption?
>>
>>Anders
>>
>>On 3/9/12 1:26 PM, Jonathan Schwartz wrote:
>>>Perfect!  Just the feedback I was looking for.
>>>
>>>In this case, it is a third party India-based developer company 
>>>with no FileMaker experience that is challenging the need to 
>>>shutdown FMS, even though I have explained that the risk is high 
>>>and the cost of downtime low.
>>>
>>>I knew I could count on my fellow fx.php'rs.
>>>
>>>Jonathan
>>>
>>>>I don't know, I haven't dealt with hot-adding memory to a virtual 
>>>>machine so I can't say whether this snapshot stuff they talk 
>>>>about is something of concern or not.
>>>>
>>>>What I would say though is that regardless of how *they* do 
>>>>things you should have your own backup of the data on that 
>>>>machine, so it can easily be restored if they fail.
>>>>
>>>>One would think that they know what they're doing and that it's 
>>>>not the first time they've done this on a VM they maintain :o
>>>>
>>>>In any case I don't see why they or you cannot just shut the 
>>>>machine down, change memory, and then turn it on again. Have them 
>>>>do that and there shouldn't be much to worry about. If they 
>>>>refuse, switch to another hosting provider :)
>>>>
>>>>
>>>>9 mar 2012 kl. 19.20 skrev Jonathan Schwartz:
>>>>
>>>>>  Hi Folks,
>>>>>
>>>>>  I need a quick weigh-in from FileMaker experts on the list.
>>>>>
>>>>>  One of my clients has moved FileMaker Web Publishing to third 
>>>>>party RackSpace, which uses virtual servers under Windows.
>>>>>
>>>>>  After a week of trying to run FMS on only 2gb ram, they have 
>>>>>agreed to upgrade the instance to 4gb.  The upgrade process 
>>>>>consists of an automated system that takes a "snapshot" of the 
>>>>>server and then rewrites the "snapshot" once the memory has been 
>>>>>upgraded.
>>>>>
>>>>>  I contend that taking the "snapshot" is the same as copying 
>>>>>live FIleMaker Server files, and in violation of FileMaker 
>>>>>Server Best Practices.  I am urging them to shut down FileMaker 
>>>>>Server and do the upgrade with it shut down.  Others are saying 
>>>>>the the "snapshot" approach is OK.
>>>>>
>>>>>  Does anyone have experience with snapshots or RackSpace or both?
>>>>>
>>>>>  Need a quick answer, as I am standing on the tracks refusing to 
>>>>>budge....for the good of the data. ;-)
>>>>>
>>>>>  Thanks
>>>>>
>>>>>  Jonathan
>>>>>
>>>>>
>>>>>  --
>>>>>  Jonathan Schwartz
>>>>>  Exit 445 Group
>>>>>  jonathan at exit445.com
>>>>>  http://www.exit445.com
>>>>>  415-370-5011
>>>>>  _______________________________________________
>>>>>  FX.php_List mailing list
>>>>>  FX.php_List at mail.iviking.org
>>>>>  http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>
>>>>
>>>>
>>>>-|
>>>>
>>>>_______________________________________________
>>>>FX.php_List mailing list
>>>>FX.php_List at mail.iviking.org
>>>>http://www.iviking.org/mailman/listinfo/fx.php_list
>
>
>--
>Jonathan Schwartz
>Exit 445 Group
>jonathan at exit445.com
>http://www.exit445.com
>415-370-5011
>_______________________________________________
>FX.php_List mailing list
>FX.php_List at mail.iviking.org
>http://www.iviking.org/mailman/listinfo/fx.php_list


-- 
Jonathan Schwartz
Exit 445 Group
jonathan at exit445.com
http://www.exit445.com
415-370-5011