search

bit-team / backintime

Back In Time - An easy-to-use backup tool for GNU Linux using rsync in the back
https://backintime.readthedocs.io
GNU General Public License v2.0
2.02k stars 200 forks source link

WISH: Option to follow symlinks #222

Closed Germar closed 8 years ago

Germar commented 8 years ago

Hi,

in my home directory I have some symbolic links to directories. When I tried to restore a file stored within such a symbolically linked folder from a snapshot of my ~, I realised that the snapshot contained copies of those links (and not the referenced directories), thus pointing to the current version of the linked dirs only. Though perhaps appropriate under certain circumstances, this turned out to be fatal in my case since there was no actual backup of the file I wanted to acces an earlier version of.

So perhaps some option to tell BackInTime whether or not to follow symbolic links (perhaps separately for directories and regular files, perhaps optionally on a dir-to-dir basis?) would be a good idea?

Regards --

tcrass

Imported from Launchpad using lp2gh.

Germar commented 8 years ago

(by danleweb) BIT backup symbolic links as symbolic links. If BIT follow symbolic links when you restore it it will remove the symbolic link and replace it with a file/folder. This can be dangerous. It is better/safer to include target into include items.

Regrads, Dan

Germar commented 8 years ago

(by torsten-crass) Hi Dan,

BIT backup symbolic links as symbolic links. If BIT follow symbolic links when you restore it it will remove the symbolic link and replace it with a file/folder. This can be dangerous. It is better/safer to include target into include items.

that's what I did now after realizing what had happended with my so-called backups. Yet I find this behaviour rather unintuitive since I'm using symbolic links to exactly prevent me from having to always think about which partition on which drive the data are actually stored on. More generally spoken, if I request a backup of my home directory, I expect the actual data to be backup'd, not so much the symbolic link structure I have set up to suit my day-to-day requirements.

So what do you think -- would an option be an option? ;-)

Regards (and thanks for developing BackInTime) --

Torsten

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ le alte Computer sowie Zubehör +++ Amiga +++ Apple II +++ At ari +++ Commodore PET/VC20/C64/C128/C16/Plus4 etc. +++ Sincl air +++ TI99/4 +++ alles, was nicht PC oder Mac ist +++ Samm ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Dr. rer. nat. Torsten Crass Biochemiker und Bioinformatiker

Web-Design / IT-Service http://www.tcits.de

Breite Lade 20 31275 Lehrte Tel. 05132/8219177 http://www.tcrass.de

Germar commented 8 years ago

(by danleweb) I'm not against it (and it is easy to implement) but I find it really dangerous. Example:

A library liba.so.1.0.0 usualy have symbolic links: liba.so.1.0, liba.so.1 and liba.so If you follow symbolic links you will have 4 files in the snapshot and when you restore liba.so, the symbolic link will be replaced with the real file.

What about recursive symbolic links (like a link to root) !!!

I think following links has more disavantages than avantages. Including the real folders it is the right solution without danger.

Germar commented 8 years ago

(by torsten-crass) Dan,

I'm not against it (and it is easy to implement) but I find it really dangerous. Example:

A library liba.so.1.0.0 usualy have symbolic links: liba.so.1.0, liba.so.1 and liba.so If you follow symbolic links you will have 4 files in the snapshot and when you restore liba.so, the symbolic link will be replaced with the real file.

I get your point! However, in my case, the opposite behaviour (i.e. not following symlinks) turned out to lead to catastrophy since only the links got backup'd, not the actual data.

What about recursive symbolic links (like a link to root) !!!

The backup process could decide not to follow a link when encountering it for the second time, but to back it up as-is, i.e. as link.

I think following links has more disavantages than avantages. Including the real folders it is the right solution without danger.

So what about implementing the feature, but set your preferred behaviour as default?

Anyway, I won't bug you any more about this.

Thanks for taking the time to discuss this issue.

Regards --

tcrass
Germar commented 8 years ago

(by danleweb) OK, I added 2 options in expert tab:

Germar commented 8 years ago

(by torsten-crass) Wow!

OK, I added 2 options in expert tab: - copy unsafe links : dereference only unsafe (targets are not in the snapshot) symlinks. This seems to work only for absolute symlinks. - copy links : dereference all symlinks.

That was quick!

Thanks a lot, looking forward to see the changes appear in Debian's repositories!

Best regards --

trcrass