We intend to do a server upgrade soon, and we need to determine the ideal minimum HD size.
laercio.espig wrote: We have basically 1 file with size 20 GB, plus 180 GB of external containers. Incremental backups are performed every hour and 2 more complete backups, one at night and the other at noon.
We have basically 1 file with size 20 GB, plus 180 GB of external containers. Incremental backups are performed every hour and 2 more complete backups, one at night and the other at noon.
Using external containers is a wise choice.
But the 20GB file probably isn't. Consider splitting it up along the lines of what data changes a lot and what doesn't. Just because we can have 1 million tables in a FM file doesn't mean that we should.
The design of the solution is a big factor in how efficient the deployment is going to be. With one file of 20GB, even if just one field in one record gets changed, the next backup needs to grab 20GB of disk space for the incremental or regular backup.
If 19GB of that was in static tables that you could split off into their own files and the field change happens in the 1GB split-off file then the same field change would mean that the next backup would only need to grab 1GB of free disk space to do the backup, *while* keeping your entire 20GB backup set intact. That's how efficient FMS backups works through hard-linking in the OS. This is a very neglected design area for most FM developers, it's very crucial when it comes to the deployment.
If you are not very familiar with how FMS uses disk space, then please ask more questions.
Please specify the server OS you will use and the expected annual growth rate of the database.
Thank you for your response / access.
Currently, our server is installed on Mac Pro 2013 OS High Sierra. Our main archive, including external containers, have 200 Gb in size and 65 users.
However, the physical space in HD is ending and the overall performance of the Mac is below our expectations. Many crashes and slowness are occurring lately, especially after upgrading to FM 17.
It seems to us that the FM version 17, in addition to spending more hardware resources, uses additional HD space to perform tasks such as backups, for example.
We will migrate to a windows server (HP-Proliant G8), already existing and available in our Datacenter. We will install an SSD / SAS disk system in Raid 1.
The question is how much optimal (minimum) space will be needed in HD, considering the current size of our file and number of users.
Thanks for any feedback.
ok, that makes it clearer. I am not a Win server expert but someone with hands-on experience like wimdecorte may chime in.
laercio.espig wrote:It seems to us that the FM version 17, in addition to spending more hardware resources, uses additional HD space to perform tasks such as backups, for example.
It doesn't so it would be crucial to understand what is happening and what you are experiencing, checked by the various logs to really see and quantify what is happening.
Make sure the FMS stats log is turned on and also turn on top call stats log, to verify what kind of bottlenecks you are hitting before deciding where to spend the money on.
laercio.espig wrote:The question is how much optimal (minimum) space will be needed in HD, considering the current size of our file and number of users.
The number of users is not a factor in deciding the size of the HD. The size of the HD depends on the size of the files, the frequency of the backups (both regular and progressive), the design of the solution and the nature of the user's interaction with the solution.
You mentioned 200GB total size of the solution but we don't know whether that is all in one file, multiples files and whether you are using the remote container feature.
One giant monolithic 200GB file would be the worst case scenario. That would call for a redesign of the solution to break it up into multiple files so that you can take advantage of FMS's native backup efficiency.
So give us a little more info on how the solution is put together and how often you want to do backups.
Thank you for you answer.
Thank you. Your information was very helpful.
Retrieving data ...