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@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/
