Re: [BackupPC-users] How to deactive the file mangling on backups ?

[Serge S. <ser...@gm...>]

The point is that it barely miss nothing to have a browsable uncompressed
rsynced backup folder for people willing to retrieve files from that
directly.
It's the default rsync behavior.
I'm pretty sure every point you are presenting could be dealt in another
way.
Attrib files could have a really proprietary name to avoid collisions
(".backuppc_internal_attrib-backup-UUID").
Attrib files could be stored in another meta directory somewhere else under
pc/localhost/ (and, regarding the volume saved on a backup, i really doubt
that a few more I/O would have a significant impact).
...

As said previously, that would allow these two nice features :
- allowing to plug an external drive with a backuppc uncompressed rsync-ed
backup folder on another computer if the main server crash (allowing a
quick recovery of some files - of course, one can "unmangle" the directory,
but really, it's an unnecessary manipulation, especially if it can be
easily avoided from the start)
- allowing to pusblish (sshfs, nfs, smb, ...) a read only share of this
uncompressed rsync-ed backup folder.

I really like a lot of features in backuppc, the internal rsync storage
behavior is the only one i strongly disagree with, mainly because i really
thing it can be easily be just a simple and regular rsync backup path.

Thanks anyway for your previous answer.

Regards.

-- 
Serge.


On Mon, Sep 24, 2012 at 8:35 PM, <bac...@ko...> wrote:

> Serge SIMON wrote at about 19:01:54 +0200 on Monday, September 24, 2012:
>  > Hello,
>  >
>  > BackupPC seems a great tool.
>  >
>  > The only - main - drawback for me is the file name mangling on (mainly
>  > rsync) backups (backuppc adds an "f" to every folder of file backuped).
>  >
>  > I've read the few information about that (that it wasn't activated on
> old
>  > versions, and why it has been), but i really think it's a bad design
>  > choice. "attrib" files could have been stored elsewhere for example,
> and so
>  > on.
>  >
>  > The problem is that the rsynced folder is not directly usable once
>  > backuped, one can only restore from the (great) backuppc front-end,
> whereas
>  > there are several use cases where this is not possible or pertinent
> (server
>  > crash > remount external backup drive elsewhere and willing to
> immediately
>  > access backuped files, or just willing to share as read only the backup
>  > folder on the network).
>  >
>
> One is not supposed to use rsync directly to restore from the pc tree
> for mulitple reasons, including the fact that if you use a compressed
> pool, the files will be compressed. Also, you lose all the key
> metadata like timestamps, ownership, permissions. Similarly, special
> files, hard/soft links, etc. won't be treated properly. Finally, the
> prefix-f is not the only potential change. Various non-alphanumeric
> characters are also substituted by their hex representations which
> would also mess up rsync. Moreover, there is good reason to keep the
> attrib file in the same tree (it saves on directory reads), hence the
> need for f-mangling.
>
> Basically, the only use case for restoring any file directly from the
> pc tree is if you are an expert user well-aware of the above
> limitations, in which case undoing the extra 'f' should not be a
> problem.
>
>  > So : how could i deactivate this file mangling thing ? (at first glance
> in
>  > the code, it seems to be hard coded !).
>
> It's hard coded. There is no reason to disable it. It would mess
> things up.
>
>  > If it is not possible to deactivate this behavior, could it be either
>  > removed, either made configurable in a next version ?
>
> No --  It's a terrible idea that shows a complete lack of
> understanding of how backuppc works and the whole purpose of the pc tree.
> Feel free to rewrite the code to function otherwise but I can't think
> of any reason why the code should be officially changed and I can
> think of lots of reasons not to.
>
>  >
>  > Thanks in advance for any answer / clue about this.
>  >
>  > Regards.
>  >
>  > --
>  > Serge.
>  >
> ------------------------------------------------------------------------------
>  > Live Security Virtual Conference
>  > Exclusive live event will cover all the ways today's security and
>  > threat landscape has changed and how IT managers can respond.
> Discussions
>  > will include endpoint security, mobile security and the latest in
> malware
>  > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>  > _______________________________________________
>  > BackupPC-users mailing list
>  > Bac...@li...
>  > List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
>  > Wiki:    http://backuppc.wiki.sourceforge.net
>  > Project: http://backuppc.sourceforge.net/
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> BackupPC-users mailing list
> Bac...@li...
> List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
> Wiki:    http://backuppc.wiki.sourceforge.net
> Project: http://backuppc.sourceforge.net/
>