Eclipse 基金会使用 Tuleap 取代了 Bugzilla。

Tuleap 是一个独特的开源项目管理工具，目前发展势头很好，现在，每个月它会出一个大版本。它还被列在 2015 年五大开源项目管理工具和 2016 年十一个名列前茅项目管理工具中。

Manuel Vacelet 是开发 Tuleap 项目的 Enalean 公司的联合创始人和 CTO，他说：“Tuleap 是一个完整用于托管软件项目的 GPLv2 平台，它提供了一个集中化的平台，在这里，团队可以找到他们所需的所有工具，追踪他们软件项目的生命周期。他们可以找到项目管理（Scrum、看板、瀑布、混合等等）、源码控制（git 和 svn）和代码审查（pull 请求和 gerrit）、持续集成、问题跟踪、wiki 和文档等的支持。”

在这次采访中，我会和 Manuel 讨论如何开始使用它，以及如何以开源方式管理 Tuleap。

Nitish Tiwari（以下简称 NT）： 为什么 Tuleap 项目很重要？

Manuel Vacelet（以下简称 MV）： Tuleap 很重要是因为我们坚信一个成功的（软件）项目必须涉及所有利益相关者：开发人员、项目经理、QA、客户和用户。

很久以前，我还是一个 SourceForge 衍生项目的实习生（当时 SourceForge 还是一个自由开源项目），几年后它变成了 Tuleap。 我的第一个贡献是将 PhpWiki 集成到该工具中（不要告诉任何人，代码写的很糟）。

现在，我很高兴作为首席技术官和产品负责人在 Enalean 工作，该公司是 Tuleap 项目的主要贡献公司。

NT：让我们聊聊技术方面。

MV： Tuleap 核心系统是基于 LAMP 并且架构于 CentOS 之上。如今的开发栈是 AngularJS (v1)、REST 后端（PHP）、基于 NodeJS 的实时推送服务器。但如果你想成为一名 Tuleap 全栈开发人员，你还将需要接触 bash、Perl、Python、Docker、Make 等等。

说到技术方面，需要重点强调的 Tuleap 的一个显著特征是它的可扩展性。一个运行在单服务器上的 Tuleap 单一实例、并且没有复杂的 IT 架构，可以处理超过 10000 人的访问。

NT：给我们说下该项目的用户和社区。有谁参与？他们如何使用这个工具？

MV： 用户非常多样化。从使用 Tuleap 跟踪他们的项目进度并管理他们的源代码的小型初创公司，到非常大的公司，如法国电信运营商 Orange，它为超过 17000 用户部署了它，并托管了 5000 个项目。

许多用户依靠 Tuleap 来促进敏捷项目并跟踪其进度。开发人员和客户共享同一个工作区。客户不需要学习如何使用 GitHub，也不需要开发人员做额外的工作，就可以将其工作转换到“客户可访问”平台。

今年， Eclipse 基金会使用 Tuleap 取代了 Bugzilla。

印度电子信息技术部使用 Tuleap 创建了印度政府开放电子政务的开放式协作开发平台。

Tuleap 有许多种不同的使用方式和配置。有些人使用它作为 Drupal 客户门户网站的后端; 它们通过 REST API 插入到 Tuleap 中以管理 bug 和服务请求。

甚至一些建筑师也使用它来管理他们的工作进度和 AutoCAD 文件。

NT：Tuleap 是否做了一些特别的事，使社区更安全，更多样化？

MV： 我们还没有创建“行为准则”；本社区非常平和而欢迎新人，但我们有计划这样做。Tuleap 的开发人员和贡献者来自不同的国家（例如加拿大、突尼斯、法国）。而且 35％ 的活跃开发者和贡献者是女性。

NT：由社区提议的 Tuleap 功能的百分比是多少？

MV： 几乎 100％ 的功能是由社区驱动的。

这是 Enalean 的关键挑战之一：找到一种商业模式，使我们能以正确的方式做开源软件。对我们来说，“开放核心”模式（其中应用程序的核心是开放的，但有趣和有用的部分是封闭源的）不是正确的方法，因为你最终还是要依赖闭源。因此，我们发明了 OpenRoadmap，这种方式是我们从社区和最终用户那里收集需求，并找公司来为此买单。

