Let me preface this, my first posting to this forum, with a hearty thank you to all those responsible for the excellent User Guide available for FreeNAS and for the tenor and content of the replies posted in your forums. I am not new to forums and could only wish for comparable civility and thoughtfulness of dialog in the scores of others upon which I depend. The results -- well-organized, well-presented documentation, and a spirit of helpfulness -- do not come automatically to a community, so the sponsors and supporters of this one deserve our appreciation and applause.
That said, the second thing I feel I need to do is to create this entirely new, entirely separate thread for my own benefit, and, I think, for that of others. I have spent a quite a few hours searching, reading, and considering what I have learned about the topic at hand, and I would guess that, it might be possible to piece together a reasonably good answer to my question from what is elsewhere presented. If I could do that, 100% successfully, I assure you, I am far too old to have any lingering 15-minutes of fame syndrome that would drive me to pressing for a separate thread. I am doing so because I was not able to find the answers to the various questions that I have about the best way to go about building a server to meet the limited needs that are absolutely the heart of the problem I am trying to solve.
So, if it is not completely clear from the title I have invented for the topic, let me spell it out. I am purposely trying to circumscribe the problems in order to arrive at a baseline that will be completely adequately served by the software/hardware thrown at it. I realize, and appreciate that good counsel from any professional in this field would raise some caveats about trying to so tightly constrain the definition of the tasks that the useful system life might be needlessly shortened. Thank you. Let's take it for a given that a correctly-architected, correctly-sized solution that one of you might suggest will include parameters that will allow for some reasonable amount of increased data volume, network traffic, and even mix of host operating system clients, and not consume too much time and energy debating those matters. I am not trying to cut out discussion of interesting considerations, just to save everyone's precious time by acknowledging that due diligence of concern for moderate growth will be assumed.
Along those same lines, but from a slightly different perspective, I would like to take off the table the seemingly inevitable concern about whether or not someone, like me, looking for a low-cost, simple to administer solution is being penny wise and pound foolish. There are quite a few threads in which accomplished professionals well-defend the point that trying to save a few bucks where doing so needlessly increases the possibility of loss of data, is probably not a good idea. So, let's just accept it as given that I am not trying to constrain the definition of the problem, nor the suggested range of recommendations to save money. It is true that, for me, and for the large set of friends and family for whom I am hoping to provide a good backup system, as we do not really fall under any umbrella of SOHO, we do not tend to cost justify our investments in terms of any revenue opportunities. Yes, budgets matter, and whereas you might be inclined to think that, absent a business model, there is not a very strong motivation for investing in a sound backup system, I am here to tell you that most of us ordinary moms and dads, aunts and uncles, grandfathers and grandmothers, are talking about digital assets that we value as highly as any corporate data sets, intellectual property, or customer contacts. So, we don't expect a zero-cost insurance policy that will secure our family records. We are willing to spend. We're here to get your professional experience in helping us spend on what matters, and not spend on that which does not.
These are, I think, the essential operational parameters of the style of backup I want to put in place:
A. The household has Windows-based, MacOS-based, and sometimes some *nix-based desktops and laptops.
B. Inevitably, some of the OSes running in our local LANs will be a release or two behind what may be considered current.
C. Each client, today, is usually configureed with its own disk drive configuration, appropriate to the work that usually goes on there. That is, the box was usually purchased and viewed as a personal computer, so if data integrity was important, some form of RAID or some form of backup strategy is probably already in use at that node. Yet, it is a home network, so yes, of course, SAMBA or some equivalent is normally being used to share mounted file systems across the LAN giving the possibility/probablilty of read-write activity 'coming at some hard disk' from anywhere.
D. What we have learned over the past two decades is that that arrangement is exacerbating the problem of the relatively low MTBF of our individual disk drives. That arrangement is causing boxes never built to be servers, to remain powered up for long, long periods of time. No, its not as bad as the short-hand of 365x24x7, but it ought to come as no surprise that I can walk around any number of such household conglomerations and run S.M.A.R.T. reports that will show a drive as having been spinning in excess of 40,000 hours, and most of that time at ambient temperatures above 125 degrees F.
E. That provides the context for the better solution we are seeking. We want to, in general, reduce the amount of local disk and concentrate what we have in a server configuration. BUT, we will also consciously change our expectation about what is available. I am not talking about just relocating the existing file systems to a box off in a corner, but retaining the same usage pattern. While it is inevitable that some other files will end up 'out there', I am asking your help in configuring the most cost-effective, low-power-consuming solution just for regularly-scheduled backups.
F. I accept the fact that the proposed solution will provide NO protection from the loss of data during the working day. Absent any specific workflow that the user may impose by way of self discipline with whatever software tools he may be using, if some change is made at 10AM and the local system experiences a failure at 2PM, that work will have been lost. We can live with that.
G. What is desired is to provide end-of-day backup during the quiescent nighttime. What I hope that means is that the 24x7 powered up condition of the FreeNAS server will mostly be in idle mode. What I hope is that, with no other intervention/control than the arrival of incoming data, the drives on the FreeNAS server will mostly spend their time consuming the least amount of electrical energy and physical rotation as that type of drive is capable of 'keeping alive'.
H. Let me restate that, in case I have just confused matters. Users turn their individual computers on and off depending upon their needs, but the server box and all its peripherals are powered on until the family goes on vacation.
If that general description of the mode of operation leaves other parameters of the problem insufficiently defined, please shoot any question back at me that would help us get to some suggested solution. I know you will want to have some estimate of total file space requirements -- I can also make that simpler than seems to be the most common sort of use case found in the closely-related threads of this forum This is NOT a media streaming center. Sure there are copies of a hundred movies running around, maybe a thousand mp3 files, but the server is only being asked to preserve a good backup to that media -- not to serve it real time. For entry level purposes and for the majority of our homes, present-generation 2-4TB hard drives can be assumed to meet the next five-year planning horizon for the solution. I don't want to make a guess that would be dumb, but I believe that an enclosure that maxed out at 4 SATA drive bays would be more than adequate.
As to the data bandwidth aspect of the problem sizing, if I understand rsync's intelligence, after priming the backup at system start-up, nightly data transfers will easily complete across Gigabit CAT-6 cables in an assumed window between 2AM and 5AM.
I have clearly gone on to more than you probably want. I hope that by being complete, by avoiding ambiguous acronyms, I have been able to describe a distinct target. I hope that more than one of you will identify enough with this admittedly low-end, un-challenging, non-state-of-the-art requirement, and make it easy for you to offer some specific recommendations in at least these categories:
A. Processor, and with that, of course, appropriate motherboard. I know and am comfortable with building bare bones with Intel Core processors, but is this really a job for their Atom offerings?
B. RAM -- I have already got it that ZFS really wants 16GB, but, given the simple, scheduled workload anticipated here, isn't it likely that 8GBs will really be more than it will use anyway? As a guy who worked on IBM 360s when our main memory was still 18-mil ferrite cores, you don't have to sell me on ECC, but since I am not going to use Xeon processors, and since a failure in the server's disk farm is most likely to be caught during backup, from which recovery would be to replace the failing drive, and restart, is ECC really going to matter?
C. Drives. Again, taking into account that these drives are mostly idle, and when they are not idle, they are mostly running write operations to whole contiguous blocks of data, what rotational spec and seek times will really be important?
D. Cooling. I will always be able to place this server/enclosure somewhere less intrusive than what exists today where my workstation is running 24x7 three feet from my bed, so I am not worried about fans. Fan placement and size, it seems ought to get special consideration for this use case, but maybe any mid-tower would get the job done.
E Monitor. I guess it is usually the case that you successfully administer a FreeNAS system via a remote login protocol, but there must be times, especially the stressful ones, when you are getting started, when a locally-attached monitor and keyboard would really be useful. Given that I will always have a light-weight monitor and keyboard nearby, since I don't know the Atom [or even Raspberry PI] space, would it be important not to cut corners so sharply that I could not plug in a monitor and keyboard?
Many thanks to anyone who has managed to stay with my pleading request for your best advice.
That said, the second thing I feel I need to do is to create this entirely new, entirely separate thread for my own benefit, and, I think, for that of others. I have spent a quite a few hours searching, reading, and considering what I have learned about the topic at hand, and I would guess that, it might be possible to piece together a reasonably good answer to my question from what is elsewhere presented. If I could do that, 100% successfully, I assure you, I am far too old to have any lingering 15-minutes of fame syndrome that would drive me to pressing for a separate thread. I am doing so because I was not able to find the answers to the various questions that I have about the best way to go about building a server to meet the limited needs that are absolutely the heart of the problem I am trying to solve.
So, if it is not completely clear from the title I have invented for the topic, let me spell it out. I am purposely trying to circumscribe the problems in order to arrive at a baseline that will be completely adequately served by the software/hardware thrown at it. I realize, and appreciate that good counsel from any professional in this field would raise some caveats about trying to so tightly constrain the definition of the tasks that the useful system life might be needlessly shortened. Thank you. Let's take it for a given that a correctly-architected, correctly-sized solution that one of you might suggest will include parameters that will allow for some reasonable amount of increased data volume, network traffic, and even mix of host operating system clients, and not consume too much time and energy debating those matters. I am not trying to cut out discussion of interesting considerations, just to save everyone's precious time by acknowledging that due diligence of concern for moderate growth will be assumed.
Along those same lines, but from a slightly different perspective, I would like to take off the table the seemingly inevitable concern about whether or not someone, like me, looking for a low-cost, simple to administer solution is being penny wise and pound foolish. There are quite a few threads in which accomplished professionals well-defend the point that trying to save a few bucks where doing so needlessly increases the possibility of loss of data, is probably not a good idea. So, let's just accept it as given that I am not trying to constrain the definition of the problem, nor the suggested range of recommendations to save money. It is true that, for me, and for the large set of friends and family for whom I am hoping to provide a good backup system, as we do not really fall under any umbrella of SOHO, we do not tend to cost justify our investments in terms of any revenue opportunities. Yes, budgets matter, and whereas you might be inclined to think that, absent a business model, there is not a very strong motivation for investing in a sound backup system, I am here to tell you that most of us ordinary moms and dads, aunts and uncles, grandfathers and grandmothers, are talking about digital assets that we value as highly as any corporate data sets, intellectual property, or customer contacts. So, we don't expect a zero-cost insurance policy that will secure our family records. We are willing to spend. We're here to get your professional experience in helping us spend on what matters, and not spend on that which does not.
These are, I think, the essential operational parameters of the style of backup I want to put in place:
A. The household has Windows-based, MacOS-based, and sometimes some *nix-based desktops and laptops.
B. Inevitably, some of the OSes running in our local LANs will be a release or two behind what may be considered current.
C. Each client, today, is usually configureed with its own disk drive configuration, appropriate to the work that usually goes on there. That is, the box was usually purchased and viewed as a personal computer, so if data integrity was important, some form of RAID or some form of backup strategy is probably already in use at that node. Yet, it is a home network, so yes, of course, SAMBA or some equivalent is normally being used to share mounted file systems across the LAN giving the possibility/probablilty of read-write activity 'coming at some hard disk' from anywhere.
D. What we have learned over the past two decades is that that arrangement is exacerbating the problem of the relatively low MTBF of our individual disk drives. That arrangement is causing boxes never built to be servers, to remain powered up for long, long periods of time. No, its not as bad as the short-hand of 365x24x7, but it ought to come as no surprise that I can walk around any number of such household conglomerations and run S.M.A.R.T. reports that will show a drive as having been spinning in excess of 40,000 hours, and most of that time at ambient temperatures above 125 degrees F.
E. That provides the context for the better solution we are seeking. We want to, in general, reduce the amount of local disk and concentrate what we have in a server configuration. BUT, we will also consciously change our expectation about what is available. I am not talking about just relocating the existing file systems to a box off in a corner, but retaining the same usage pattern. While it is inevitable that some other files will end up 'out there', I am asking your help in configuring the most cost-effective, low-power-consuming solution just for regularly-scheduled backups.
F. I accept the fact that the proposed solution will provide NO protection from the loss of data during the working day. Absent any specific workflow that the user may impose by way of self discipline with whatever software tools he may be using, if some change is made at 10AM and the local system experiences a failure at 2PM, that work will have been lost. We can live with that.
G. What is desired is to provide end-of-day backup during the quiescent nighttime. What I hope that means is that the 24x7 powered up condition of the FreeNAS server will mostly be in idle mode. What I hope is that, with no other intervention/control than the arrival of incoming data, the drives on the FreeNAS server will mostly spend their time consuming the least amount of electrical energy and physical rotation as that type of drive is capable of 'keeping alive'.
H. Let me restate that, in case I have just confused matters. Users turn their individual computers on and off depending upon their needs, but the server box and all its peripherals are powered on until the family goes on vacation.
If that general description of the mode of operation leaves other parameters of the problem insufficiently defined, please shoot any question back at me that would help us get to some suggested solution. I know you will want to have some estimate of total file space requirements -- I can also make that simpler than seems to be the most common sort of use case found in the closely-related threads of this forum This is NOT a media streaming center. Sure there are copies of a hundred movies running around, maybe a thousand mp3 files, but the server is only being asked to preserve a good backup to that media -- not to serve it real time. For entry level purposes and for the majority of our homes, present-generation 2-4TB hard drives can be assumed to meet the next five-year planning horizon for the solution. I don't want to make a guess that would be dumb, but I believe that an enclosure that maxed out at 4 SATA drive bays would be more than adequate.
As to the data bandwidth aspect of the problem sizing, if I understand rsync's intelligence, after priming the backup at system start-up, nightly data transfers will easily complete across Gigabit CAT-6 cables in an assumed window between 2AM and 5AM.
I have clearly gone on to more than you probably want. I hope that by being complete, by avoiding ambiguous acronyms, I have been able to describe a distinct target. I hope that more than one of you will identify enough with this admittedly low-end, un-challenging, non-state-of-the-art requirement, and make it easy for you to offer some specific recommendations in at least these categories:
A. Processor, and with that, of course, appropriate motherboard. I know and am comfortable with building bare bones with Intel Core processors, but is this really a job for their Atom offerings?
B. RAM -- I have already got it that ZFS really wants 16GB, but, given the simple, scheduled workload anticipated here, isn't it likely that 8GBs will really be more than it will use anyway? As a guy who worked on IBM 360s when our main memory was still 18-mil ferrite cores, you don't have to sell me on ECC, but since I am not going to use Xeon processors, and since a failure in the server's disk farm is most likely to be caught during backup, from which recovery would be to replace the failing drive, and restart, is ECC really going to matter?
C. Drives. Again, taking into account that these drives are mostly idle, and when they are not idle, they are mostly running write operations to whole contiguous blocks of data, what rotational spec and seek times will really be important?
D. Cooling. I will always be able to place this server/enclosure somewhere less intrusive than what exists today where my workstation is running 24x7 three feet from my bed, so I am not worried about fans. Fan placement and size, it seems ought to get special consideration for this use case, but maybe any mid-tower would get the job done.
E Monitor. I guess it is usually the case that you successfully administer a FreeNAS system via a remote login protocol, but there must be times, especially the stressful ones, when you are getting started, when a locally-attached monitor and keyboard would really be useful. Given that I will always have a light-weight monitor and keyboard nearby, since I don't know the Atom [or even Raspberry PI] space, would it be important not to cut corners so sharply that I could not plug in a monitor and keyboard?
Many thanks to anyone who has managed to stay with my pleading request for your best advice.
