-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jeffrey J. Kosowsky wrote:
> Adam Goryachev wrote at about 14:14:49 +1000 on Tuesday, September 1, 2009:
> > Jeffrey J. Kosowsky wrote:
> > > Jim Leonard wrote at about 20:20:59 -0500 on Monday, August 31, 2009:
> > > > Jeffrey J. Kosowsky wrote:
> > > > > Is it self-evident that a BackupPC tree is difficult to
> > > > > copy/move/resize if not on a dedicated filesystem?
> > > >
> > > > What is a "dedicated filesystem"? How does it differ from any
other
> > > > filesystem?
> > >
> > > I mean a filesystem used just for a BackupPC topdir vs. a filesystem
> > > that may contain data and/or code for multiple applications. Based
> > > upon the nearly weekly postings on this group, it seems that many
> > > people (myself included) initially set up their BackupPC topdir on a
> > > filesystem containing mixed data and without the advantage of things
> > > like LVM or ZFS since they don't realize in advance how hard it is to
> > > copy/move/resize the topdir area due to the large number of
> > > hard-links. It seems to me that new users should be strongly advised
> > > to create topdir on a separate ("dedicated") filesystem on top of LVM,
> > > ZFS, RAID, etc. to maximize flexibility. Alternatively, we can
> > > continue to address this same issue every week ;)
> >
> > BTW, my "simple" solution to this apparently "major" problem was as
follows:
> > 1) Start using backuppc with a single FS (/) formatted with reiserfs (my
> > preference).
>
> As I mentioned this is not (well) documented in the BackupPC
> documentation and continues to trip up new and not-so-new users
> alike. Also, there are use cases where you can't have a single FS for
> BackupPC (though Michael Stowe has decided to call them "fringe")
As I mentioned, I didn't have a single FS for backuppc, I only had a
single FS for the whole system (ie, /)
> > 2) Backuppc grows too big for the FS, and I want to add RAID1 backup of
> > the system
>
> > 3) Purchase and install 2 x 1TB HDD's and configure with a single
> > partition and use MD for RAID1
>
> May be nothing for an enterprise but could be an issue for SOHO use. I
> for instance don't have two empty 1TB drives and enclosures hanging
> around.
The requirement for 2 x 1TB drives depends on the user, it could have
been an upgrade to 2 x 500G or 2 x 80G drives. In fact, if I still
didn't want RAID for backuppc then I could have simply used a single
drive....
> > 4) Boot from CD/USB live linux system, and use dd to copy the old
> > /dev/sda to /dev/md0
> > 5) Adjust the /etc/fstab on the root FS to mount /dev/md0 onto
> > /var/lib/backuppc
> > 6) mount /dev/md0 somewhere
> > 7) mv var/lib/backuppc backuppc
> > 8) rm -rf all directories other than backuppc
> > 9) mv backuppc/* .
> > 10) rmdir backuppc
> > 11) umount md0
> > 12) adjust the partition size
> > 13) adjust the filesystem size
> > 14) reboot and enjoy the newly expanded pool size
> >
> > I really don't see why people think this is so difficult... Sure, there
> > are lots of hardlinks, but block level copies are... simple. Sure, the
> > new drive is bigger, but increasing partition sizes and filesystem sizes
> > is simple. No "dangerous" operations, nothing technically hard or
> > difficult... just simple standard unix tools to solve a problem by
> > breaking it down into simple steps.
>
> Some of those operations can be dangerous. I have made mistakes when
> manipulating raid and filesystem sizes. But maybe I'm just sloppier
> than most ;)
Well, nobody can stop you from shooting yourself in the foot. You can
do equally silly things with standard file utilities as you can with
any of the above tools.
> >
> > I don't use LVM, in fact I don't really know how to use it. It might
> > have made my life simpler if I had used it, but since I understand MD
> > much more than I understand LVM, I find it more reliable for me.
>
> The point is that playing around with mdadm, lvresize,
> resize2fs/resize_rieserfs etc. are not everyday operations for me
> and hence open to error - especially since the consequences of errors
> can wipe out a whole fs or even disk. I don't think there is anything
> wrong with expecting a program that is file-based to be copyable using
> standard file-based tools. Sure you can make a setup that avoids the
Why? Just because you think there is nothing wrong with it, doesn't
mean it is the best way to do it. My mailserver would be best migrated
with block based tools rather than file tools, because there are just
so many small files.
> problem by using dedicated filesystems and block-copying but that
> doesn't seem ideal or natural. Again, nobody said there weren't any
> solutions -- people just continue on a weekly basis to be dissatisfied
> with them....
Actually, some people just refuse to use the perfectly good solutions,
and instead want to continue blathering about how things should be
different. I think we have had 3 months worth of emails in the past day.
:(
Regards,
Adam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkqc6bMACgkQGyoxogrTyiVD8QCgxzBmBC+s7MZSHTPSz0gSNGC/
VpUAn11aaPJ8l6kLt1+ssrQzRdc36X2E
=xeNn
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
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/
|
