我们的开发环境有很多层，并且难以有效地复制甚至备份。基本上，文件系统（即 /usr/appdir/webapp...）还有其他应用程序服务于我们的 Web 应用程序，我们更新的那些应用程序从它们的存储库执行 svn 更新。
使用 Web 应用程序本身（作为用户）将影响文件系统和数据库。所以备份系统就是在同一时间点拥有文件系统和数据库（mysqldump）的副本。两者之一本身不会是完整的备份，因为应用程序本身是非常动态的。
当我们将 web 应用程序部署到登台以供我们的一位客户测试和输入数据时，我们的环境现在很难从我们的开发环境同步回来，甚至难以将其投入生产。由于我们会在开发中向客户提出更改请求，但客户自己会在分期中进行更改。
目前我们正在使用冻结期，我们要求客户对开发环境甚至直接对生产环境进行更改（在完全上线之前）。
我想知道他们是否是关于如何从开发-> 暂存-> 生产中传递有效流程的最佳实践？或者，如果您可能有一些指示。
我通常不会对 QA/staging 环境进行任何更改。任何更改都会在开发环境中进行，然后推送到 QA/staging 和生产。通常，如果可以避免的话，我也不会在 QA/staging 中使用实时数据。如果我在 QA/staging 中有实时数据，我将使用 SQL Data Compare（来自 Red Gate）之类的东西来管理新数据从 QA/staging 环境到生产环境的迁移。
此外，我在源代码控制中为开发/质量保证/生产维护单独的配置。当更改影响所有配置时，必须记住在所有配置中进行更改有点痛苦，但是有足够的差异，这样做比在应用程序发布时更新 QA/生产配置更容易/安装。
从它的声音来看，您的问题因应用程序的性质而变得复杂。
首先，您的应用程序是否区分作为应用程序一部分的文件和仅作为数据的文件？如果不是，除非您有非常令人信服的理由不这样做，否则这种性质的更改应该会使您的文件系统的版本控制更加简单——那么将应用程序部分置于版本控制之下是有意义的，而不是数据部分。
其次，我一直觉得让文件系统数据与数据库数据保持同步是一件很痛苦的事情。一种解决方案（可能是更广泛的重构）是使一个可以从另一个生成。您能否以某种方式将文件系统内容存储在链接到相关数据的数据库中，从而可以从脚本中填充文件系统？如果您的文件太大，在许多情况下，具有用于开发和测试目的的代表性文件就足够了。
或者，您可以有一个单独的数据存储库，它可以拍摄一组数据（数据库和文件系统）的有效快照，这些数据可以与您的应用程序代码分开存储和管理（尽管这种方法会带来其他问题...... )
如果这里的设计问题是不变的，我想不出比你的冻结期更好的主意。