我正在探索最小化多个WordPress实例的数据库转储大小（用于自动备份WordPress内容）的可能性。

我最想知道的是，数据库中是否存储了任何生成的数据，我可以在备份期间安全地丢弃这些数据，因为这些数据将由WordPress重新生成（或者备份后可以手动执行的操作）。例如，对于phpBB3，丢弃搜索词等通常是安全的，因为您可以在灾难恢复后轻松地重新编制索引。。。

哦，我应该补充一下，我读过this 并且没有从中推断出任何最小化转储大小的方法（除了--compact 和--skip-comments 命令行切换到mysqldump).

我自己做了进一步的调查。之前我尝试过Git和Mercurial只存储两个快照之间的差异，但这些工具对于特定用途来说并不太好。我也试过了rdiff-backup, 但结果是。。。嗯，平庸。

无论如何，我想我可能已经找到了缩小单个（DB）快照大小的替代方法。我已经尝试过重新打包SQL转储文件。编号：

对于我使用它的其中一个博客，24小时（每小时）的备份总计约1500个MiB<单独压缩(gzip -9) 这些时钟总共约为540个MiB（每24小时一次）

• 将24小时的备份重新打包到一个单独的归档中xz 我想出了以下数字：
  • xz -6: 仍然>300 MiBxz -7: 仍然>300 MiBxz -9: 取决于每天10到30个MiB。。。我发现这种差异令人惊讶，但这可能是由于垃圾邮件的评论，所以这需要更多的实验

    重新打包过去24小时内的备份添加过去24小时内的最新文件，我将查看这是否也适用于每月备份，或者是否需要在重新打包之前精简备份。

    在DB转储缩小前--where 命令行切换到mysqldump 看起来很有希望，但我还不能表达where comment_approved not in (\'spam\', \'trash\') 以一种适用于博客特定数据库中所有表的方式，这使得使用：

    mysqldump: Couldn\'t execute \'SELECT /*!40001 SQL_NO_CACHE */ * FROM `wp_commentmeta` WHERE comment_approved not in (\'spam\', \'trash\');\': Unknown column \'comment_approved\' in \'where clause\' (1054)
    

    （指列名，如wp_comments.comment_approved 也没有帮助）