标签: maintenance

我遇到过一些用户在他们的邮箱中保留非常旧的邮件（+5 年）的情况，这只是浪费空间，出于安全原因也应该删除。

我发现我可以使用doveadm它，但是运行如下：

doveadm expunge -u testuser@sv.dev mailbox INBOX savedbefore 1-Jan-2011

没有任何影响。根据我的理解，电子邮件客户端expunge在服务器上运行之前将电子邮件标记为删除以实际删除它们。

如何将它们标记为删除使用doveadm然后在doveadm之前或直接完全删除它们之前运行命令？

我有一台笔记本电脑，是我一年前带来的，它的电池可以使用 3 小时。

6 个月前，电池寿命下降到大约 15 分钟（Windows 说它应该持续 30 分钟）。

当我本周测试它时，它缩短到 5 分钟。

我有一种感觉，我的电池已经没电了，但网上冲浪给出了不同的（大多数情况下，相互矛盾的）恢复充电的提示。

我买不起新电池，但如果有必要我会买一个。现在，我的笔记本电脑始终连接到电源。

有什么办法可以恢复我的电池强度吗？

遇到服务器故障，你们使用什么软件或系统来提醒您进行日常维护？您如何核对清单并记录您应该检查的各种项目？你有内部流程文件吗？您是否每周都有 cron 邮件提醒您检查系统日志？

另外，您是否在一个团队中工作进行系统维护，如果是，您如何协调谁将进行哪些维护？

如果您使用错误/问题跟踪系统来输入任务，您是否有一个 cron 作业输入重复性任务？

我正在考虑将自动加载磁带驱动器作为备份策略的一部分。这将是我第一次体验磁带备份。磁带驱动器的成本效益似乎取决于它们将提供多年服务的假设。然而，我很难评估磁带驱动器的预期服务年限。它们有很多活动部件和易损部件要损坏，这意味着它们应该是可修复的；但产品文献并没有太多关于维修的说明。具体来说，我正在寻找以下问题的答案：

1. 修复失败的自动加载磁带机是否常见？如果是这样，通常谁来修理？（制造商、第三方、内部？）另外，备件的供应情况如何？
2. 如果它们通常不维修，我如何评估磁带驱动器可以使用多长时间？
3. 是否有一些品牌或系列的自动加载磁带机比其他品牌或系列更可靠或更易于维护？

背景：我对磁带驱动器维护的理解主要基于我使用激光打印机的经验。一些入门级打印机显然根本不值得维修。另一方面，我仍在维护一些相对容易维修的LaserJet 4V打印机。我想知道自动加载磁带驱动器适合该范围的哪些地方。

某些数据库维护任务（例如重新组织索引、移动文件、更改架构等）需要禁用任何正在使用该数据库的应用程序。

除了在您的网站上发布一条消息（例如“我们将从美国东部标准时间午夜至凌晨 4 点停机以进行服务器维护”）之外，还有哪些好的策略可以解决此问题？

这应该是社区维基。我正在尝试列出我们应该定期执行的所有系统管理员任务的列表，因为我相信我们在公司做得还不够。这里的态度是修复问题不方便，但我们没有时间做预防性维护或持续改进。

日常的：

• 更换每晚备份磁带/驱动器
• 检查防病毒更新是否已推送到所有系统

每周：

• 每周更换备份磁带/驱动器
• 清除所有系统中的临时文件
• 对所有系统进行碎片整理

每月：

• 规划基础设施改进
• 将过时的设备交付/发送给电子产品回收商
• 重建或更换老化的工作站
• 测试从备份恢复

年度的：

• 重建或更换老化的服务器
• 更换 UPS 电池

本着问题的精神，您仍然可以使用的最旧硬件是什么？，我想问：

您所知道的仍在生产中使用的最古老的硬件是什么？您（或其他人）在保持其运行方面遇到了哪些挑战（缺乏文档、没有支持、没有可用的备件......）？

大多数组织会在 5-10 年后淘汰/升级软件和硬件，但有时旧软件会继续在旧机器上运行，因为它“正常工作”。

我曾经在一个客户站点工作，该站点在运行 HP-UX 的单个服务器上运行（内部开发的）业务软件的关键部分。服务器很旧（大约 12-13 年），但幸运的是仍然运行没有问题；然而，获得备件非常困难，而且由于软件安装没有记录，任何重大的系统更改甚至新硬件都可能导致严重的停机时间和数据丢失。我们最终设法更换了它，但这并不总是可行的。

我还了解到，许多组织仍在运行已有十年历史的大型机硬件，特别是对于控制工业机器或发电厂的高度定制化系统。

您遇到过哪些旧硬件？您是如何应对这些挑战的？

相关问题：

旧服务器是否应该退役

如何将 SQL Server 数据库备份到网络共享？

我在免费增值站点上托管了一个 SVN 存储库，其存储库大小最大。当我接近这个容量时，我知道我已经签入的文件我知道我可以永久删除以释放磁盘空间。我如何告诉 SVN 一个文件不仅可以被删除，而且它的历史也是如此？

我正在寻找一种解决方案来自动化我们应用程序的部署过程之一。在部署开始时，我想以编程方式将指定的服务器设置为维护模式，最后在部署完成后，从 nginx 服务器中删除维护模式标志。

通过维护模式，我的意思是 nginx 应该以 HTTP 响应代码 503 响应所有请求（可能带有自定义页面）。

我知道如何设置服务器块以响应 503 代码（请参阅http://www.cyberciti.biz/faq/custom-nginx-maintenance-page-with-http503/）但问题是如何以编程方式执行此操作并且最有效。

我想到了两个选择：

选项1：在部署过程开始时，将维护文件写入文档根目录，并有条件地检查nginx服务器配置中是否存在维护文件：

server {
    if (-f $document_root/in_maintenance_mode) {
        return 503;
    }
}

此方法包含一定的开销，因为每个请求都会检查文件是否存在。是否可以仅在加载 nginx 配置时检查文件是否存在？

选项 2：部署脚本用维护版本替换整个 nginx 服务器配置文件，并在部署结束时将其换回。如果使用此方法，我担心可能会覆盖维护配置文件的其他自动化进程，例如 puppet。