我知道VMWare KB在长时间运行的快照上皱眉，主要是由于两件事（在我看来） 大量的快照可以填满数据存储。 快照只是增量文件。 比方说，你有一个50G的VMDK，几乎已经满了，你拍一张快照。 在你的快照中，你翻转每一个位。 您的增量文件也将是大约50 GB。 再次快照，翻转位，另一个50千兆增量文件。 这些可以快速失控。 提交大量快照会带来风险。 合并快照时，您正在将增量更改写入原始VMDK。 这需要时间，并带有风险，如果发生什么事情，你只是VMDK nucked。 他们的警告似乎是合乎逻辑的。 这就是说，从VMDK快照中永久运行我的机器本身是不好的？ 我想让我的树如下： 基础 Snap1 快照2 你在这里 在安装和configuration基本系统后，将立即执行快照1和2。 这些是我打算频繁刷新的机器，所以我会简单地让我的树看起来像下面这样： 基础 Snap1 你在这里 快照2 删除Snap2并重新创buildSnap2。 我不明白这可能会有什么影响，原因如下： 由于我只是简单地安装了一个基本的图像，并在没有办法填充数据存储之后马上拿走了我的三angular洲。 假设我的基本映像只有10 GB（在50 GB精简置备的磁盘上），即使我的增量翻转每一位，最大总使用量可能是60 GB（10 GB基本VMDK已locking+ 50 GB增量快照VMDK文件）。 这假定我不创build任何进一步的快照。 由于我的使用案例不需要整合快照，所以我不会冒险整理我的错误。 当我移回Snap1并删除Snap2时，所有位于Snap2中的增量只会被删除。 存储负载是完全一样的，所以我应该得到相同的IOPS。 我知道一些文件（主要是系统文件）将存在于原始的VMDK上，而其他的文件（基础之后的所有文件）将存在于delta中，但是我不明白ESXI是如何处理的。 所有文件都在同一个物理数据存储上，所以性能应该等同于在没有快照的情况下引用原始VMDK中的所有内容。 有什么想法吗？ ESXI 5.5与数据存储RAID'd DAS。 我没有vCenter许可证，所以模板和克隆不在桌面上。 结果的testing 我今天早些时候进行了一些testing。 结果如下。 有一个performance惩罚，但我不知道为什么。 快照之前： 快照后：
在三个星期的时间里，我在客户现场遇到了六次完整的LTO-1和LTO-2磁带机故障。 有些机制失败了。 其他人失去了可靠编写的能力。 这些是惠普Ultrium 232,448和460驱动器。 这些单位大部分是在2006年至2008年间部署的，所以失败的时机是正确的。 容量（400GB）对应用程序是正确的。 为了保持一致性，我用同等设备replace了几个驱动器。 一台服务器也出现SCSI HBA故障，进一步延迟恢复。 那时，客户询问是否有可用的硬盘解决scheme，比磁带更好（或者更不挑剔）。 当我开始寻找替代品时，我发现RDX可移动磁盘存储技术已经被主要服务器制造商（ HP ， Dell ， IBM ）所采用。 从我的angular度来看，它看起来像2.5“SATA磁盘，通过USB2在内部或外部连接，容量高达1TB，因为这些是实际的磁盘，恢复和寻找时间似乎是合理的。该技术在实践中。 有没有人在这里使用这些驱动器成功？ 有什么需要注意的吗？ 什么区别RDX从直接的外部USB磁盘？ 磁带在我的应用程序中的一个优点是驱动器具有硬件压缩。 这极大地帮助我在Linux系统上备份的高度压缩的数据集。 我是否正确地认为RDX依靠软件压缩？ 由于这些是物理磁盘，Linux或Windows中是否有挂载点问题？ 关于磁带的好处之一是，它不是一个安装的文件系统，通常不受病毒，rootkit，系统崩溃等的影响。 另外，我还看了一个关于使用RDX和Cactus Lone-Tar的入门书，并且在使用mkfs命令在/dev/sda上的RDX驱动器上创build一个文件系统时， 是否有设备重命名/重新sorting的机会（从添加SCSI控制器，插入USB密钥等），或者在交换驱动器时对接单元是否会保留在特定的设备名称？ 30兆字节/秒的备份速度是否准确？ 我很好奇，因为这可能是一个有趣的select。 一系列的磁带驱动器故障发生之前，有必要重新评估其他选项，然后再继续前进。
我的团队目前有两个较大的存储服务器，都运行debian linux的NAS。 第一个是一个几十年前的一个全function的24盘（SATA）服务器。 我们有两个设置LVM的硬件RAIDS。 第二个服务器是64个磁盘，分为4个机箱，每个机箱都有一个硬件RAID 6，通过外部SAS连接。 我们使用LVM的XFS来创build100TB的可用存储。 所有这些工作都很好，但是我们超出了这些系统。 在构build了两个这样的服务器并仍在不断增长的情况下，我们希望构build一些能够使我们在未来增长方面更具灵活性的备份选项，在磁盘故障下更好地运行（检查更大的文件系统可能需要一天或更长时间）在一个严重的并发环境中（思考小型计算机集群）。 我们没有系统pipe理支持，所以我们自己pipe理所有这些（我们是一个基因组实验室）。 因此，我们所寻求的是相对低成本，可接受的性能存储解决scheme，它将允许未来的增长和灵活的configuration（认为ZFS具有不同的操作特性）。 我们可能超出了单个NAS的境界。 我们一直在考虑将ZFS（例如openindiana）或者每个服务器的btrfs与运行在其上的glusterfs结合起来，如果我们自己做的话。 我们所反对的仅仅是咬紧牙关，投资于Isilon或3Par存储解决scheme。 任何build议或经验，表示赞赏。
作为19英寸机架式设备的新手，请耐心等待。 最近我想到了将2.5“硬盘驱动器的4倍或6倍放入机架的最佳方法，而且目前真正困惑的是最好的解决scheme。 在search市场之后，我发现这种types的磁盘arrays单元提供了内置的RAID和大量的驱动器插槽以及大量的极客信誉，但价格却不符合我的预算。 我也发现这种types的可爱的适配器，在一个3.5英寸的插槽中需要两个2.5“的驱动器，但我显然需要一个具有很多3.5”空间的沙发才能使其工作。 那么将我的硬盘放在机架上的最经济的方法是什么？
我可以考虑采取备份的两个主要原因似乎是照顾当我同时使用快照和RAID与btrfs。 （这里是RAID，我的意思是RAID1或10） 意外删除数据：快照涵盖了这种情况 驱动器故障和位腐烂 完全失败：RAID涵盖了这种情况 驱动器返回错误数据：RAID + btrfs的错误纠正function涵盖了这种情况 因此，作为一个现场备份解决scheme，这似乎工作正常，它甚至不需要一个单独的数据存储设备！ 但是，我听说RAID和快照都不被认为是正确的备份，所以我想知道我是否错过了任何东西。 除了btrfs还不是一个成熟的技术，你能想到我错过的任何东西吗？ 还是我的想法是正确的，这是一个有效的现场备份解决scheme？
我有存储空间，可以让我精简提供给客户的卷。 这安全吗？ 什么是最佳实践？
阅读完文档后，我发现自己对如何最好地pipe理高效的应用程序/服务数据感到困惑。 似乎有3个选项： 只需将卷映射到主机目录（即docker run -v参数） 为数据创build一个docker容器图像（即单独的容器和–volumes-from ） 创build一个docker卷（即docker volume create ） 现在看来，接受的做法是选项＃2，但是我想知道＃3的目的是什么。 特别是如何正确处理docker volume这些情况，使用数据卷容器还是更适合每种情况？ 您需要在服务器的单独卷和/或存储层中提供应用程序数据 备份 恢复数据
我们已经在LTO磁带上备份了多年的数据，知道我们拥有磁带上的所有东西，这是一个真正的安慰。 一个姊妹项目和我们的数据提供商之一，都搬到了100％的磁盘存储，因为磁盘的成本已经下降了很多。 当我们现在向潜在客户提出系统时，我们倾向于淡化或不提到我们使用磁带系统来存储数据，因为它看起来可能已经过时了。 将数据保存为两种不同的格式（磁盘和磁带）让我感觉更加舒适。 另外，一旦数据被安全地写入磁带，我感觉（也许天真地）它已被永久保存。 不需要依靠RAID控制器来读取数据对我来说是另一个好处。 你现在看到有磁带备份的地方吗？
我正在改变我们的DHCP / DNS的东西在工作的方式。 目前我们有3个DNS服务器和一个DHCP框。 他们都是虚拟机。 有一个循环依赖项，启动东西需要NFS，这需要DNS。 所以，当我们重新启动的东西，事情可能会恢复微妙，直到DNS启动，我们重新启动一些服务。 我想要做的是有几个低功耗服务器，可能是双核Atoms或类似的，从SSD运行，所以他们开机该死的快。 我想尽可能使整个启动尽可能快。 理想情况下，我想使用Ubuntu 11.10或Debian 6作为操作系统。 我对Gentoo不感兴趣或者编译自己的内核。 这需要我自己合理支持。 除SSD驱动器之外，还可以采取哪些其他优化步骤来提高启动速度？
在指定服务器的时候，比如（我会假设）许多不是存储专家的工程师，我通常通过在最less10k SAS驱动器上进行标准化来实现安全（也许是市场营销的奴隶）（因此是“企业“等级为24×7的工作周期等），用于”系统“数据（通常是操作系统，有时是应用程序），并保留使用7.2k中/近线驱动器存储非系统数据，其中性能不显着因子。 这都是假设2.5“（SFF）磁盘，因为3.5”（LFF）磁盘只对高容量，低IOP要求非常有用。 在没有大量非系统数据的情况下，我通常会将它放在与系统数据相同的磁盘/arrays上，这意味着服务器只有10k SAS驱动器（通常是“一个Big RAID10”types这些天设置）。 只有在非系统数据量很大的情况下，我通常会考虑把它放在一个单独的7.2k中/近线磁盘arrays上，以降低成本/ GB。 这使我想知道：在某些情况下，RAID10arrays中的10k磁盘是否已被replace为7.2k磁盘而没有任何重大的负面影响？ 换句话说，我是否坚持使用至less10k个“企业”级磁盘，有时候会过度专注（并且让硬件厂商保持高兴），还是有充分理由始终坚持这一点？ 例如，为一个典型的小型公司（比如说50个用户）提供一台虚拟机作为虚拟机pipe理程序。 该公司具有平均的I / O模式，没有特别的要求。 典型的9-5，周一到周五的办公室，备份每晚运行几个小时。 虚拟机可能可能是DC和文件/打印/应用程序服务器。 服务器有一个带有6个磁盘的RAID10arrays，用于存储所有数据（系统和非系统数据）。 对我的非专业人士来说，看起来好像中/近线磁盘可以做得很好。 以HP磁盘为例： 工作量：中线磁盘的工作负载小于40％。 由于办公室每天只能开放9个小时，在此期间平均I / O几乎不可能接近最大值，工作量似乎不大可能超过40％。 即使在晚上进行了几个小时的I / O备份，我的猜测仍然是低于40％ 速度：虽然磁盘只有7.2k，但通过将其分布在六个磁盘上可提高性能 所以，我的问题是：坚持至less10k SAS硬盘是合理的，还是7.2k中线/近线硬盘实际上在许多情况下都足够了？ 如果是这样的话，我该如何判断线路的位置，避免因安全起见而成为无知的奴隶？ 我的经验主要是惠普服务器，所以上面可能有一个惠普倾向于它，但我会假设原则是相当独立于供应商。