如何进行预定的 Linux 服务器备份

Sej*_*nus 4 maintenance ubuntu backup ubuntu-9.04 backup-restoration

我需要在 Ubuntu 9.04 上组织数据库、网站、ftp、电子邮件等的自动备份,因为我以前从未做过,所以我正在寻找学习的地方。需要做什么,我可以使用什么(免费)软件,提示和技巧,最佳实践等等。如果你能给我指出适合初学者的相关文章,我将不胜感激

Flo*_*Flo 6

备份总是很难正确调整;特别是因为人们有不同的需求,而这些需求通常是数据“快照”备份、数据归档、服务器(配置)备份、可靠服务等之间的混合)。

3dinfluence 和 davey 都对:尝试恢复操作很重要(如Joel 所说),通常首先要做的是一组 cron 脚本;但是必须根据您可以“接受松散”的数据量以及您需要的可靠性级别来执行其他操作。

所以你必须问自己的问题是:

  • 备份的目的 - “保护”您的数据/服务免受:

    • (本地)硬件故障,如磁盘崩溃;
    • 更大的损坏,如建筑物着火;
    • 用户错误(意外删除)或需要检索旧数据;
    • 有问题的软件包发布(升级服务通常很困难,等等)。
  • 可接受的停机时间(和数据丢失),以防出现不同类型的问题

    • 磁盘故障?例如。没有损失,没有停机时间(?)
    • 其他硬件故障(MB、CPU 等)?失去了一天的工作,几个小时的停机时间
    • 火(和消防员的水)?一周损失,几天停机
    • 地震还是停电?

根据这些问题的答案,您将了解每日备份是否足够,或者您是否需要位于不同地理位置的热备用服务器。

我根本不是这个领域的大师,但也许我的例子可以给你一些想法。

我正在管理一个小型(debian)服务器,提供数据库(postgresql)、subversion 存储库、trac 站点和其他一些类似的功能;服务器主要是我们研发组用的,所以人很少(subversion的客户端约20个),还有一些仪器(数据库的客户端约50个),但他们几乎24/24h,7/7天工作(特别是仪器,它为数据库提供度量)。

如果出现一般问题(如主要硬件故障),2 到 4 小时的停机时间是可以接受的(仪器可以在本地工作一段时间)。所以我没有(还)警告备用服务器,但只有一组本地和远程备份和转储。

所以要求一点也不苛刻:大约有一百场演出的数据,而要服务的客户不到一百个。

第一道“防线”由磁盘冗余和分区提供(这不仅有助于防止磁盘崩溃,还有助于进一步备份或服务器升级) 该机器配备 4 个磁盘(每个 500Gb)。

  • 2 个(软)raid 阵列(类型 1,在 3 个磁盘上):
    • 一小部分,专用于 /boot
    • 和一个大的,由 lvm 使用(见下文)
  • 2个lvm组:
    • 在大型RAID阵列上制作的一个(第四个磁盘上的+ 1个非RAID分区)
    • 另一个仅使用非 RAID 分区(前 3 个磁盘中的每个磁盘上有 50Gb,第四个磁盘的一半)
  • 最后,分区:
    • / 和 /var 在来自大型突袭的两个 lvm 卷上;用户数据都存储在 /var ...
    • 第一个 vgroup 的非突袭扩展保留用于快照 (lvm)
    • /boot 直接在小型 raid 1 阵列上
    • /tmp 和来自第二个 vgroup(非突袭)的两个 lvm(线性卷)上的特殊 /backup。使用最后一个驱动器,其他 3 个驱动器的扩展保留用于快照。

第二道防线是定期备份:它们由 cron 脚本制成,基本上每天启动(例如 svn、trac 站点的热备份、db 文件的副本等)或每周(数据库转储、svn 转储等) .) 每次备份的确切方式取决于服务;例如,subversion 提供了用于(快速)热备份(使用硬链接等)和文本转储的工具,但一个简单的 rsync 用于数据库,由 lvm 快照制成。

所有这些备份都在(本地!)/backup 分区上进行(要快);该分区通常以只读方式挂载;两个 sudoeable 脚本用于以 rw 模式(备份开始)重新绑定它,并返回到 ro(最后)。基于锁文件的信号量用于处理并发备份。

每次将 /backup 切换到 ro(以及每 4 小时),就会安排一次镜像操作(使用 'at' 并有一个小的延迟来连接来自第三行的更改)。镜像是(使用 rsync)到不同的服务器,从那里数据被存档在磁带上(每天,只有一年的保留),并通过网络,到一组遥远的 terra 站。

为了避免失去一整天工作的风险,以最小的带宽成本,还准备了第三条线路,包括在可能的情况下进行增量备份。

例子:

  • 对于颠覆,每个修订版都转储到一个(压缩文件)中,来自 post-commit 和 post-revpropschange 挂钩(使用 svn-backup-dumps)
  • 对于数据库,使用连续归档(和 PITR 概念)

这些增量使用与每日和每周副本相同的概念保存(首先到本地备份分区,然后在第二台主机上稍有延迟)。当然,每日复制和每周转储脚本必须处理增量的轮换。

请注意,这第三行非常接近警告备用服务器(嗯,这是实现这一概念的必要步骤)。

最后,服务器本身的配置(如果必须设置新的,则可以最小化工作)。由于我不相信重影解决方案(新机器将有不同的硬件、磁盘配置等),我设置了一个专用的 subversion 存储库,我将手动编辑的每个脚本或配置文件都放在上面(直接或间接通过用户界面)。所以文件系统(/)的根是一个工作副本。此外,每天安排的一个cron任务负责保存已安装包列表(dpkg)、分区表(fdisk)、raid和lvm设置等。

顺便说一句,这当然是最薄弱的一点:服务器配置位于一个 subversion 存储库上,由“相同”主机提供服务。无论如何,如果需要,使用来自不同机器(甚至是 Windows 机器)的存储库备份之一(快速备份或转储)是相当容易的。

此外,我也尝试在触及主系统上的任何脚本(或包升级)之前,认真制作lvm快照。但是这些 lvm 快照的生命周期应该尽可能短,因为在其他服务上引入了很大的惩罚。

好吧,我希望它能有所帮助,或者至少提供一些想法......


3di*_*nce 5

根据您的目标、基础设施和媒体偏好,有很多选择。

首先,无论您最终采用哪种解决方案,您都可能需要弄清楚如何设置 cron 作业。它是在 *nix 上运行计划任务的东西。

至于备份本身,我倾向于使用rsnapshot,因为它很容易设置并完成我需要的操作。Amanda 和 Bacula 都是很好的解决方案,但涉及数据库和其他使备份和恢复复杂化的事情。当我需要可靠的东西(例如备份)时,我倾向于避免复杂的事情。Rsnapshot 使用 rsync over ssh 在系统之间传输数据,因此它既安全又高效。然后它使用硬链接,以便您拥有要备份的文件系统的许多时间点快照。

必须对数据库进行一些特殊处理,您要么需要在运行备份作业时锁定表,要么将数据库表转储到另一个位置,然后使用您选择的任何方法进行备份。如果您使用的是 MySQL,则可以使用 mysqldump 之类的工具完成此操作。此转储通常使用 cron 作业自动执行。