= NextCloud AIO 与 NextCloud Bare Metal =

在过去的两年里，我一直在运行各种形式的 NextCloud。这仅供个人在家中在我的 Odroid HC4（类似于 RPi 的 ARM 板）上使用。我从安装 NextCloudPi 开始，但后来我转向裸机安装，因为我想在为 NextCloudPi 打包之前尝试更新

我设置它的首要任务是我有一个很好的备份策略。在 NextCloudPi 上，备份和恢复完整实例（包括或不包括数据）的能力直接内置于软件包中。我喜欢这个功能。在裸机安装中，我必须安排一个 cron 作业来备份配置文件、数据库和压缩文件
.tar.gz.不过，我一直不确定如何恢复它，幸运的是我昨天尝试了这个以确保我的备份是合适的；它们不是。我从头开始构建了一个新盒子，安装了带有 Apache + PHP 的 NC（对于与 NextCloud 兼容的各种版本的 PHP，这并不完全直观），并恢复了配置文件、数据库和数据文件。我最终遇到了无数似乎不起作用的错误。我已经接近我只想要一个可行的解决方案的地步了——我不想花几个小时来让一些复杂的东西工作

进入 NextCloud AIO，一个 Docker 容器，旨在复制与 NextCloudPi 提供的东西接近的东西。一旦我开始工作，设置起来就相对简单了

**我是否必须担心 NextCloud AIO 的未来发展我能够通过 NextCloud AIO 提供的“Borg”备份实用程序执行备份（并且我正在测试恢复以确保这些备份有效），但是我对这些预打包解决方案的担忧始终是长期维护。在 NextCloudPi 的情况下，正如我们所见，维护者已经离开了该项目。如果我没有注意并且仍然盲目地运行它并进行定期备份，我可能永远无法恢复我的数据。使用裸机安装，如果您单独拥有所有组件（文件、配置、数据库）并且始终可以将它们集成到 NextCloud 的未来实现中，那么这永远不会是一个担心。既然我再次寻求更简单的预打包解决方案，我想知道我是否应该担心 AIO 的未来发展


根据安装 NextCloud AIO 后运行的 docker 容器，我假设性能相似。 AIO 似乎只是一个实用程序，用于简化和容器化 NextCloud 的每个单独组件。例如，这是我的盒子上运行的，它只为 NextCloud 服务：
aio-apache
aio-nextcloud
aio-redis
aio-postgresql
aio-borgbackup
aio域检查
aio-mastercontainer
编辑：到目前为止更多的内存使用。对于裸机，我看到从空闲到加载的内存使用量为 1-1.5GB。在过去的十分钟里，它目前的范围是 1.5-2.4GB

我更喜欢使用 Docker 来管理 PHP 版本和扩展，以及隔离；并将 NextCloud 作为常规 PHP 应用程序托管在该容器内

这在控制和灵活性之间提供了最佳平衡。您的数据直接放在您选择的文件夹中，紧邻 NextCloud wwwroot。您的数据库数据文件也可以直接使用。添加几个脚本和一个用于备份的 cron 作业，一切就绪

至于 redis 等——我根本不需要它用于小规模设置（1-2 个用户）

至于 AIO 和其他变体 - 我根本不信任它们（在架构方面）。我知道我的 docker-compose 解决方案，而且我确信我能够解决任何问题（如果出现）。不能对那些“对每个人都有好处”的解决方案说同样的话

您实际检查是否可以从备份中恢复数据，这非常好。不过，我相信设置 DB + 文件备份应该不会很困难。我们都会犯错误，但一旦错误被修复，备份过程就不会那么复杂，因此您必须切换其他方法

== 关于社区 ==
成员
在线的