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

[Feature Request] A "full checkout" / "full backup" option #111

Closed
wallace11 opened this issue Feb 8, 2022 · 4 comments
Closed

[Feature Request] A "full checkout" / "full backup" option #111

wallace11 opened this issue Feb 8, 2022 · 4 comments

Comments

@wallace11
Copy link

wallace11 commented Feb 8, 2022

Hi,
I've had this idea to use dsc in order to make a full backup of the documents in an organized structure that'll represent the structure in Docspell as closely as possible.

What I had in mind is something like the following structure:

documents
└── document_title
    ├── file-a.pdf
    └── file-b.pdf

This could then be extended to include other "metadata" represented in a file directory structure using symlinks.
For example, by-date:

by-date
└── 1970-01-01
          └── document_title -> ../../documents/document_title
              ├── file-a.pdf
              └── file-b.pdf

or by-tag: (note how it appears multiple times to represent multiple tags)

by-tag
└── #important-stuff
          └── document_title -> ../../documents/document_title
              ├── file-a.pdf
              └── file-b.pdf
└── #invoices
          └── document_title -> ../../documents/document_title
              ├── file-a.pdf
              └── file-b.pdf

The main goal for me at least is to have another backup copy independent of Docspell that I can have alongside Docspell backups for any catastrophe situation. Somewhat gloomy but if I'm gone or unable to maintain the Docspell instance anymore, my family would still have access to all the documents through those backups.

What do you think?

@eikek
Copy link
Member

eikek commented Feb 8, 2022

Hi! I like that, just wondering if that is not already there with the export command? It seems very close at least. But maybe I missed some detail.

@wallace11
Copy link
Author

I actually have missed that option 😅
So I was trying to use export --all and ran into an issue (#112) 😅 😅

In any case, it got some files in place and I see that the file hierarchy is a bit challenging to understand because it uses indexed hashes which are less of the human friendly type. I do like the metadata.json file, though.

This brings to the table the question whether a change of the hierarchy or an additional option (--pretty-hierarchy 😂) is even something you're interested to add.
If you see a value in such thing I can either change the title of this issue or open another one for a discussion on that :)

@eikek
Copy link
Member

eikek commented Feb 9, 2022

Good :) and thanks for the report!

There is an option --link-naming which allows to use the name as the link target instead of the id - not sure if you noticed. You can also use --folder-link and --folder-delimiter to create a hierarchy that mirrors the folder of an item. The link source (the items folder) stays the same, though. Would this create a close enough "pretty" hierarchy? :) If not, what kind of hierarchy do you think of?

@eikek
Copy link
Member

eikek commented Sep 10, 2022

I think the issue #114 would then solve this by allowing to create custom hierarchies. So I'm closing this one.

@eikek eikek closed this as completed Sep 10, 2022
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

2 participants