作者简介：

Nitish 是一名专业的软件开发人员并对开源有热情。作为一本基于 Linux 的杂志的技术作者，他会尝试新的开源工具。他喜欢阅读和探索任何开源相关的事情。在他的空闲时间，他喜欢读励志书。他目前正在构建 DevUp - 一个让开发人员以真正的方式连接所有工具和拥抱 DevOps 的平台。你可以在 Twitter 上关注他 @tiwari\_nitish。

via: https://opensource.com/article/17/1/interview-Tuleap-project

作者：Nitish Tiwari 译者：geekpi 校对：jamsinepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

作为程序员，我们虽然不像港台剧那样处处用中文混着英文说话，但是在日常的工作学习中还是会大量接触到各种英文单词和缩写。除了一些很普通的英文单词由于某种神秘不可知的原因被屡屡错读之外，计算机世界是变化的如此之快，也经常出现一些新的缩写令非英语母语的中国程序员在懵圈之后随便选个姿势去读。

我猜测，或许是为了将广告野生程序员从这种尴尬之中解脱出来，石墨文档在 GitHub 上做了一个有趣的仓库，专门收集了许多中国程序员容易发音错误的单词。

本着简单的原则，又为了避免程序员们出现选择困难症，“正确音标”采用了最接近有道词典音频的英式 DJ 音标，不代表其唯一性。专业在线英语词典请参考知乎链接:在线英语词典哪个比较好?

参考资料

1. https://www.zhihu.com/question/19739907
2. https://www.v2ex.com/t/131094
3. https://www.v2ex.com/t/309350
4. https://www.v2ex.com/t/63781
5. https://www.v2ex.com/t/246033
6. https://www.v2ex.com/t/342087

此外，还有一位 lexrus 同学根据此库的数据，做了一个开源的 iOS 应用，这个应用的名字非常绝妙，叫做“花灰”——请捋直了舌头跟我念：H-U-A-花，H-U-I-灰，花灰。

作者说道：

这个小 App 用 UITableView 陈列了一些中国程序员经常读错的单词，用 AVFoundation 实现美音和英音的朗读，用 Playground 同步单词库。功能异常简陋，实现非常粗暴，仅供 iOS 程序员自行编译，纠正发音使用，懒得提交 App Store。

可从以下视频中略窥一斑，做的还是不错的，不过如果你的 iPhone 没越狱，显然是没法用的——或许你可以去作者的 issues 页面请求他上架？:-D

那么你有几个读错的呢？欢迎发表评论，也欢迎去提交你发现易读错的计算机术语和缩写。

有同学表示，读对还不行，你经常用的一些单词术语，或许并不是你以为的那个意思。不信？你去看看“程序员眼中的英语单词”和它原本的意思差别有多大就知道了~

GNU Affero 通用公共许可证版本 3（AGPLv3）是与 GPLv3 几乎相同的 左版 （ copyleft ） 许可证。两个许可证具有相同的公共版权范围，但在一个重要方面有重大差异。 AGPLv3 的第 13 节规定了 GPLv2 或 GPLv3 中不存在的附加条件：

在本许可证的其它条款之外，如果你修改了程序，你必须把你修改的版本，给你的那些使用计算机网络远程（如果你的版本支持此类交互）与之交互的用户，明确提供一个通过一些标准或者常规的复制手段，从网络服务器上免费获得与你所修改的版本相匹配的源码的机会。

这个“通过计算机网络远程交互”的范围主要被认为是 SaaS 部署的情形，尽管其实际上读起来的意思超乎了惯例的 SaaS 部署情形。其目标是解决在用户在使用像 Web Services 这样的功能时，其代码没有公开的常规 GPL 协议所暴露出的漏洞。因此，该协议的第 13 节，在 GPLv2 第 3 节以及 GPLv3 和 AGPLv3 第 6 节中包含的目标代码分发的触发要求之外，提供了额外的源代码公开的要求。

常常被误解的是，AGPLv3 第 13 节中的源代码分发要求仅在 AGPLv3 软件已被“你”（例如，提供网络服务的实体）修改的地方才触发。我的理解是，只要“你”不修改 AGPLv3 的代码，许可证就不应该被理解为需要按照第 13 节规定的方式访问相应的源码。如我所见，尽管即使公开许可证中不要求公开的源代码也是一个好主意，但在 AGPL 下许多未修改以及标准部署的软件模块根本不会触发第 13 节。

