BackupPC-users

Re: [BackupPC-users] Copying in a file instead of backing up

2009-01-14 21:32:13
Subject: Re: [BackupPC-users] Copying in a file instead of backing up
From: Adam Goryachev <mailinglists AT websitemanagers.com DOT au>
To: backuppc-users <backuppc-users AT lists.sourceforge DOT net>
Date: Thu, 15 Jan 2009 13:22:26 +1100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

In advance, sorry for messing up the threading, I don't have an actual
email from the thread to "reply" to...

In any case though, I would like to extend this discussion in two
different directions:
1) The ability of an admin to manually "insert" a file into the pool and
a host's backup. I imagine it should be fairly simple to do this. ie,
BackupPC_addfile2pool -c 3 abc.doc
where -c means add it to the cpool, 3 means the level of compression to
use, and abc.doc is the file to add.

Then, add a hardlink from the pc/machine/234/etc/fabc.doc to the new
cpool file.

Then, finally, add the attrib file entry as needed.

Really should not be difficult, but if someone could assist in providing
a solution for the above 3 steps, it would be greatly appreciated.

2) The ability for backuppc to know that file abc.doc on host1 is
identical to file abc.doc on host3 and file def.doc on host 2....

During the backuppc_link stage, we could add entries to the berkeley DB
if the uncompressed file is larger than "CacheMinSize".

During the backuppc_nightly as we delete a file from the pool, we also
remove the entry from the DB file (if it exists). At the end of the
nightly run, maybe we need to "compress" the DB file if that is an issue
for Berkeley DB files (ie, in case it becomes too fragmented/etc...

The other option would be to change the hashing system used by backuppc
to store files into the pool to match the checksum's used by rsync. Yes,
this would be an incompatible change, and a lot of work for people with
a large pool, but overall, should not in itself be so difficult. What is
perhaps more important is whether the result is any better/worse than
what we have, especially in the case where the user is only using tar
for backups.... If it is no worse, or is better, then perhaps it is
worth looking at it.

In the end, what problem are we solving?
A) Backing up identical files from multiple remote hosts
B) Backing up identical files when renamed/moved

(A) shouldn't really be a huge problem, although these days files being
emailed from person to person can encourage this, but I can't imagine it
really is a massive issue.

(B) This has and will be an issue for me at least on a few occasions. In
one case, I had to write a script to rename the backup files (dumped
from another program) to ensure they would have the same filename each
day. I'll probably need to do that again in the near future for another
remote server. If we could solve this, it would be useful.
In another case, we have around 30G of image files, which will be
renamed/etc in the near future so that they sit on a different server,
and the directory structure will also change. Again, the above would
solve this issue, but this is a once off thing, and not really a problem
since each file is small....

Finally, would the original problem be solved by being able to keep a
partial file in a partial backup? This would allow rsync to continue,
and also allow you to have some of your old file instead of none of
it... I understand it may increase your pool/disk use but as soon as the
backup changes from partial to full/incr, then the old portion of the
file would be removed from the backup.

Anyway, gotta get back to work now, just thought I might add my
thoughts/2c worth :)

Regards,
Adam

- --
Adam Goryachev
Website Managers
www.websitemanagers.com.au
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkluneIACgkQGyoxogrTyiWM7wCfd6YP18FF7XngwUZIlBjBihHp
GdUAn1DBYzRUtvDXyFrvT4FQkdo+oNWm
=Ioya
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

<Prev in Thread] Current Thread [Next in Thread>