系统维护
定期的系统维护对于 Arch 系统的长期正常运行是必不可少的。及时维护是许多用户习惯的做法。
检查错误
失败的 systemd 服务
检查是否有 systemd 服务失败
$ systemctl --failed
有关更多信息，请参阅 systemd#Using units。
日志文件
在位于 /var/log/ 的日志文件中查找错误，以及在 systemd journal 中记录的消息。
# journalctl -b
有关 Xorg 在何处以及如何记录错误的信息，请参阅 Xorg#Troubleshooting。
备份
拥有重要数据的备份是必要的措施，因为人为和机器处理错误非常可能随着时间的推移而产生损坏，并且存储数据的物理介质最终也会失效。
有关可能更适合您的应用程序，请参阅 Synchronization and backup programs。有关其他感兴趣的文章，请参阅 Category:System recovery。
强烈建议自动化备份并测试恢复过程，以确保一切按预期工作。有关自动化，请参阅 System backup#Automation。
配置文件
在编辑任何配置文件之前，请创建一个备份，以便在出现问题时可以恢复到正常工作的版本。像 vim 和 emacs 这样的编辑器可以自动执行此操作。在大规模上，请考虑使用 配置管理器。
对于 点文件（主目录中的配置文件），请参阅 dotfiles#Tracking dotfiles directly with Git。
已安装软件包列表
维护所有已安装软件包的列表，以便在不可避免地需要完全重新安装时，更容易重新创建原始环境。
有关详细信息，请参阅 pacman/Tips and tricks#List of installed packages。
Pacman 数据库
请参阅 pacman/Tips and tricks#Back up the pacman database。
加密元数据
请参阅 Data-at-rest encryption#Backup for disk encryption scenarios。
系统和用户数据
请参阅 System backup。
升级系统
建议通过 pacman#Upgrading packages 定期执行完整的系统升级，以享受最新的错误修复和安全更新，并避免一次性处理太多需要手动干预的软件包升级。当向社区寻求支持时，通常会假设系统是最新的。
确保准备好 Arch 安装介质或其他 Linux "live" CD/USB，以便在更新后出现问题时可以轻松地恢复系统。如果您在生产环境中使用 Arch，或者由于任何原因无法承受停机时间，请先在非关键的副本系统上测试配置文件更改和软件包更新。然后，如果没有出现问题，再将更改部署到生产系统。
如果系统中包含来自 AUR 的软件包，请仔细升级所有这些软件包。
pacman 是一个强大的软件包管理工具，但它并不尝试处理所有极端情况。用户必须保持警惕，并负责维护自己的系统。
升级系统前必读
在升级之前，用户需要访问 Arch Linux 主页 查看最新新闻，或者订阅 RSS feed 或 arch-announce 邮件列表。当更新需要非同寻常的用户干预（多于 pacman 提供的说明所能简单处理的）时，会发布相应的新闻帖子。
在将 内核、xorg、systemd 或 glibc 等基础软件升级到新版本之前，请查看相应的 论坛，看看是否有任何已报告的问题。
用户同样必须意识到，升级软件包可能会引发**意外**问题，这些问题可能需要立即干预；因此，不建议在即将执行重要任务之前不久升级稳定系统。相反，请等到有足够的时间来解决任何升级后问题再进行升级。
避免某些 pacman 命令
避免进行 部分升级。换句话说，**切勿**运行 pacman -Sy；而是**务必**使用 pacman -Syu。
通常避免使用 pacman 的 --overwrite 选项。--overwrite 选项接受一个包含 glob 的参数。使用时，pacman 将绕过与 glob 匹配的文件的文件冲突检查。在维护良好的系统中，仅应在 Arch 开发者明确建议时使用。请参阅 #Read before upgrading the system 部分。
避免使用 pacman 的 -d 选项。pacman -Rdd package 会跳过软件包移除期间的依赖检查。结果是，提供关键依赖的软件包可能会被移除，导致系统损坏。
部分升级不受支持
Arch Linux 是一个滚动发布发行版。这意味着当新库版本被推送到存储库时，开发者和软件包维护者会根据这些库重新构建存储库中所有需要重新构建的软件包。例如，如果两个软件包依赖于同一个库，只升级一个软件包可能会升级该库（作为依赖项），从而可能破坏依赖于旧版本库的另一个软件包。
这就是为什么**不支持**部分升级。**不要**使用
pacman -Sy package,pacman -Sy后跟pacman -S package（而是应该在安装软件包时使用-Su）。
pacman -Syuw存在与pacman -Sy相同的风险，因为它会更新 pacman 的同步数据库而不安装新软件包。- checkupdates bash 脚本（随 pacman-contrib 包提供）提供了一种安全的方式来检查已安装软件包的升级，而无需运行系统更新，并提供了一个选项（
-d）将待处理的升级下载到 pacman 缓存中，而不同步数据库，从而避免了在之后尝试使用pacman -S package安装软件包时出现部分升级问题。
刷新软件包数据库时，**务必**使用 pacman -Syu 进行完整升级。
出于同样的原因，在使用 IgnorePkg 和 IgnoreGroup 时要非常小心。如果系统中有本地构建的软件包（例如 AUR 软件包），当其依赖项收到 soname 升级时，用户需要重建它们。
如果已经创建了部分升级场景，并且二进制文件因为找不到它们链接的库而损坏，**不要只是通过符号链接来“修复”问题**。当库**不向后兼容**时，它们会收到 soname 升级。只要 pacman 没有损坏，简单的 pacman -Syu 到正确同步的镜像就会修复问题。
处理升级过程中的警报
升级系统时，务必注意 pacman 提供的警报通知。如果需要用户执行任何额外操作，请确保立即处理。如果 pacman 警报令人困惑，请搜索论坛或查看 Arch Linux 主页上的最新新闻（参见 #Read before upgrading the system）以获取更详细的说明。
及时处理新的配置文件
调用 pacman 时，可能会创建 .pacnew 和 .pacsave 文件。Pacman 在发生这种情况时会发出通知，用户必须及时处理这些文件。有关详细说明，请参阅 pacman/Pacnew and Pacsave wiki 页面。
此外，还要考虑您可能复制或创建的其他配置文件。如果一个软件包有一个您复制到主目录的示例配置文件，请检查是否已创建新文件。
升级后重启或重新启动
升级通常不会应用于现有进程。您必须重启进程才能完全应用升级。
archlinux-contrib 包提供了一个名为 checkservices 的脚本，该脚本运行 pacdiff 来合并 .pacnew 文件，然后检查正在运行的进程是否使用了过时的库，并提示用户是否要重新启动它们。
内核尤其难以在不重启的情况下进行修补。重启始终是最安全的选择，但如果非常不方便，可以使用 内核实时补丁在不重启的情况下应用升级。
回滚损坏的更新
如果一个软件包更新预计/已知会导致问题，打包人员会确保当该软件包更新时 pacman 显示相应的消息。如果在更新后遇到问题，请通过查看 /var/log/pacman.log 来仔细检查 pacman 输出。
此时，只有在确保 pacman 没有提供任何信息，https://archlinux.org.cn/ 上没有相关新闻，并且论坛上没有关于更新的帖子后，才考虑在 论坛或 IRC 上寻求帮助。降级有问题的软件包以回滚损坏的更新应作为最后的手段。
检查孤立和已删除的软件包
升级后，您可能拥有不再需要或不再位于官方存储库中的软件包。
使用 pacman -Qtd 检查作为依赖项安装但现在没有其他软件包依赖它们的软件包。如果孤立的软件包仍需要，建议将其安装原因更改为显式。否则，如果不再需要该软件包，则可以将其删除。有关详细信息，请参阅 pacman/Tips and tricks#Removing unused packages (orphans)。
此外，某些软件包可能不再存在于远程存储库中，但仍可能位于您的本地系统中。要列出所有外部软件包，请使用 pacman -Qm。请注意，此列表将包括手动安装的软件包（例如，来自 AUR）。要排除（仍）在 AUR 中可用的软件包，请使用来自 BBS#288205 的脚本或尝试 ancient-packagesAUR 工具。
使用包管理器安装软件
Pacman 在跟踪文件方面比您做得好得多。如果您手动安装东西，迟早会忘记您做了什么，忘记您安装到了哪里，安装了冲突的软件，安装到了错误的位置，等等。
- 使用 pacman#Installing packages 部分的方法从官方存储库安装软件包。
- 如果您需要的程序不可用，请检查是否有人在 AUR 中创建了软件包。请遵循该文章中的安装方法。
- 最后，如果您想要的程序不在官方存储库或 AUR 中，请学习如何为它创建软件包。
要清理不正确安装的文件，请参阅 pacman/Tips and tricks#Identify files not owned by any package。
选择开源驱动程序
在诉诸专有驱动程序之前，请始终尝试开源驱动程序。大多数情况下，开源驱动程序比专有驱动程序更稳定可靠。开源驱动程序的错误更容易也更快地得到修复。虽然专有驱动程序可以提供更多功能，但这可能会以牺牲稳定性为代价。为了避免这种困境，请尝试选择已知具有成熟的开源驱动程序支持且功能完整的硬件组件。有关具有开源 Linux 驱动程序的硬件信息，请访问 linux-drivers.org。
小心使用非官方软件包
在使用来自 AUR 或非官方用户存储库的软件包时要小心。大多数是由普通用户提供的，因此可能不具备与官方存储库中相同的标准。在构建和/或安装软件包之前，**务必**检查 PKGBUILD 文件是否合理，以及是否有错误或恶意代码的迹象。
为了简化维护，请限制非官方软件包的使用量。定期检查哪些是实际使用的，并移除（或替换为官方对应项）其他任何软件包。有关有用的命令，请参阅 pacman/Tips and tricks#Maintenance。系统升级后，使用 rebuild-detector 来识别可能需要重建的非官方软件包。
更新镜像列表
更新 pacman 的镜像列表，因为镜像的质量会随时间变化，有些可能会离线或下载速度会下降。
有关详细信息，请参阅 mirrors。
清理文件系统
有关此内容的帮助程序可以在 List of applications/Utilities#Disk cleaning 中找到。
未使用的 D 大文件
在查找要删除的文件时，重要的是找到占用磁盘空间最多的文件。有关此内容的帮助程序可以在 List of applications/Utilities#Disk usage display 中找到。
软件包缓存
删除 /var/cache/pacman/pkg/ 中不需要的 .pkg 文件以释放磁盘空间。
有关更多信息，请参阅 pacman#Cleaning the package cache。
未使用的软件包
从系统中删除未使用的软件包以释放磁盘空间并简化维护。
请参阅 #Check for orphans and dropped packages。
旧的配置文件
旧的配置文件可能与新软件版本冲突，或随时间损坏。定期删除不需要的配置，尤其是在您的主目录和 ~/.config 中。出于类似原因，在共享不同安装之间的主目录时要小心。
查找以下目录
~/.config/– 应用程序存储其配置的位置~/.cache/– 某些程序的缓存可能会增大~/.local/share/– 旧文件可能存放在此处
有关这些目录的更多信息，请参阅 XDG Base Directory support。
为了防止主目录中出现临时文件，最好管理一个不需要的文件列表并定期删除它们，例如使用 rmshit.py。
rmlint-gitAUR 可用于查找并可选地删除重复文件、空文件、递归空目录和损坏的符号链接。
损坏的符号链接
旧的、损坏的符号链接可能散落在您的系统中；您应该将它们删除。有关实现此目的的示例，请参阅 此处和 此处。然而，您不应该盲目删除所有损坏的符号链接，因为其中一些是有目的的 [1]。
要快速列出系统中所有永久文件的损坏符号链接，请使用
# find / -type d \( -path "/dev" -o -path "/proc" -o -path "/run" -o -path "/sys" \) -prune -o -xtype l -print
然后检查并从列表中删除不必要的条目。
技巧与提示
以下提示通常不是必需的，但某些用户可能会觉得它们很有用。
使用经过验证的软件包
Arch 的滚动发布对于希望尝试最新功能并尽快获得上游更新的用户来说是一个福音，但它们也可能使系统维护变得更加困难。为了简化维护和提高稳定性，请尝试避免使用最新的软件，并且只安装成熟且经过验证的软件。这类软件包不太可能收到困难的升级，例如重大的配置更改或功能移除。倾向于拥有强大而活跃的开发社区以及大量称职用户的软件，以便在出现问题时简化支持。
避免使用测试存储库，甚至是从测试中使用的单个软件包。这些软件包是实验性的，不适用于稳定系统。同样，避免直接从上游开发源构建的软件包。这些通常在 AUR 中找到，名称包含诸如："dev"、"devel"、"svn"、"cvs"、"git" 等。
安装 linux-lts 软件包
linux-lts 软件包是一个可选的 Arch 内核软件包，可在 core 存储库中找到。此特定内核版本具有来自上游的长期支持（LTS），包括安全和错误修复。如果您使用非核心内核模块并希望确保其兼容性，或者在新的内核版本导致问题时想要一个备用内核，它会很有用。
要使其可用作启动选项，您需要更新引导加载程序的配置文件以使用 LTS 内核和 ram disk：vmlinuz-linux-lts 和 initramfs-linux-lts.img。