Hi,
C. Ronoz wrote on 2011-06-30 12:54:44 +0200 [Re: [BackupPC-users] Yet another
filesystem thread]:
> [...]
> >> - How stable is XFS?
unless I missed something, I'd say XFS is perfectly stable - more stable than
reiserfs in any case. The only thing that makes me hesitate with that statement
is Les' remark "XFS should also be OK on 64-bit systems" - why only on 64 bit
systems? [Of course, for really large pools, a 64 bit system would be
preferable with XFS.]
> [Bowie Bailey asked on 2011-06-29 10:43:28 -0400:]
> >How much memory do you have on the backup server? What backup method
> >are you using?
> The server has 1GB memory, but a pretty powerful processor.
A powerful processor doesn't help even marginally with memory problems.
See http://en.wikipedia.org/wiki/Thrashing_(computer_science)
> I found out that BackupPC is ignoring my Excludes though, [...]
This is because your syntax is wrong.
> $Conf{BackupFilesOnly} = {};
> $Conf{BackupFilesExclude} = {'/proc', '/blaat', '/pub', '/tmp'};
While the comments in config.pl state
# This can be set to a string, an array of strings, or, in the case
# of multiple shares, a hash of strings or arrays.
that is actually incorrect. A hash of strings makes no sense. In fact, Perl
would turn your example into a hash with "/proc" and "/pub" as keys and
"/blaat" and "/tmp" as respective values - certainly not what you want.
Turn your config value into an array (use '[]' instead of '{}'), and you
should be fine. You'll notice that the examples correctly don't include a
hash of strings.
Better yet, use a full hash of arrays. That is easier to read and maintain,
because it's explicit on which shares you want which excludes to apply to:
$Conf {BackupFilesExclude} = { '/' => [ '/proc', '/blaat', '/pub', '/tmp' ] };
The leading '/' on your excludes is just fine, contrary to what has been said.
It anchors them to the "transfer root". Without the slashes, you would also be
excluding e.g. "/home/user/pub" and "/home/user/tmp", just as two examples of
things you might *not* want to exclude (well, you might even want to exclude
"/home/user/tmp", but really *any* file or directory named "tmp"? It's your
decision, you can do whatever you want, even things like "tmp/" (only
directories) or "/home/**/tmp/" (only directories somewhere under "/home") or
"/home/*/tmp/" (only directories immediately in some user's home directory).
See the rsync man page for details). Just note that if your share name is
*not* "/", you'll need to remove that part from the excludes (e.g. for a share
name "/var", to exclude /var/tmp you'll need to specify "/tmp" as the exclude,
not "/var/tmp", which would try to exclude /var/var/tmp).
> This could explain why the run takes longer, but it should still finish
> within an hour?
On the first run (or whenever something is added that does not yet exist in
the pool), compression might slow down things considerably, especially if your
exclude of /proc is not working. Just consider how long compressing a large
file (say 1 GB) takes in comparison to how long reading the file takes. The
host status page should tell you more about how much data your backups
contain and how much of that was already in the pool.
> >You can just delete the directory and remove the test host from your
> >hosts file.
> That will only remove the hardlinks, not the original files in the pool?
What you mean is correct, but you should note that there is nothing more
"original" about the hardlinks from the pool to the content than those from
the pc directory to the same content. They are all hardlinks and are
indistinguishable from each other. Every "normal" file on your Linux system is
a hardlink to some content in the file system, just for files with only a
single hardlink we don't usually think much about it (and for files with more
than one hardlink we don't usually *need* to think much about it - it "just
works" as intended).
> >The space should be released when BackuPC_Nightly runs. If you want to
> >start over quickly, I'd make a new filesystem on your archive partition
> >(assuming you did mount a separate partition there, which is always a
> >good idea...) and re-install the program.
I believe you don't even need to reinstall anything. BackupPC creates most of
the directories it needs, probably excluding $TopDir, which will exist in your
case, because it's the mount point, but which will need to have the correct
permissions (user=backuppc, group=backuppc perms=u=rwx,g=rx,o= - but check
your installation values before unmounting the existing FS). Reinstalling
BackupPC may or may not be the easier option, depending on your preferences.
> I ran backuppc nightly /usr/share/backuppc/bin/BackupPC_nightly 0 255
You shouldn't have. Hopefully, there were no BackupPC_link processes running
during that time. BackupPC_nightly *should* contain a comment something like
# *NEVER* RUN THIS BY HAND WHILE A BackupPC DAEMON IS RUNNING. IF YOU NEED AN
# IMMEDIATE NIGHTLY RUN, TELL THE BackupPC DAEMON TO LAUNCH ONE INSTEAD:
#
# BackupPC_serverMesg BackupPC_nightly run
#
# IT WILL DO SO AS SOON AS THIS IS POSSIBLE AND WILL REFRAIN FROM DOING ANY
# CONFLICTING WORK AS LONG AS BackupPC_nightly IS RUNNING.
# BY DISOBEYING THIS RECOMMENDATION, YOU STATE THAT YOU EITHER "KNOW WHAT YOU
# ARE DOING" OR THAT YOU ARE PREPARED TO SACRIFICE YOUR POOL INTEGRITY.
prominently at the top before the usage note.
> after removing all but 1 small host, but there are still lots of files left.
> root@backuppc:~# df
/var/lib/backuppc
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/sdb1 206422036 24155916 171780500 13% /var/lib/backuppc
That doesn't really say anything about the file *count* ('df -i' would give
a rough approximation). If you didn't exclude /proc, you might have a
considerable amount of unexpected data in there (/proc/kcore ...), which is
just about guaranteed not to be pooled between backups (if you have more than
one).
One other thing to check would be whether /var/lib/backuppc/trash is empty. It
should be, and anything in there can be safely removed if it isn't.
I wouldn't expect you to have many and/or large log files in
/var/lib/backuppc/log ...
Hope that helps.
Regards,
Holger
P.S.: You might also want to exclude /sys and /dev from backups - I'm quite
sure rsync is smart enough *not to* skip them unless you tell it to.
Concerning bare metal recovery, how do you plan to do that? Restoring
to the target host requires an installed and running system, restoring
to a naked new disk mounted <somewhere> requires a plan how to do that
with BackupPC, as well as some preparation (partitioning, file systems)
and some modifications afterwards (boot loader, /etc/fstab, ...).
BackupPC is not designed to handle all of that alone, though it will
obviously handle a large part of the task if that is how you want to
use it.
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
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/
|