如何解释 AGPL 的条款和条件，包括 AGPL 软件是否已被修改，可能需要根据具体情况的事实和细节进行法律层面的分析。

作者简介：

Jeffrey R. Kaufman 是全球领先的开源软件解决方案提供商 Red Hat 公司的开源 IP 律师。Jeffrey 也是托马斯·杰斐逊法学院的兼职教授。在入职 Red Hat 之前，Jeffrey 曾经担任高通公司的专利顾问，向首席科学家办公室提供开源顾问。Jeffrey 在 RFID、条形码、图像处理和打印技术方面拥有多项专利。

via: https://opensource.com/article/17/1/providing-corresponding-source-agplv3-license

作者：Jeffrey Robert Kaufman 译者：geekpi 校对：Bestony

本文由 LCTT 原创编译，Linux中国 荣誉推出

Pengutronix 内核黑客 Jan Lübbe 总结了嵌入式 Linux 中正在不断增长的安全威胁，并在这次欧洲嵌入式 Linux 会议上概述了一个计划，以保持长期设备的安全和功能完整。 Linux 基金会

安全漏洞只发生在 Windows 上的好日子正在快速过去。恶意软件黑客和拒绝服务老手们正在越来越多地瞄准过时的嵌入式 Linux 设备，因此在 10 月的 欧洲嵌入式 Linux 会议 Embedded Linux Conference Europe （ELCE）上的几个演讲的主题就与修复 Linux 安全漏洞相关。

最值得去听的讲演之一是 Pengutronix 内核黑客 Jan Lübbe 的《长期维护或管理（或免管理）嵌入式系统 10 年以上》。在总结嵌入式 Linux 中不断增长的安全威胁后，Lübbe 制定了一项计划，以确保长期设备的安全和功能完整。 Lübbe 说：“我们需要迁移到更新、更稳定的内核，并进行持续维护以修复关键漏洞。我们需要做上游更新和自动化流程，并建立一个可持续的工作流程。我们没有理由让系统中仍留有过时的软件。”

随着 Linux 设备变得越来越老，传统的生命周期过程已经不再适用。 Lübbe 说：“通常，你会从 SoC 供应商或主线上获取内核、构建系统，并添加到用户空间。你可以定制和添加程序，并做一些测试。但是，在此之后有 15 年的维护阶段，你最好期望平台不会发生变化、不会想要添加新的功能、不需要实施管理调整。”

所有这些变化，越来越多地导致你的系统暴露出新的错误，并需要大量更新以才能与上游软件保持同步。 Lübbe 说：“在内核中发生导致问题的错误并不总是无意的”。对于去年在 Allwinner 内核中发现的后门，他又补充说：“这些供应商的内核从来不会执行主线内核社区的审查流程”。

Lübbe 继续说：“你不能认为你的供应商一直没问题。也许只有一两个工程师查看过后门代码这块。如果补丁发布在 Linux 内核邮件列表上，就不会有这种事，因为总会有人注意到。硬件供应商不关心安全或维护，也许你会在一两年后得到更新，但是即使这样，他们从一个固定版本开始开发，到他们发布稳定的版本通常需要几年的时间。如果你在这个基础上再开始开发，可能又过了半年，这就更过时了。”

越来越多的嵌入式开发人员在 长期稳定 Long Term Stable （LTS）内核上构建长期产品。但这并不意味着没事了。Lübbe 说：“一个产品发布后，人们经常不再遵循稳定的发行链，也不再应用安全补丁。这样你会得到两个最糟糕的结果：过时的内核和没有安全性。你失去了多人测试的好处。”

Lübbe 指出，使用像 Red Hat 这样的面向服务器的发行版的 Pengutronix 客户经常由于快速的定制、需要系统管理员干预的部署和升级系统而遇到问题。

“更新对一些东西有用，特别是在 x86 上，但每个项目基本上是自己建立基础设施来更新到新版本。”

