我将在海上石油平台(机架服务器)上安装数据库系统。他们的硬件和空间非常有限,因此无法发送备份基础设施。通过 FTP 发送备份也是不可能的,因为他们甚至没有文件服务器。
我考虑将 SQL 数据库备份到便携式 USD 硬盘上。USB 硬盘将始终直接插入服务器。每周一次,他们会将硬盘换成新的/旧的。
这样做是个好主意吗?如果不是,你能提出更好的解决方案吗?
答案1
这只是一个想法,但您可以通过镜像服务器/数据库提供外部(或第三方)备份服务。每次您执行插入/更新/事务日志/更改/创建/等任何修改时,信息都会被复制。因此,如果您无法访问或与互联网/外部网络的连接有限(每周一次),则交易量非常少,可以排队。
如果您告诉我您使用的是哪种数据库,我可以为您提供更多帮助。是 MySQL?MSSQL?ORACLE?
甚至(只是另一个想法)您是否考虑过制作一个策略良好的可编程备份?例如,如果您知道结构和数据以及数据的到期时间,则可以移动/删除不必要的历史记录或使用上述有关镜像数据库的想法。
我认为,在风险、安全性、空间和硬件损坏方面,使用具有最小连接的镜像数据库的成本低于使用外部可移动硬件的成本。
編輯:
关于镜像服务器,有很多帮助、教程和视频教程。我的技能更侧重于 Linux 上的 MySQL 服务器,但我可以告诉你一些技巧,希望它们能对你有所帮助。
- 首先,看看这里,在 serverfault 上,甚至更好:Stack Exchange 上的数据库管理员
- 在 MSSQL 的 msdn 上(我给你 2005 版本,我不知道你的服务器/数据库是什么版本):SQL Server 2005 中的数据库镜像但您可以在顶部菜单上更改它。
有一个常见问题解答链接位于该文件底部这可以澄清很多关于一些主要的问题(例如,队列交易,网络容量等):
或者如何准备镜像数据库在 2008 R2 上(您可以点击顶部的“其他版本”来更改版本)。
- 在 Google 上使用类似这样的键,您将会厌倦阅读有关它的内容:谷歌搜索。正如我所说的,这不是我首选的数据库,所以我真的不知道如何在 MSSQL 上做到这一点,但有一件事我很确定:如果数据库至少是 2005,你就可以做到这一点,而且肯定有比我告诉你的更多的选项和更好的选择。
- 我认为几乎每个提供仅数据库服务器服务的托管都可以从任何位置进行镜像,并且具有某种策略或证书,他们会向您解释。我现在不记得有什么好的服务,但我知道有很多。您可能会找到比 MSSQL 服务器更便宜的 MySQL 服务器,但我认为您需要一些“迁移应用程序”才能将数据从 MSSQL 移动到 MySQL,所以对我来说,第一个选择是您查看有关源的每个细节,然后要求兼容的镜像。
按照这种思路,还有另一个想法:
假设您无法配置镜像或任何原因。在最后一个实例中,您可以制作一个小作业/任务/自动化软件或脚本,通过 SQL 读取大量数据并通过 SQL 发送它(并且您可以更改目标,例如从 MSSQL(您的实际源)更改为 MySQL(它是免费的,您可以在任何地方支持它,使用您自己的 PC/服务器/等等)。
确实,如果您了解 SQL,您就可以做到。
还有另一个提示,我认为您说过您不能添加/连接任何 HD,但您可以使用 RAID 的磁盘来扩展内部备份的容量。
但无论如何,备份的主要思想是,您将备份放在完全不同的环境(另一个地方)中,如果某个数据库因任何原因(火灾、地震、革命、硬件问题)崩溃,您可以访问该数据库和/或切换该数据库。这就是镜像的主要思想:负载平衡服务器对用户来说一目了然,您真的不知道自己在哪里工作,它会同时以相同的方式工作。这就是“历史备份”和“实时备份”的区别。
編輯2: 无论如何,我永远不会回答你的想法。当然总比没有好,但对于关键数据来说,这就像什么都没有一样。它有很多不理想的未来问题:
- USB 速度
- 手动处理(由谁来处理?这些信息对于其他人来说是否太过重要?如果处理您数据的人员窃取/销毁/更改了您的数据,您是否承担任何法律/工作/经济责任?
- 时间,当然你想要一个自动选项。
- 您将备份……什么?数量有多少?什么类型的数据?旧数据是什么?使用什么标准?标准会或可以改变?这就引出了下一个问题:
- 在我们国家,有句“谚语”或“俗语”,比如“今天的面包,明天的饥饿”。我的意思是,你需要随时改变这个过程吗?你是否需要在短时间内寻找另一种方法?成本是多少?你的解决方案是否灵活,或者你会免费得到未来的问题?
答案2
备份到 USB 连接驱动器肯定比没有备份要好。备份到专门为备份而设计的硬件(如磁带)可能是更好的选择。
您能承受丢失一周的数据吗?如果您每周只更换一次驱动器,那么您将面临丢失一周数据的风险。如果驱动器连接了一周,则存在电涌损坏计算机和备份驱动器的风险。如果该驱动器 6 天没有更换,那么您将丢失 6 天的数据。
您会将驱动器运送到另一个位置吗?发生某种事件同时破坏原始数据库和备份驱动器的可能性似乎相当高。