Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd_backup does not store node information for leading directories #889

Open
middelink opened this issue Mar 17, 2017 · 2 comments
Open
Labels
category: backup state: need implementing cause/request established, need work/solution type: bug

Comments

@middelink
Copy link
Member

Output of restic version

restic compiled manually
compiled with go1.8 on linux/amd64

Expected behavior

Include at least the information for directory given on the cmdline. Don't start in it. (follow rsyncs lead, rsync -avHAX rsync://xxxx / restores everything correctly for the entire tree, including /)
Change the snapshot title to "Directory/File" or something.

Actual behavior

Only the file seems to be backed up. However the snapshot "Directory" indicates that it comes with the full path.

I have some issues with it.

  • (minor) it is unexpected. The heading says "Directory" but it is "File" in this case. I would prob have expected /home/middelin/go/src/github.com/middelink/restic/src/cmds/restic or cmd_rebuild_tree.go or something. Although I realize that opens up another can of worms.

  • In case of actually using a directory, say /, the snapshots tree points to the contents of /, but does not contain /. This means if I want to restore the backup, I will not get the permissions, ownership etc of / restored. (which is important to me personally as I make full system image backups and let restic figure out the dedupping.)

Steps to reproduce the behavior

$ restic -r rest:http://qnap.ch.polyware.nl:8000 backup --tag test -x /home/middelin/go/src/github.com/middelink/restic/src/cmds/restic/cmd_rebuild_tree.go
scan [/home/middelin/go/src/github.com/middelink/restic/src/cmds/restic/cmd_rebuild_tree.go]
scanned 0 directories, 1 files in 0:00
[0:00] 100.00%  0B/s  2.313 KiB / 2.313 KiB  1 / 1 items  0 errors  ETA 0:00 
duration: 0:00, 0.01MiB/s
snapshot 304eb099 saved
$ restic -r rest:http://qnap.ch.polyware.nl:8000 snapshots --tag testID        Date                 Host                   Tags        Directory
----------------------------------------------------------------------
304eb099  2017-03-17 10:54:34  bigbox.ch.polyware.nl  test        /home/middelin/go/src/github.com/middelink/restic/src/cmds/restic/cmd_rebuild_tree.go
$ restic -r rest:http://qnap.ch.polyware.nl:8000 cat snapshot 304eb099
{
  "time": "2017-03-17T10:54:34.008284541+01:00",
  "tree": "da281dcd5827edd1fbe35a56c6f8082ba8c689bc82b8d407ae930f8faa74fd1f",
  "paths": [
    "/home/middelin/go/src/github.com/middelink/restic/src/cmds/restic/cmd_rebuild_tree.go"
  ],
  "hostname": "bigbox.ch.polyware.nl",
  "username": "middelin",
  "uid": 1000,
  "gid": 1000,
  "excludes": [
    "/tmp/*",
    "/var/log/*",
    "/var/tmp/*"
  ],
  "tags": [
    "test"
  ]
}
$ restic -r rest:http://qnap.ch.polyware.nl:8000 cat blob da281dcd5827edd1fbe35a56c6f8082ba8c689bc82b8d407ae930f8faa74fd1f
{"nodes":[{"name":"cmd_rebuild_tree.go","type":"file","mode":436,"mtime":"2017-03-17T10:28:24.783675427+01:00","atime":"2017-03-17T10:30:41.197184715+01:00","ctime":"2017-03-17T10:28:24.785675376+01:00","uid":1000,"gid":1000,"inode":1838378,"size":2369,"links":1,"extended_attributes":[{"name":"security.selinux","value":"dW5jb25maW5lZF91Om9iamVjdF9yOnVzZXJfaG9tZV90OnMwAA=="}],"content":["c9c3f7f623edce67053a3dc67d0874a21b15c172254889f6590c6a30ff71ed35"]}]}
@fd0
Copy link
Member

fd0 commented Mar 17, 2017

I agree, this is not good style. I'm currently reworking the archiver (in #842), and I'll change the code to do what tar does: have the complete path that is given on the command line. I'm going to close this as a duplicate of #549 (which is even more severe).

@fd0 fd0 closed this as completed Mar 17, 2017
@fd0 fd0 added the type: bug label Mar 17, 2017
@fd0
Copy link
Member

fd0 commented Mar 17, 2017

Hm, I re-read your report, and I think you have a (different) and very valid point about the permissions of the top-level directory. Reopened.

@fd0 fd0 reopened this Mar 17, 2017
@fd0 fd0 added the state: need implementing cause/request established, need work/solution label May 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
category: backup state: need implementing cause/request established, need work/solution type: bug
Projects
None yet
Development

No branches or pull requests

2 participants