许多开发人员选择把向后移植作为更新长期产品的解决方案。Lübbe 说：“开始时很容易，但是一旦你不处于项目的维护范围，他们就不会告诉你所使用的版本是否受到一个 bug 的影响，因此很难判断一个修复是否相关。于是你不停打补丁和更新，而 bug 也在不断累积，而这些你必须自己维护，因为其他人不使用这些补丁。使用开源软件的好处就丢失了。”

跟随上游项目

Lübbe 认为，最好的解决方案是跟踪由上游项目维护的版本。“我们主要关注基于主线内核的开发，所以我们在产品和主流内核及其他上游项目之间尽可能没有差别。长期系统在主线内核上得到很好的支持。大多数不使用 3D 图形的系统只需要很少的补丁。较新的内核版本还有很多新的强化功能，这些可以减少漏洞的影响。

跟随主线发展对许多开发人员来说似乎令人畏惧，但是如果从一开始就这样，然后坚持下去，就会相对容易一些，Lübbe 说：“你需要为系统上做的一切制定流程。你总需要知道什么软件正在运行，这在使用良好的构建系统时会更容易。每个软件版本应定义完整的系统，以便你可以更新相关的一切。如果你不知道那里有什么，你就不能解决它。你也需要一个自动测试和自动部署更新。”

为了“减少更新周期”，Lübbe 建议在开始开发时使用最新的 Linux 内核，并且在进入测试时才转到稳定的内核。之后，他建议每年将系统中的所有软件（包括内核、构建系统、用户空间、glibc 和组件（如 OpenSSL））更新为当年上游项目支持的版本。

Lübbe 说：“得到更新并不意味着你需要部署。如果没有看到安全漏洞，你可以把补丁放在一边，需要时它再用就行。”

最后，Lübbe 建议每个月查看发布公告，并且每周检查 CVE 和主线列表上的安全公告。你只需要问自己“该安全公告是否影响到了你”。他补充说：“如果你的内核足够新，就没有太多的工作。你不会希望通过在新闻中看到你的设备才获得有关你的产品的反馈。”

via: https://www.linux.com/news/event/ELCE/2017/long-term-embedded-linux-maintenance-made-easier

作者：ERIC BROWN 译者：geekpi 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

今年像动态插件，Serverless Go 以及 HTTP/2 这些创新对你的开发意味着什么？

Go 1.8 刚刚发布，它有几个新功能，包括：

• HTTP/2 Push
• HTTP 服务器平滑关闭
• 插件
• 缺省 GOPATH

这些新功能的影响力取决于你和开发团队如何使用 Go。 自从 Go 1.0 于 2012 年发布以来，其简单性、并发性和内置支持使其保持普及度不断增长，所以对“Go 擅长什么”的答案一直在增长。

这里我会提供一些想法，包括新到来的版本及 Go 世界最近其它吸引我的地方。这不是一个详尽的列表，所以请让我知道你认为在 2017 年 Go 还会发生哪些重要的事。

Go 的超级可部署性 + 插件 = 容器、任何东西？

1.8 版本已经发布，我已经与其中几个人交谈过添加动态插件会如何影响像容器之类的事物，动态插件是为了加载在编译时不是程序一部分的共享库的代码。 动态插件使容器中的高并发微服务变得更加简单。 你可以轻松地以外部进程的方式加载插件，同时具备在容器中微服务的所有好处：保护你的主进程不会崩溃，并且没有任何东西会搞乱你的内存空间。 对插件的动态支持应该是在 Go 中使用容器的福音。

关于专家现场 Go 培训，请注册 Go Beyond the Basics。

跨平台支持仍在吸引开发人员

在 Go 开源之后的 7 年里，它已被全球采用。Daniel Whitenack 是一名数据科学家和工程师，他为 Jupyter 维护 Go 内核，告诉我最近他在西伯利亚做数据科学和 Go 语言培训，（是的，在西伯利亚！数据科学和 Go - 之后再细讲一下...）并 “很惊讶地看到那里 Go 社区是如此活跃和积极。” 人们继续在项目中采取 Go 的另一个很大的原因是交叉编译，对此，几个 Go 专家解释说这在 Go 1.5 版本中变得更容易了。来自其他语言（如 Python）的开发人员应该发现，在没有 VM 的目标平台上，能够为多个操作系统构建捆绑的、可部署的应用程序是在 Go 中工作的关键。

