如果表损坏,我可以恢复备份吗?

发布于 2024-07-25 19:33:05 字数 525 浏览 4 评论 0原文

我希望这对你们中的一个人来说是一个简单的答案。

我们已经在单板计算机上运行了 PHP/MySQL,该产品将成为基于 Web 的管理工具。 该产品将是一个“设置好后就忘记它”的应用程序。

我们关心的问题之一(无论是否有效)是 MySQL 表/数据库损坏。

我们在这个小盒子上持续运行进程,可以诊断损坏,或捕获数据库错误并采取相应的行动。

我们通过这些相同的流程定期创建备份。 我们的想法是,如果我们感觉到损坏或捕获数据库错误,我们将短暂暂停我们的进程并从最近的备份中恢复表。 我们希望这能够解决腐败问题。

问题是:如果MySQL表损坏,我们可以执行备份恢复吗?

我想后续问题是我们上面的逻辑是否正确。 备份恢复能否纠正表损坏问题?

我知道这听起来很愚蠢,但我们对 MySQL 后端不太熟悉。 我们担心的是,如果数据库(或表)以某种方式损坏,这也会阻碍备份恢复。

你们中的一些人可以对此发表意见吗?

非常感谢。

I'm hoping this will be a simple answer for one of you.

We've got PHP/MySQL running on a single board computer for a product that will be a web-based admin tool. This product will be a 'set it and forget it' application.

One of our concerns (whether or not it's valid) is MySQL table/dbase corruption.

We have processes running continually on this little box that can diagnose the corruption, or catch dbase errors and act accordingly.

We are creating backups regularly via these same processes. Our thought is that if we sense corruption or catch a dbase error, that we'll briefly pause our processes and do a restore of the table from the most recent backup. Our hope is that this will fix the corruption.

The question is: If a MySQL table is corrupted, can we perform a backup restore?

I suppose a follow-up question would be if our logic above is correct. Will a backup restore correct a table corruption issue?

I know this sounds silly, but we're not that familiar with the MySQL backend. Our fear is that if the dbase (or a table) is somehow corrupted, that this will also impede a backup restore.

Can some of you weigh in on this?

Thanks so much.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

半仙 2024-08-01 19:33:05

是的,它会。 请记住,您只会拥有上次备份之前的数据,因此您将丢失从该时间到损坏时间之间发生的所有数据,但这通常最多是一天。

备份是数据库在备份期间处于任何状态的副本。 如果您使用干净的备份来恢复损坏的数据库,那就太好了。 因此,请保留每月备份和最近 7 天的备份。 以防万一你的一个备份被冲洗了。

Yes, it will. Keep in mind that you'll only have data up until your last backup, so you'll lose whatever went in from that time to the corruption time, but this is generally a day at most.

The backup is a copy of the database in whatever state it was in during backup. If you restore a corrupt database with a clean backup, you'll be hunky dory. For this reason, keep monthly backups and the last seven days, as well. Just in case one of your backups is hosed.

情徒 2024-08-01 19:33:05

我认为甚至在您想到这一点之前,您就需要采取措施以确保损坏的表永远不会被备份。 因为如果您恢复备份而备份本身恰好已损坏,您就会回到开始的地方。

您使用什么存储引擎?

I think even before you think of that, you need to put in place measures to ensure that corrupt tables are never backed up. Because if you restore a backup and the backup itself happens to be corrupt, you are right back where you started.

What storage engine are you using?

或十年 2024-08-01 19:33:05

需要考虑一件事; 根据数据库的结构,从备份恢复单个表可能会导致引用完整性问题。

One thing to think about; Depending on how your database is structured restoring a single table from backup can cause problems with referential integrity.

掩于岁月 2024-08-01 19:33:05

我认为这就是备份的全部意义,不是吗?

此外,如果表已经损坏,当您尝试恢复它时最糟糕的情况是什么?

我说去吧。

I think that's the whole point of having a back-up isn't it?

Besides, if the table is already corrupt, what's the worst that could happen when you try to restore it?

I say go for it.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文