每个人都使用源代码控制来管理版本（对吗？），这提供了某种程度的备份。但是，有时您的本地副本与存储库不同步。此外，一些沙盒类型的项目可能还没有 ;-) 进入 SCC。
编辑：我的项目目录中有多个项目。并非所有都在当前开发中，但只要发现错误，其中任何一个都可能需要“修复”。从 SCC 恢复单个活跃的项目似乎完全合理。从 SCC 恢复我支持的所有几十个项目似乎不如从备份恢复并根据需要从 SCC 同步。
除了源代码控制之外，您还使用哪些备份策略来保证代码安全？
可以在https://stackoverflow.com/questions/38388/organization-wide-backup-strategy找到类似的问题，但如果您碰巧在没有总体战略。我将在答案中提供我的策略。
我的策略始终是签入并备份整个存储库。
我从不遗漏任何东西，我确保定期备份（每天增量、每周和每月轮换）正在发生并且正常运行。
在一天结束时，我将我的代码检查到源代码管理中。
在午夜左右，Mozy启动并在异地备份我的代码。
在凌晨 1 点左右，SC 盒子被备份到磁带上。
在凌晨 3 点左右，Syncback SE 醒来并将我的代码备份到外部 HD。
一整天，我的工作盒使用Live Sync与我的家庭盒同步
（除了远程服务器的源代码控制）我使用免费版本的 SyncBack (www.2brightsparks.com) 和这个批处理文件：（syncback.exe 的参数指定以前配置的 syncback 备份配置文件）
@echo off
echo Stop and start SQL Server
echo -------------------------
net stop "SQL Server (SQLEXPRESS)"
net stop "SQL Server (SQLSERVER2008)"
echo -----------------------------------------------------------
echo Back up running now... please wait.
"C:\Program Files\2BrightSparks\SyncBack\SyncBack.exe" c e-contents f-contents
echo Backing up done. Starting SQL Server...
echo -----------------------------------------------------------
net start "SQL Server (SQLEXPRESS)"
net start "SQL Server (SQLSERVER2008)"
echo -----------------------------------------------------------
echo Back up is done and SQL Server is running now.
echo -----------------------------------------------------------
pause
每天有两个 8GB 闪存驱动器。在本周末，我会做同样的事情，但随后将目标放在桌面外部驱动器上。
SyncBack 很棒！
OSX 的时间机器
在我看来，时不时地从 SCC 重建所有内容无论如何都是一个好习惯（例如在夜间）。这样做可以确保您没有忘记将任何重要文件添加到存储库。无论如何，整个过程最多需要几个步骤。
我使用Microsoft SyncToy 2.0将我的项目目录与网络共享上的文件夹同步。我有单独的计划任务，它们为各种目录运行不同的 SyncToy 脚本（按 Visual Studio 版本细分）。
对于除了最简单的 5 分钟测试之外的所有内容，我使用版本控制，在我的例子中是 Subversion。
我使用了一些运行 linux 的旧硬件和一个我承诺的 Subversion 服务器。然后我有一个 cron 脚本，每晚归档存储库（如果自上次更改后），并将其以邮件的形式附加到我的 gmail 帐户，正文中包含更改日志。由于 Gmail 的 20 mb 附件限制，除了最密集的二进制存储库之外，所有存储库都可以通过拆分文件进行备份。
我计划重新设计以将备份放在 Amazon S3 上，但还没有时间去做。
恕我直言，最重要的是始终在其他地方（地理上）进行备份，而不仅仅是在 USB 驱动器或其他东西上。
在非常小的 5 分钟的情况下。测试我把它们放在我的 Dropbox (www.getdropbox.com) 中。
如果磁盘驱动器死机，没有人愿意从 SCC 重建他们的整个项目目录
嗯？我们总是这样做。事实上，我们有一个构建服务器，它可以从干净的结帐中不断地执行新的构建。如果从备份恢复似乎比从 SCC 恢复更好，您需要改进您的 SCC。
对于所有尚未准备好投入生产的代码，我们在 SCC 中有一个名为“playground”和“junk”的目录。
尽管这是一个主观的答案，但我认为您没有正确使用源代码控制。
是的，您的本地副本通常与存储库不同步，但是任何给定的更改都应该只是少量的工作（例如，您不应该有连续几天没有签入的东西）。如果您经常提交，那么在驱动器丢失（盗窃/故障/等）的情况下，您会损失少量（通常<1天）的工作。
如果您正在做一些对其他开发人员造成破坏的完全疯狂的事情，那么您应该在一个分支中工作。完成后，将更改合并回来。
您还应该能够随时从您的 SCC 系统重建项目。时不时地做一件好事，只是为了确保您需要构建的所有内容都在 SCC 中 - 有时文件会丢失，而您永远不会注意到，因为您总是从您一直使用的工作副本构建过去 6 个月。
我使用Unison在家里的两台不同机器上复制我的整个主目录。这样，如果我马虎或者我有 20 年前的文件不受源代码控制（.emacs）我仍然有一定的保护措施。我还在工作的机器上复制除了个人文件（照片、音乐）之外的所有内容。
版本控制 (SVN) 对我来说绰绰有余。然而，有一些规则：
不要使用双向同步工具进行备份
...好吧，至少不会自动
同步工具（例如 unison）正在同步两个（或更多）位置。因此，如果您不小心弄乱了某个位置的文件，则该混乱将转换为另一个位置，而您不会注意到。
我们还检查所有内容（尽早检查并经常检查）并使用 tar 和 ftp 将整个存储库 (CVS) 备份到我们的备份服务器。
当你写的东西（还）不属于主构建时，创建一个分支。当它应该进入主构建时，将您的分支与它合并。
分布式 VCS 还使本地分支变得非常容易，中央存储库永远不会知道它们的存在。
通过将更改推送到远程副本来备份本地存储库（分布式 VCS）非常简单，以至于我使用 git 作为大多数文档、配置文件以及基本上任何非二进制文件的主要备份方法。
如果您在很长一段时间内偏离源代码控制，那么您需要一些分布式源代码控制。
我正在开发一种名为“Transactor Code Agent”的产品，它旨在满足您的要求。
它为您的源文件提供本地备份和版本控制。
它使您可以将现有的源代码控制设置用于其用途（管理多个开发人员在多个版本中“大部分完成”的工作），同时为您正在进行的工作提供自动备份和本地文件版本控制。
测试版应该在一月份的某个时候发布。
您可以在以下位置查看我们的“网站”（有点粗糙）
那里有一个表格，您可以使用它来注册私人测试版。
更新：
根据我在评论中得到的一些反馈，这里有更多信息：
1）我有反对源代码控制的事情吗？
不！我认为源代码控制是一件很棒的事情。如果使用得当，它为管理软件生命周期提供了一个巨大的工具。
但是，如果使用得当，源代码控制会留下很大的空白，因为它在完成之前无法保护开发人员的工作。我们需要的是专注于单个程序员正在进行的工作的东西。代码代理就是这样做的。
换句话说，源代码控制是一种旨在让老板的生活更轻松的工具（因为它有助于随着时间的推移管理功能和更改以及团队和版本）
Code Agent 是一款旨在让您的生活更轻松的工具（因为它确保您的工作始终得到保存）。
未签入（并因此备份）到您的 VCS 的代码不存在。它并不比你头脑中的代码更真实。真的就是这么简单。
我使用了一个产品（我写的，它是我的 micro-isv），称为 Transactor Code Agent。它是专为程序员设计的备份工具。
它监视您的源代码，每次您保存更改时，它都会备份它并为您保留本地历史记录。
我认为它在备份方面比源代码控制效果更好，原因如下：
你可以在这里下载它的演示：
因为我使用 TFS（Team Foundation Server），所以我只备份 SQL Server 数据库，就像我使用的任何其他数据库一样
万一出现任何问题，我有时会通过电子邮件将我正在处理的重要邮件发送到 webmail 帐户，例如 yahoo 或 hotmail。我知道每个人都在谈论从纸质到数字化的转变，但有时你永远不知道会发生什么，所以我会打印出纸质版。显然，这不是最好的解决方案，尤其是对于大型项目而言，因此我通常会将硬拷贝限制为更小、更重要的部分。我也倾向于有点偏执，所以我最终会采取备份备份的备份。
我使用 rdiff-backup 通过 SSH 对我的笔记本电脑执行每日增量备份。它使用 deltra 压缩（如 rsync），因此速度非常快。它还允许您在备份数据中返回任意天数，以便您可以在完成一些复杂的代码之后立即返回，但在您不小心将其全部删除之前。
开始有点棘手，但在我看来非常值得。
除了颠覆之外，我还使用crashplan进行在线异地备份。它还可以备份到本地存储和其他计算机（尽管不幸的是，目前似乎需要在每个目的地存储相同的备份集 - 即不能在异地存储少量重要的东西，而在本地存储更大的集。）
我还使用了 unison（对于太大而无法在异地备份的东西——音乐、电影等）和 OSX 时间胶囊，这样在数据丢失的情况下，我可以在不求助于在线备份的情况下进行恢复。在线备份适用于房屋被烧毁或被盗等灾难。
但是，有时您的本地副本与存储库不同步。此外，一些沙盒类型的项目可能还没有 ;-) 进入 SCC。
首先，您应该尽量减少代码“超出”SCC 的时间。不是为了备份目的，而是为了跟踪什么时候做了什么，特别是为什么。提交评论是无价的。包含 3000 个文件并带有“初始修订”消息的大型签入不是很有用。
沙盒项目参数确实有一定的分量，但是您应该像对待所有其他文件一样对待它。将它们备份到外部 USB 驱动器或其他任何东西。如果您没有备份所有其他文件，我建议您现在开始。
而且，当然，如果磁盘驱动器死机，没有人愿意从 SCC 重建他们的整个项目目录——从实际备份中恢复要好得多。
这不只是svn checkout吗？为什么不只是“从 SCC 重建”？
Subversion：服务器由 Beanstalk 管理，客户端使用 Tortoise SVN。每次编码会话后，所有内容都会返回到 SVN 存储库，因此我永远不必担心丢失代码。我还定期将最新代码备份到 CD 并将其锁定在保险库中以确保安全！
另外，请记住，您的代码只是等式的一部分。大多数现代开发环境本身都需要大量定制（集成第 3 方工具是一个明显的例子，但仅使用适当的选项安装 IDE 也需要相当长的时间）。因此，我也在一个可以轻松备份到外部硬盘驱动器的虚拟机中进行所有开发。这些也被锁定在保险库中。
最后，我备份了一个“参考”数据库来完成图片。我不能只备份模式，因为在我的产品中，数据库中保存了重要的系统数据（例如，与网站一起提供的内容）。
我使用MozyPro自动对我机器上的当前代码以及源代码控制数据库进行异地备份。这每晚都会递增运行。
在线（互联网）备份是该过程的重要组成部分。
对外部驱动器的所有类型的备份都注定会失败，除非它们是由指定的个人（例如秘书）进行的。如果您是一家非常小的商店（或像我这样的 µ-ISV），这不是一个选择。即便如此，外部驱动器保存在哪里？带防火功能的保险箱是唯一可能的好答案。将它们存放在异地并不好：人们会忘记将其带回办公室进行定期备份。
恕我直言，备份到 NAS 是比外部驱动器更好的解决方案。但是在建筑物着火的那一天，异地备份是您生存的唯一机会。
除了 SCC DB 之外，我个人还使用Mozy来备份主要的本地目录。
不用说，AES-256 或类似的加密对于将源代码存储在其他人的硬盘驱动器上是必不可少的。Mozy 及其所有严肃的竞争对手都提供它。
来自 joelonsoftware 的 joel 在一些帖子中说，如果构建和部署您的项目需要两个以上的命令行（或准备工作超过一分钟），那么您做错了。我完全同意他的观点，我认为单片机就足够了。备份系统仅适用于灾难性灾难（硬盘故障、火灾和龙卷风）。