restic version
Restic 0.1.0
使用go1.6.3于2016-07-20 12:42:43编译
还原后,所有目录都应还原。
仅还原一个目录。
/tmp/restic/FILESNEW01/Dir01/Test01.txt
/tmp/restic/FILESNEW01/Dir01/Test02.txt
/tmp/restic/FILESNEW01/Dir01/Test03.txt
/tmp/restic/FILESNEW02/Dir01/Test01.txt
/tmp/restic/FILESNEW02/Dir01/Test02.txt
/tmp/restic/FILESNEW02/Dir01/Test03.txt
文件内容:
cat /tmp/restic/FILESNEW01/Dir01/Test0*
Content file. /tmp/restic/FILESNEW01/Dir01/Test01.txt
Content file. /tmp/restic/FILESNEW01/Dir01/Test02.txt
Content file. /tmp/restic/FILESNEW01/Dir01/Test03.txt
cat /tmp/restic/FILESNEW02/Dir01/Test0*
Content file. /tmp/restic/FILESNEW02/Dir01/Test01.txt
Content file. /tmp/restic/FILESNEW02/Dir01/Test01.txt
Content file. /tmp/restic/FILESNEW02/Dir01/Test03.txt
我要备份
命令:
在/ tmp / restic / BACKUP目录中启动存储库
进行备份
scan [/tmp/restic/FILESNEW01/Dir01 /tmp/restic/FILESNEW02/Dir01]
scanned 2 directories, 6 files in 0:00
[0:00] 16.67% 0B/s 51B / 306B 0 / 8 items 0 errors ETA 0:00
duration: 0:00, 0.01MiB/s
snapshot 4d197b90 saved
检查存储库中是否存在备份
ID Date Host Directory
4d197b90 2016-07-26 14:14:43 nebss /tmp/restic/FILESNEW01/Dir01
/tmp/restic/FILESNEW02/Dir01
恢复备份
restoring <Snapshot 4d197b90 of [/tmp/restic/FILESNEW01/Dir01 /tmp/restic/FILESNEW02/Dir01] at 2016-07-26 14:14:43.208840145 +0300 EEST> to /tmp/restic/RESTORE/
检查目录/文件是否存在
Dir01
Content file. /tmp/restic/FILES01/Dir01/Test01.txt
Content file. /tmp/restic/FILES01/Dir01/Test02.txt
Content file. /tmp/restic/FILES01/Dir01/Test03.txt
感谢您报告此问题,我认为这是一个错误。
只要顶级目录具有相同的名称,就可能发生。 因为未还原完整路径,所以仅顶层目录。
解决方案是在还原时重建完整路径,并将每棵树还原到完整路径。 因此,结果路径将类似于/tmp/restic/tmp/restic/FILESNEW0{1,2}/Dir01/
。 我认为这是可以接受的。
补丁是否需要在还原过程中实施?
还是必须在备份过程中通过构建包含完整路径组件的其他顶级树来完成?
我也怀疑是这种情况。 目前,restic的工作方式如下:
当称为restic backup A/foo B/foo
它将在存储库中创建一个树形结构,如下所示:
├── foo
└── foo
因此,仅采用从参数到backup
命令的最后一个路径组件,这将导致在还原此类快照时出现问题。
为了纠正此问题,我建议实现与tar
相同的行为,在这种情况下,将创建以下树:
.
├── A
│ └── foo
└── B
└── foo
这将需要在restic的归档器部分中进行一些工作。 我认为我们根本不需要触摸恢复。
@ fd0我建议还包括一个用于备份的选项(--store-full-path),该选项显式地存储备份目标的完整“真实”路径。
原因是在tar情况下以及使用其他几种备份工具,您可以获得一些复杂的还原树。 虽然这是一个不错的默认设置,但如果我的还原类似于主机备份的原始文件系统的整个布局,我个人希望使用它。 (如果还原还可以在还原位置之前添加主机名,则更好)
@trbs我认为默认值需要存储完整路径,并为使用相对路径的特殊情况进行切换。 原因是rel路径会产生意外或不确定的行为,但abs不会。 如果您想请求前缀或某种其他形式的路径处理,我建议这是一个完全独立的问题。
我已经考虑过这一点,并且我认为我们需要更改备份行为,以便始终保存完整路径(如命令行中给出的)。 这就是tar
所做的,并且效果很好。 不幸的是,这是在开发Restic的早期就做出了错误的设计决定。
为--store-full-path
+1
讨厌+1,但我也很想解决这个错误。 有多个Restic待处理的安装,不幸的是,此错误是个热门。
感谢@ fd0为您所做的工作,我知道现在放松并不容易。
-1为--store-full-path
。 我宁愿看到完整路径始终在备份中,然后在恢复时不需要--strip-components <N>
来取走一部分。 这意味着完整的数据始终在备份中可用,如果用户在还原时从路径中剥离了太多组件,因此合并了子目录,它将成为可恢复的用户错误。
至于将主机名前缀到备份位置,这似乎可以从cmdline轻松完成,因为大多数人都知道他们要从哪个主机预先还原:)
考虑到您还不是1.0,我投赞成票,如果为了做出理想的修复而必须进行重大更改,请早点进行,而不是晚一点。
@mholt我同意,我已经在为此工作。 正如我所说,这是由早期的错误设计决定引起的,需要予以纠正。
嘿@ fd0-刚刚看到0.7已发布。 这是0.7.1上的地图(以及#910和#909)吗?
也许不是0.7.1,而是0.8.0左右。 我已经开始着手了。 可能有点背景:这是由存档程序代码引起的,该代码是restic中存在的最古老的代码。 不幸的是(当我刚开始学习Go / 2013/2014时)时,存档器代码非常复杂,并且我犯了很多新手错误(并发太多,渠道太多)。 我还担心原来根本不是问题的事情,而忽略了成为问题的事情(例如索引处理)。
因此,我已经开始完全重新实现存档程序代码,仅在有意义的情况下使用并发(即处理单个块),而不是从磁盘上并行读取20个文件。 该代码还包括适当的目录遍历,并将完整的路径插入到存储库中。
幸运的是,这实际上只是需要触摸的存档器,其余代码(由于restic和repo的设计)将继续正常工作。
此更改会影响现有存储库吗?
是的,“影响”“新备份的结构会稍有不同”,是的,仅此而已。 不需要migrate
或任何其他东西。
因此,#1209已被合并,它通过检测名称冲突并解决(通过重命名)来改善这种情况,但是此问题仍未完全解决。 我在做这个工作 :)
@ fd0当我们期望包含完整原始路径的快照时有任何想法吗? 我们目前正在使用restic自动化备份和还原。
自动执行还原时,保持源路径完整至关重要。
如果我有一台服务器备份了两个“数据”目录(这不是理论上的话,那么我们有许多服务器需要备份Confluence和JIRA“数据”目录)-恢复过程需要知道数据目录属于Confluence,而哪个数据目录属于JIRA。 像'data'和'data-1'这样的名称显然在这里没有删减。
我认为目前最好的解决方法是备份单独快照中的数据目录,并用“ JIRA”或“ Confluence”标记它们?
没有时间表,对不起。
我认为目前最好的解决方法是备份单独快照中的数据目录,并用“ JIRA”或“ Confluence”标记它们?
是的,但是根据#1225,您以后将无法轻松将它们合并到一个存储库中。
关于选项--store-full-path
: rsync
具有以下选项: -R
, --relative
。
也许为Restic使用相同的选项名称?
对于全系统备份,我在这里描述了一种解决方法: https :
这个错误让我有些担心,但是我无法通过提供的步骤在0.8.3中重现它。 这仍然是一个未解决的问题吗?
是的,不幸的是,这仍然是一个问题。
嗯,我无法以某种方式复制问题,所以不确定我在做什么。 我附上了测试脚本。
您可以这样复制它:
$ mkdir dir1/subdir
$ echo foo > dir1/subdir/foo
$ mkdir dir2/subdir
$ echo bar > dir2/subdir/bar
$ restic backup dir1/subdir dir2/subdir
password is correct
scan [/home/user/dir1/subdir /home/user/dir2/subdir]
scanned 2 directories, 2 files in 0:00
/home/user/dir2: name collision for "subdir", renaming to "subdir-1"
[...]
snapshot f6138d06 saved
对于两个子目录,restic使用子目录的基本名称作为存储库中的顶级目录,因此对于dir1/subdir
和dir2/subdir
都是subdir
,这就是原因碰撞。
列出最新快照将显示它:
$ restic ls latest
password is correct
snapshot f6138d06 of [/home/user/dir1/subdir /home/user/dir2/subdir] at 2018-03-21 20:38:33.58232292 +0100 CET):
/subdir
/subdir/foo
/subdir-1
/subdir-1/bar
在您的测试案例中, $TESTDIR/dir1
和$TESTDIR/dir2
基本名称不同( dir1
与dir2
),因此不会发生该错误。
从0.9版的发行说明中:
使用该版本的Restic进行的第一个备份可能会导致本地重新读取所有文件,因此将花费更长的时间。 之后的下一次备份将再次快速。
我只想给你一些统计数据:
第一次备份:
-------------------------------------------------------------
Start: Do 24. Mai 05:15:01 CEST 2018
437 snapshots
Files: 0 new, 0 changed, 40524 unmodified
Dirs: 0 new, 0 changed, 2 unmodified
Added: 0 B
processed 40524 files, 14.805 GiB in 1:38
snapshot f724ff21 saved
Files: 556 new, 0 changed, 0 unmodified
Dirs: 2 new, 0 changed, 0 unmodified
Added: 719 B
processed 556 files, 914.493 GiB in 2:15:29
snapshot 3c0e0f1b saved
Files: 11570 new, 0 changed, 0 unmodified
Dirs: 2 new, 0 changed, 0 unmodified
Added: 719 B
processed 11570 files, 66.044 GiB in 16:21
snapshot 312fd29c saved
Files: 2309 new, 0 changed, 0 unmodified
Dirs: 2 new, 0 changed, 0 unmodified
Added: 719 B
processed 2309 files, 163.332 GiB in 24:13
snapshot 2baab573 saved
Files: 312 new, 0 changed, 0 unmodified
Dirs: 2 new, 0 changed, 0 unmodified
Added: 719 B
processed 312 files, 1.503 TiB in 4:48:23
snapshot 02dfe40c saved
Files: 743172 new, 0 changed, 0 unmodified
Dirs: 2 new, 0 changed, 0 unmodified
Added: 84.927 MiB
processed 743172 files, 89.131 GiB in 2:48:59
snapshot dcee3e70 saved
Files: 441 new, 0 changed, 0 unmodified
Dirs: 2 new, 0 changed, 0 unmodified
Added: 719 B
processed 441 files, 727.575 GiB in 1:56:36
snapshot 676adc45 saved
End: Do 24. Mai 17:46:46 CEST 2018
Duration: 12h:31m:45s
-------------------------------------------------------------
第二个:
-------------------------------------------------------------
Start: Fr 25. Mai 05:15:01 CEST 2018
444 snapshots
Files: 0 new, 0 changed, 40524 unmodified
Dirs: 0 new, 0 changed, 2 unmodified
Added: 0 B
processed 40524 files, 14.805 GiB in 1:42
snapshot 9c7cf320 saved
Files: 0 new, 0 changed, 556 unmodified
Dirs: 0 new, 0 changed, 2 unmodified
Added: 0 B
processed 556 files, 914.493 GiB in 0:15
snapshot 533e2155 saved
Files: 0 new, 0 changed, 11570 unmodified
Dirs: 0 new, 0 changed, 2 unmodified
Added: 0 B
processed 11570 files, 66.044 GiB in 0:17
snapshot 1c1235c3 saved
Files: 0 new, 0 changed, 2309 unmodified
Dirs: 0 new, 0 changed, 2 unmodified
Added: 0 B
processed 2309 files, 163.332 GiB in 0:13
snapshot d5ef168d saved
Files: 0 new, 0 changed, 312 unmodified
Dirs: 0 new, 0 changed, 2 unmodified
Added: 0 B
processed 312 files, 1.503 TiB in 0:16
snapshot 76e94946 saved
Files: 292 new, 0 changed, 743172 unmodified
Dirs: 0 new, 2 changed, 0 unmodified
Added: 32.790 MiB
processed 743464 files, 89.163 GiB in 1:06
snapshot 12fa66e8 saved
Files: 0 new, 0 changed, 441 unmodified
Dirs: 0 new, 0 changed, 2 unmodified
Added: 0 B
processed 441 files, 727.575 GiB in 0:15
snapshot ab2d29bb saved
End: Fr 25. Mai 05:19:12 CEST 2018
Duration: 0h:4m:11s
-------------------------------------------------------------
所以更长,意味着更长:-)
继续努力! 👍
@ fd0 ,很棒的工作! 非常感谢! 您的备份工具已成为我所有异地备份的最爱(使用b2):-)
最有用的评论
也许不是0.7.1,而是0.8.0左右。 我已经开始着手了。 可能有点背景:这是由存档程序代码引起的,该代码是restic中存在的最古老的代码。 不幸的是(当我刚开始学习Go / 2013/2014时)时,存档器代码非常复杂,并且我犯了很多新手错误(并发太多,渠道太多)。 我还担心原来根本不是问题的事情,而忽略了成为问题的事情(例如索引处理)。
因此,我已经开始完全重新实现存档程序代码,仅在有意义的情况下使用并发(即处理单个块),而不是从磁盘上并行读取20个文件。 该代码还包括适当的目录遍历,并将完整的路径插入到存储库中。
幸运的是,这实际上只是需要触摸的存档器,其余代码(由于restic和repo的设计)将继续正常工作。