在 1.8 版本中对跨平台的支持，再加上提升了 15% 的编译速度，你就可以看到为什么 Go 是初创公司最喜欢的语言。

有兴趣了解 Go 的基础知识吗？查看 Go 基础学习路径 让 O’Reilly 专家来带你开始。

Go 解释器在开发中；再见 Read-Eval-Print-Loop

有一些聪明的家伙正在做一个 Go 解释器，我一定会持续关注它。如你所知的那样，有几个 Read-Eval-Print-Loop（REPL）的解决方案可以用来评估表达式，以确保代码如你预期的工作，但那些方法通常意味着容忍一些不便，或需要费力从几个方案中找到一个适合你的用例的。有一个健壮、一致的解释器就太好了，一旦我了解到更多消息，我会告诉你们。

在开发中使用 Go 复杂特性？观看 O'Reilly 的视频训练 中级 Go 。

Go 的 serverless - 会是什么样子？

是的，现在围绕 serverless 架构（功能即服务（FaaS））有很多炒作。但有时候也有些捉摸不定的地方，那么关于 Go 的 serverless 发生了什么？我们能在今年看到一个 Go 语言原生支持的 serverless 服务么？

AWS Lambda 是最知名的 serverless 提供商，不过 Google 最近也推出了 Google Cloud Functions。这两个 FaaS 解决方案使你可以在无须管理服务器的情况下运行代码，你的代码存储在别人为你管理的服务器集群上，并且仅在触发事件调用它时运行。AWS Lambda 目前支持 JavaScript、Python 和 Java，还可以启动 Go、Ruby 和 bash 进程。 Google Cloud Functions 只支持 JavaScript，但很可能不久将支持 Java 和 Python。许多物联网设备已经使用 serverless 方案，随着 Go 越来越多地被创业公司采用，serverless 似乎是一个可能的增长点，所以我在关注这些 serverless 解决方案中 Go 的开发情况。

已经有几个框架可以支持 AWS Lambdas：

• λ Gordon - 使用 CloudFormation 创建、连接及部署 AWS Lambdas
• Apex - 构建、部署及管理 AWS Lambda 函数
• Sparta - AWS Lambda 微服务的 Go 框架

还有一个 AWS Lambda 替代品支持 Go：

• Iron.io：建立在 Docker 和 Go 之上；语言未知；支持 Golang、Python、Ruby、PHP 和 .NET

有关 serverless 架构的更多信息，请观看 Mike Roberts 在旧金山 O'Reilly 软件架构会议上的演讲主题：serverless介绍。

数据科学中的 Go

我在本文开头暗示了这一点：也许令人惊讶的是很多人都在使用 Go 进行数据科学和机器学习。关于它是否适合还有一些争论，但基于像 《Gopher 学院之 2016 年终》那样的年度文章中，你会注意到 30 篇文章中至少有 4 篇是关于机器学习或分布式数据处理，它们正在像我们走来。

我之前关于 Go 的易部署性的观点可能是数据科学家使用 Go 的一个关键原因：他们可以更轻松地在易读而可用于生产环境的应用程序中向他人展示数据模型。与此相结合的是 Go 的广泛使用（正如我前面提到的，它正变得越来越流行！），而且有数据专家创建“可用并且与其它程序配合”的程序。任何使用 Go 构建的应用数据科学家会在公司其他部分使用相同的语言，或者至少它非常适合现代架构。

更多关于 Go 的数据科学，Daniel Whitenack 写了一个很好的概述，解释了如何使用它： Data Science Gophers。

作者简介：

O'Reilly Media 的监督编辑，与编辑团队合作，涵盖各种各样的编程主题。

via: https://medium.com/@sconant/5-things-to-watch-in-go-programming-in-2017-39cd7a7e58e3#.8t4to5jr1

作者：Susan Conant 译者：geekpi 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

探索 rsync 在备份方案中的作用。

在系统管理员的工作中备份无疑是一个重要的部分。当没有完整备份或者良好规划的备份和实施时，就可能或早或晚不可挽回地丢失重要的数据。

