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

weird flow when restoring a removed directory #27

Open
alive opened this issue Jan 16, 2023 · 12 comments
Open

weird flow when restoring a removed directory #27

alive opened this issue Jan 16, 2023 · 12 comments

Comments

@alive
Copy link

alive commented Jan 16, 2023

When trying to restore a directory with a non-null files.end, it is pretty much a certainty that files.end < now. I don't understand why gb fails to restore instead of just restoring latest version?
This issue is compounded because as far as I can tell there's not a clear way to get the latest timestamp for a directory? I had to gb ls and grab a random one from a file, though this may just be me missing something.

To resolve, I think:

  • gb restore should not exclude files where files.end < now in the query
  • gb ls should also output information about directories (though this seems much more complicated)

What do you think?

@alive
Copy link
Author

alive commented Jan 16, 2023

To be clear, this is the error I'm talking about
panic: {path} did not exist in the database (as either a file or directory) as of that timestamp

@leijurv
Copy link
Owner

leijurv commented Jan 16, 2023

Wouldn't it be surprising if you restored a directory and it gave you every file that's ever been in that directory? How would that work if there were many revisions of the same file (with the same name)? I think it's correct to ask you for a timestamp and restore the directory as it was at that timestamp.

@leijurv
Copy link
Owner

leijurv commented Jan 16, 2023

Also I'm shocked that someone is using gb! LOL

How long have you been using it?? with how many files?

@5HT2
Copy link

5HT2 commented Jan 16, 2023

i also use gb

@leijurv
Copy link
Owner

leijurv commented Jan 16, 2023

really???????????????????????????

@leijurv
Copy link
Owner

leijurv commented Jan 16, 2023

why

@5HT2
Copy link

5HT2 commented Jan 16, 2023

i didn't like how anything else worked and decided "well if it's in Go and i don't like smth i can hack together my own features" and ended up being okay with how it works.

normally i'd just roll my own solution for shit but i don't have the time anymore to write my own backup solution and test it in real world senarios to be sure it's reliable so i trust yours works fine rofl

~150k files stored as of this morning :p

@alive
Copy link
Author

alive commented Jan 16, 2023

Wouldn't it be surprising if you restored a directory and it gave you every file that's ever been in that directory? How would that work if there were many revisions of the same file (with the same name)? I think it's correct to ask you for a timestamp and restore the directory as it was at that timestamp.

This is a good point, maybe it should restore all files with timestamp = max(timestamp over all files in directory)?
My main concern is that it is not so clear what timestamp I should be restoring to in the case where I want the latest files?

Also I'm shocked that someone is using gb! LOL

How long have you been using it?? with how many files?

For about 8 months, and with only about 10gb of files (I don't backup much media with gb)

@leijurv
Copy link
Owner

leijurv commented Jan 17, 2023

Wow, cool! What storage do you guys use? S3 (the actual S3 or a compatible API?) or gdrive?

This means gb has at least 5 users! Me, @babbaj @glen3b and you two! That's so exciting!

@leijurv
Copy link
Owner

leijurv commented Jan 17, 2023

My main concern is that it is not so clear what timestamp I should be restoring to in the case where I want the latest files?

This is a reasonable idea. I'd be okay with adding an option to restore to do the most recent version of every file, but it won't be the default.

@5HT2
Copy link

5HT2 commented Jan 17, 2023

Actual S3 in my case :3

@alive
Copy link
Author

alive commented Jan 19, 2023

wip here #28

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants