我正在我们的实验室服务器上安装一个新的Ubuntu。 我们有许多庞大的基因组需要由Apache www数据用户访问。 目前我支持外部驱动器上的所有数据。 我的目标是拥有一个全新的Ubuntu，在其上安装新的Web应用程序，然后导入丢失的旧数据，以便Apache将这些数据提供给使用这些新应用程序的用户。 用户也会上传文件。 优先事项是保持简单，以便新的未来系统pipe理员可以轻松地赶上事情在服务器上的工作方式。 我目前的计划：
1）有实验室的人（我不在状态）刻录Ubuntu ISO光盘，从它启动机器，并执行基本的Ubuntu安装 ，为我设置SSH访问。 她会重新格式化内部磁盘，除了位于独立分区上的/ home文件夹。
2）从旧安装迁移用户; 手动清理/ home（旧）文件夹中不必要的数据。 用它replace新的/ home文件夹。
3）安装LAMP，networking应用程序和其他必要的软件。
4）创build/ home / user / webdata文件夹，给Apache用户所有的权限。 在里面，创build网站用户上传文件的上传/文件夹。 在它旁边将是包含物理位于外部驱动器上的基因组的符号链接的基因组/文件夹。 Apache将从这个文件夹为用户提供基因组。
5）设置/ home / user / webdata /的自动备份，并把这个东西联机。
我没有系统pipe理的经验，所以我有以下怀疑：
a）以任何方式保持步骤4中描述的数据较差吗？ 存储和服务大型基因组以及用户上传的最常见和有效的方式是什么？ 我应该在/ var / www / html下面有这个webdata /文件夹吗？ 还是应该不使用符号链接，并将内部驱动器上的基因组（/ home或/ var）？ 我不喜欢/ var的一个原因是因为将所有东西放在/ home下面都是简单而安全的。
b）是否可以更改或添加其他任何步骤以使过程更安全和更专业？
非常感谢你的支持，让我知道我是否应该提供任何补充信息。
对我来说，有一个上传文件夹和一个基因组文件夹的文件结构听起来很基于我设置的webapps的标准。
这是一个真正以系统pipe理员为中心的观点，但对于我来说，从软件/应用程序的angular度来看，文件结构的组织是重要的，物理设置将对冗余性，可靠性和性能产生更大的影响 – 在衡量“专业性“的设置。
我可能有一些build议：
1.）如果可以，请购买小型NAS。 外部驱动器没有任何冗余，速度会有所不同，特别是如果您有多个用户在同一磁盘上读取/写入数据。
2.）考虑使用外挂数据的挂载点，并指向Apache。 如果您坚持使用基因组/上传结构，您可以考虑将外部存储挂载到这些文件夹，或者将符号链接到/ mnt目录上的共享。
3.）真正考虑读写操作和你服务的用户数量。 如果侏儒很大，而且你将要进行很长时间的连续读取，那么把这些数据放在一个单独的卷/一组磁盘上，与更多的写入“上传”文件夹分开。 如果必须坚持使用单个磁盘或多个单独的磁盘，则可以将数据分离到单独的磁盘上，将基因组数据放在一组磁盘上，然后上传到另一个磁盘上。
正如John所说，从系统pipe理员的angular度来看，物理设置比文件和文件夹的“组织”更重要，因为这对系统pipe理员关心的事情有最大的影响 – 可靠性，性能，可伸缩性，可pipe理性，监控，冗余，DR /备份等
把东西设置成“正确”并将用户迁移的想法是一个好主意。 我要做的第一件事就是尝试在RAIDarrays上获取数据，这样当驱动器不可避免地发生故障时，不会丢失数据或停机。 我是硬件RAID的支持者，但是Linux软件RAID并不是完全可怕的 – 你希望在服务器级别增加一些冗余级别，并提高正常运行时间。 （说到正常运行时间，我希望有一个UPS送入这台服务器…）
接下来，我将为此function设置一些辅助服务器。 （按照优先顺序），我会尝试设置一个集群，[听起来客户面临或影响]或故障转移，甚至热备用服务器。 （准备就绪的服务器，等待在原始模具死亡的时候按下服务）。 当电源耗尽或主板被短路时，具有数据冗余function将无济于事。
最后，一个备份解决scheme，根据您的需求和限制，这个备份解决scheme的差异很大 如果您可以在arrays上设置磁带备份或磁盘到磁盘的备份，以便提供合理的数据保留期，那就太好了。 如果不是这样，即使是一个小型的消费级NAS或者两个也不比什么都好。 最坏的情况是，在没有预算的情况下，我已经在我的工作站驱动器，消费级外部USB驱动器，甚至是DVD-R主轴上保留了重要服务器的备份。 重要的是要确保你有一定的数据保留水平。 从前一天晚上进行原始备份，当你发现上周开始的数据损坏，或者你在一个月前已经扎根时，你是不行的。