标签: backup

我正在通过千兆位从服务器到 NAS 备份 ~800GB（目标是安装在我需要备份的服务器上的共享）。您会为 volsize 推荐什么值？

谢谢

如果我运行的是现代 vmware ESXi 系统，我可以通过 SSH 将静态链接的 rsync 二进制文件和 rsync 文件放入任何目的地。

我试图理解为什么大多数（全部？）vmware 来宾备份不是通过这种方式完成的。

如果 VM 正在运行，您可以简单地使用“vim-cmd vmsvc/snapshot.create”来创建快照，然后将该快照同步到远程主机。（甚至可以选择“停顿”快照）

或者，如果您想要更强大的备份，您可以优雅地停止 VM 并通过 vmdk 文件进行 rsync。

所以......看起来我是一个简单的shell脚本，远离我想要做的所有备份，简单而轻松，使用普通的旧rsync。

我在这里错过了什么？

当询问 Gitlab 支持如何在内部部署的 Gitlab 上进行 3TB 备份时，他们回答使用我们的工具来生成 tarball。

这在所有层面上对我来说都是错误的。这个 tarball 包含 postgres 转储、docker 图像、repo 数据、GIT LFS 等配置等等。将 TB 的静态数据与 KB 非常动态的数据一起备份是不正确的。然后是问题，我们想每小时做一次备份。

题

我真的很想从其他人那里知道他们是如何做到的，以获得一致的备份。

Linux 上的 ZFS 对我来说没问题，如果这是解决方案的一部分。

SharePoint 2007 带有一个内置的备份工具，但我听说过它的坏处。即，您可以备份但不能恢复配置数据库，并且通常恢复总是一种信心的考验。

我想知道是否有一些“最佳实践”或强大的备份（和还原）解决方案？

我正在使用tar将 linux 服务器备份到磁带。我正在使用使用-j压缩文件的选项bzip2，但是我看不到从 tar 调整 bzip2 块大小选项的方法。默认块大小为 900,000 字节，这提供了最佳压缩但最慢。我对压缩率并不那么在意，所以我希望以较小的块大小使 bzip2 运行得更快。

我们使用单独的TRAC实例作为许多项目的票务系统，并且需要每天多次将它们移出现场以进行灾难恢复。

实现这一目标的最佳方法是什么？有没有类似于svnsync 的用于颠覆的东西？

我有一个由大约 30 台 Windows PC 组成的网络。

有什么好的免费软件可以自动（计划）为这些 PC 进行备份（不是整个 HDD，而是仅某些文件夹）并保存在仅用于存储备份的远程服务器上？服务器最好运行 Linux，备份将通过 FTP 存储，其中每台 PC 都有自己的 FTP 帐户。

我使用 rsync 备份服务器，但这些备份非常大，我想压缩它们。有没有办法在 rsync 周围使用某种包装器来压缩备份中的文件，rsync 实时文件中的更改，然后在复制后立即重新 gzip 文件？

即如果 live 上的源文件是foo、bar和baz，则备份有foo.gz、bar.gz和baz.gz。

重申：我想要一端是压缩文件，另一端是未压缩文件。我不想在 rsyncing 之前进行压缩，因为即使使用 --rsyncable，它也会降低 rsync 的效率。我知道 rsync 的 -z 选项。我在备份机器上没有空间来存储所有未压缩的文件。

我正在考虑使用云服务来备份我客户的网站之一。

我（客户）的主要关注点是（按重要性降序排列）

1. 保护知识产权（商业秘密、源代码）、用户帐户详细信息等
2. 服务提供商提供的正常运行时间保证（以最大限度地减少网络服务器停机时间）
3. 成本
4. 上传/下载速度

理想情况下，我想要没有长期联系的服务（即我更喜欢一种“现收现付”服务）

我还想避免供应商锁定，因为几乎不可能转移到其他服务。

我想要一些关于以下方面的一般准则：

1. 如何选择服务提供商
2. 谁是该领域的主要参与者
3. 推荐软件用于：备份/恢复/和上传/下载保存/恢复的文件

服务器软件要么是 Ubuntu 要么是 Debian（我可能会发布一个关于将哪个操作系统用作服务器的问题 - 我已经熟悉 Ubuntu）

您已输入 Amazon EC2 EBS 支持的 Windows 映像 010 的介绍性备份...

我一直在绞尽脑汁想为我们运行 SharePoint Services 的单个 Windows 2008 服务器找到一个简单的备份策略。这是具有一个数据卷的一台服务器的 EBS 支持的映像。我不需要任何异国情调的东西。我只需要“每日”备份（丢失一天的数据并不是灾难性的）。

我们创建并保存了一个 EBS 支持的 AMI 映像 (Windows 2008)，我们可以轻松使用。我们开始通过简单地创建一个新的 EBS AMI 映像来进行备份。这真的很简单，但是正在运行的服务器在创建映像的前 10 到 15 分钟内处于离线状态——这并不理想。

创建备份的标准方法似乎是创建附加到正在运行的实例的卷的快照。同样，它非常简单，服务器在快照生成期间仍然可用。显而易见的第 22 条规则是您不能简单地直接从快照启动新实例。

我知道如何将正在运行的实例绑定到 S3 存储，然后从 S3 存储桶注册 AMI。这确实允许我捕获正在运行的实例的备份，如果正在运行的实例丢失，则从 S3 存储桶注册 AMI 并启动新的 AMI 以恢复实例，但这似乎真的很复杂，而且不得不这样做似乎很荒谬在 AWS 控制台和 Firefox 的 S3 Organizer 插件之间来回切换以实现这一目标。（请不要提及命令行方法，这是一门 010 级别的课程）。

通过使用 EBS 支持的图像，以下方法似乎对我有用（全部在 AWS 控制台中完成）：

1.对于您的备份，只需根据需要对系统卷 (/dev/sda1) 进行快照。2.如果您丢失了正在运行的实例，请执行以下操作： a. 从上次快照备份创建一个新卷 b. 启动启动 AMI 的另一个实例（必须由 EBS 支持） c. 停止此实例。d. 将现有系统卷与新停止的实例分离并丢弃。e. 将新创建的卷作为系统卷 (/dev/sda1) 附加到停止的实例。f.重新启动新实例。我已经测试了几次，它似乎对我有用。

问题：这种方法有什么问题吗？