Thanks for your response. I deleted backup 044, and it seems to have worked.

luks encryption works great. The problem I run into is that with an
encrypted partition, you can't span drives. So I have to set up one volume
group per drive. But other than that, it works great. I manage backups on
between 12 and 20 machines on my home network on a 2.5GHz P4 system. The
main problem with this machine is that it has two IDE drive slots. Any more,
the largest IDE drives I have been able to find are 500GB. So I have a 500
and a 250 in the machine.

Since I have to use separate volume groups, I'm wondering if/where I can
mount the 150GB partition in the backuppc heirarchy to get the most out of
it. That would give me almost 650GB instead of the 500 (well, 488G) that I
have now.

So I am currently searching down the backuppc/cpool tree to see where this
space may be useful. The thing I am not sure about is hard links. Is it
going to break things to copy the contents of one or more of the directories
into the spare 150GB? If so, is there a better way? Symlinking doesn't seem
like a very good idea, given the circumstances. Is there a better way?

Also, when I finally identify the mount point, would doing an rsync -avH
copy everything over correcetly?

Thanks again,
--b

On Sun, Apr 18, 2010 at 3:58 PM, Matthias Meyer <matthias.me...@gmx.li>wrote:

> B. Alexander wrote:
>
> > Hi all,
> >
> > I shot myself in the foot, and need to pick your brains about how to
> > recover. My backup machine has a 500GB drive using LVM for my backup
> > partition. I managed to fill it up. Currently, backups are not running
> > (which makes me nervous), and the backuppc partition on this machine is
> > at:
> >
> > /dev/mapper/vg01-backuppc
> >                      488367552 485798240   2569312 100% /media/backuppc
> >
> > I have a machine, my workstation (defiant), that I has a bunch of stuff
> on
> > it in /media/archive. The backup is about 250 GB before pooling and
> > compression. Well, I have been slowly migrating data from /media/archive
> > to another machine which now has a 1.5 TB drive. All well and good,
> except
> > that without thinking about backups, I nfs mounted the filesystem to
> which
> > I am migrating stuff from defiant. I mounted it under /media/archive, so
> > when the last full backup ran on defiant, it filled the filesystem on the
> > backup host.
> >
> > I got an email from the Backuppc Genie, and started clearing some old
> > backups. After (I assume) Backuppc_nightly ran, I am still at 100%. I
> > started digging in to see why the filesystem was still full. In the
> > /media/backuppc/pc/defiant directory, there were two large directories,
> >
> > # du -sh *
> > 219G    869
> > 210G    944
> >
> > However, BackupPC_delete only shows backup number
> 869:/media/backuppc/pc/defiant
> >
> > # BackupPC_delete -c defiant -l
> > BackupNumber 869 - full-Backup from 2010-01-23
> >
> > and the web interface shows the same. Only 869.
> >
> > Can I delete the 944 directory without adverse effects? If not, what is
> > the best way to free up this drive space?
>
> Try cat /media/backuppc/pc/defiant/backups
> If there is no backupp number 944 you can remove it.
> You have to remove /media/backuppc/pc/defiant/XferLOG.944
> or /media/backuppc/pc/defiant/XferLOG.944.z too.
>
> >
> > Also, I have another 120GB of free space in another volume group. Is
> there
> > a way to integrate that into the backup filesystem? With all the hard
> > links, I wasn't sure how best to allocate the space.
>
> I use LVM too and I am be able to add and remove size from my backup
> volume.
> The hardlinks are no problem.
>
> >
> > /dev/mapper/vg00-archive
> >                      156962116     32840 156929276   1% /media/archive
> >
> > Unfortunately, since I use LUKS encryption on the drives, spanning a VG
> > across two drives is contraindicated. (It decrypts the first drive, but
> > not the second, so the volume group can't open.) Can I still use the
> 150GB
> > on vg00-archive in /media/backuppc?
>
>  But I didn't use LUKS encryption. So I can't say if that will work with
> resized volumes.
>
> ! You should test it ;-) !
>
> br
> Matthias
> --
> Don't Panic
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> 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/
>
------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
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/

Reply via email to