所有公司，无论大小，都运营在数据之上。考虑到丢失业务数据造成的经济和业务损失，从最小的个人公司到最大的跨国企业，没有一个公司能在丢失大部分数据以后得以幸存。你的办公室可以通过保险赔偿重建，但是你的数据就不可能再恢复了。

这里提到的丢失是指数据的完全损坏。而不是指数据被偷走，那是另一种灾难。我这里说的是数据被完全摧毁。

即使你只是个人用户而不是一个企业，备份你自己的数据也是非常重要的，我有二十年来的个人财务数据和我现在已经关闭的企业的数据，以及大量的电子发票。也包括近年来我创作的大量不同类型的文档、报告和数据报表。我不想失去任何这些数据。

所以备份是我数据长期安全的必要保障。

备份软件选择

有许多软件可以执行备份。大多数 Linux 发行版提供至少一种开源的备份软件。同时也有许多商业备份软件，但是这些都不符合我的需求，所以我决定使用基础的 Linux 工具来进行备份。

在我为 Open Source Yearbook 写的文章， 最佳搭档之 2015：tar 和 ssh 中，我说明了昂贵的商业备份软件在设计实施可行的备份计划中并不是必要的。

从去年开始我尝试了另一种选择， rsync 命令，它有许多我已经从中受益的有趣特性。我的主要需求是所创建的备份，用户不需要解压备份压缩包就能定位和恢复文件，以便节约创建备份的时间。

这篇文章的目的只是为了说明 rsync 在我的备份方案中的作用。并不是 rsync 的全部能力或者它的各种适用场景的概览。

rsync 命令

Andrew Tridgell 和 Paul Mackerras 编写了 rsync ，首次发布于 1996 年。它的目标是向另一台电脑同步文件。你注意到了他们为什么取这个名字了吗（remotely synchronize）？它是大多数发行版都提供的开源软件。

rsync 能够用于同步两个目录或目录树，无论它们是在同一个计算机上还是不同的计算机上，而且不仅如此，它还能做到更多。它创建或者更新的目录与源目录完全一样。新的目录不是以 tar 或 zip 等打包存储，而是普通的目录和文件，常见的 Linux 工具都能轻松访问，而这正是我所需要的。

rsync 的最重要的特性之一是它处理源目录被修改的已有文件的方式。它使用分块校验来比较源文件和目标文件，而不是从源把整个文件复制过去。如果两个文件所有块的校验和都相同，那么就不用传输数据。否则只有被改变的块被传输。这样节约了远程同步消耗的大量时间和带宽。比如，我第一次使用 rsync 脚本来把我所有的主机备份到一个外接的大型 usb 硬盘上需要三个小时，因为所有的数据都需要传输过去。而接下来的备份需要的时间就只是 3 到 8 分钟，这取决于上次备份以来创建和改变了多少文件。我使用 time 命令来记录实际花费的时间。昨天晚上，我只花了三分钟来从六个远程系统和本地工作站备份大概 750 Gb 数据。实际上只有在白天改变的几百 Mb 数据需要备份。

下面的命令可以用来同步两个目录及其任意子目录的内容。也就是说，在新目录的内容和源目录同步完之后，它们的内容完全一样。

rsync -aH sourcedir targetdir

-a 选项表示归档模式，它会保持权限、所有关系和符号（软）链接。-H 选项用来保持硬链接。注意源目录和目标目录都可以在远程主机上。

假设昨天我们使用 rsync 同步了两个目录。今天我们想再同步一次，但是我们从源目录删除了一些文件。rsync 默认只复制新的和改变过的文件到新目录里，而不去改变新目录里被我们删除的文件，但是如果你想让那些在源目录里被删除的文件在新目录里也被删除，那么你可以加上 --delete 选项来删除。

另一个有趣的选项，也是我个人最喜欢的选项是 --link-dest，因为它极大地增加了 rsync 的能力和灵活性。--link-dest 使每日备份只花费很少的额外空间和很短的时间。

用这个选项指定前一天的备份目录，以及今天的备份目录，然后 rsync 会创建今天的新备份目录，并将昨天备份目录里的每一个文件在今天的备份目录中创建硬链接。现在我们在今天的备份目录中有一大堆指向昨天备份的硬链接。文件没有被重复创建，而是创建了一些硬链接。对于硬链接，在 Wikipedia 中有非常详细的描述。而在用昨天的备份目录文件的硬链接创建了今天的备份之后，rsync 和平常一样进行备份，如果在文件中检测到了变化，就不会做硬链接，而是从昨天的备份目录里复制一个文件的副本，再把源文件中变化的部分复制过去。（LCTT 译注：此处疑似原文表述不清，参见 generator.c 的 try_dests_reg 函数，先根据 match_level 选择复制或者硬链接，而不是创建硬链接后再判断 match_level）

现在我们的命令类似于下面这样。

rsync -aH --delete --link-dest=yesterdaystargetdir sourcedir todaystargetdir

你也可能想要排除一些不想要备份的目录或者文件。那么就可以使用 --exclude 选项。用这个选项加上你想排除文件或目录的模式。你可以用下面的新命令来排除浏览器的缓存。

rsync -aH --delete --exclude Cache --link-dest=yesterdaystargetdir sourcedir todaystargetdir

注意：你想排除的每一个文件的模式前面都分别需要加上 --exclude 选项。

rsync 可以同步远程主机，无论是作为同步源头还是目标。再举一个例子，我们假设想要把名为 remote1 的远程主机的目录同步到本地。因为 ssh 作为与远程主机交换数据的默认协议，我一直使用 ssh 选项。现在命令类似于下面这样。

rsync -aH -e ssh --delete --exclude Cache --link-dest=yesterdaystargetdir remote1:sourcedir todaystargetdir

这就是我的 rsync 备份命令的最终版本。

你可以依靠 rsync 的大量选项来定制你的同步过程。大多数情况而言，我刚刚描述的简单命令就足以胜任我的个人需要。你可以阅读 rsync 丰富的文档来了解它的其他能力。

部署备份

我的备份自动运行因为—“万物皆可自动化”。我写了一个 BASH 脚本使用 rsync 创建每天的备份。包括确保备份介质被挂载，生成每天的备份目录的名字，以及在备份介质中创建合适的目录结构，最后执行真正的备份再卸载备份介质。

我用 cron 每天早晨执行脚本确保我永远不会忘记备份。

我的脚本 rsbu 和配置文件 rsbu.conf 可以在 GitHub 上获取。

恢复测试

所有没有经过测试的备份计划都不完整的。你可以通过测试恢复某个文件或者整个目录，以确保备份在照常工作并且可以通过它来在数据全部丢失后恢复。我见过太多备份由于种种理由失败，以及由于缺乏测试忽略的问题导致宝贵的数据被丢失。

选择一个文件恢复到比如 /tmp 的测试目录，这样你就不会覆盖任何备份后被更新的文件。验证文件的内容是否是你预期的。恢复用 rsync 备份的文件仅仅只是找到你的备份文件然后把它复制到你想恢复的地方去那样简单。

我有几次不得不恢复我的个人文件，偶尔是整个目录。大多数是自己意外删除了文件或者目录。有几次是因为硬盘崩溃。这些备份迟早会派上用场。

最后一步

但仅仅创建备份并不能拯救你的业务，你需要定期的地创建备份，使最近的一次备份储存在另一台远程机器上，如果有可能，放在另外一个建筑物中或几英里之外。这样可以确保大规模的灾难不会摧毁你的所有备份。

对于小型企业的一个合理选择是在可移动介质上做每日备份，晚上把最新的备份带回家里，第二天早上把更早的备份带到办公室。你就会有几个轮流的拷贝。甚至可以把最新的备份带到银行并放到你的保管箱里，然后带回之前的备份。

作者简介：

David Both - 他居住在北卡罗来纳州的罗列，是 Linux 和开源提倡者。他已经从事 IT 行业 40 多年。在 IBM 教授了二十多年 OS/2。在 IBM 的时候，他在 1981 年为最初的 IBM 个人电脑编写了第一门培训课程。他为红帽教授 RHCE 课程，并曾在世通公司、思科、北卡罗来纳州政府工作。他使用 Linux 和开源软件已经有二十年左右了。

via: https://opensource.com/article/17/1/rsync-backup-linux

作者：David Both 译者：trnhoe 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出