splitting off directories

Steve Searle steve at stevesearle.com
Wed Jun 20 14:36:27 UTC 2007


Around 02:10pm on Wednesday, June 20, 2007 (UK time), Michael Klinosky scrawled:

> Well, I know that /boot can't reside in an LVM (so it has to be split off).

I don't use LVM - I did when it first came out but never saw it as an
advantage to *me*.

> >I also have some custom partitions for storing digital camera pics and
> >distro images on.  Keeping these separate makes it much easier when
> >installing a new version - I don't reformat these partitions.
> 
> Wouldn't it be possible to have them in /home? /home doesn't get 
> reformatted if on its own partition - correct? (It's an option, I believe.)

I always select to customise the partitions when I install, which does
mean that they aren't formatted buy default (I reuse the existing
partitions unless the sizes form the previous installation aren't
working for that particular machine's use).

I know I am unusual in reformatting /home, but I don't find it a problem
to redo the config files by editing or restoring from backups (sad
person that I am I have all my installation processes documented).  I
prefer to do this as I am more comfortable with a "completely clean"
installation.

> >And I also just ignore my browser cache in my regular backup job - no
> >need for it to be on a different partition.
> 
> Sounds like you use a program for that task. I'm not experienced enough 
> yet to find one I'd like. What do you use?

I just use tar.  Each machine has a job something like this:


|  #!/bin/bash
|  
|  YEAR=`date +%Y`
|  MONTH=`date +%B`
|  DAY=`date +%d`
|  
|  
|  tar cf /backups/jenny/backup.jenny.daily.$YEAR.$MONTH.$DAY.tar.bz2 -j \
|  	--exclude=/home/steve/share \
|  	--exclude=/home/steve/.beagle \
|  	--exclude=/home/steve/.mozilla \
|  	/etc \
|  	/home/steve \
|  	/usr/local/etc
|  
|  find /backups/jenny -name backup.jenny.daily.*.tar.bz2 \
|  	-mtime +11 -type f -exec rm {} ";"
|  
|  if [ "$DAY" = 01 ]; then
|  	cp /backups/jenny/backup.jenny.daily.$YEAR.$MONTH.$DAY.tar.bz2 \
|  		/backups/jenny/backup.jenny.monthly.$YEAR.$MONTH.tar.bz2
|  	find /backups/jenny -name backup.jenny.monthly.*.tar.bz2 \
|  		-mtime +400 -type f -exec rm {} ";"
|  fi
|  
|  if [ "$MONTH" = 01 ]; then
|  	cp /backups/jenny/backup.jenny.daily.$YEAR.$MONTH.$DAY.tar.bz2 \
|  		/backups/jenny/backup.jenny.yearly.$YEAR.tar.bz2
|  fi
|  
|  exit 0

I have a very old machine running as a backup server.  The /backup
directory, where the backup file is created is a nfs partition exported 
to this machine.  Anything that I want backed up is listed in the tar
job, with appropriate exlusions for large directories that don't need
backing up, e.g .mozilla, or directories that are nfs mounts from
another machine (/home/steve/share) that are backed up elsewhere.  Note
the real tar job is longer than this, I removed quite a bit for
brevity's sake.

Cron runs this on each machine every day.  If it is the first day of the
month and/or year, the backup file is copied to a month or year version,
and only files from the last 11 days are kept.  Similarly the monthly
files are deleted when they are 400 days old.

Once a month, after the monthly version of the backup file is created, I
burn all the latest monthly files from each machine to CD - all tarred
together and gpg encrypted (I have another job to do this) and keep the
CD at my workplace (this is my home system I am talking about), until
the next montly one is created.

Somewhat paranoid and somewhat unwieldly, it works for me and has the
advantage that I understand exactly how it works (becasue I develeoped
it over time).o

Steve

-- 

A:  Because it messes up the order in which people normally read text.
Q:  Why is top-posting a bad thing?

 14:53:30 up 3 days, 12:26,  2 users,  load average: 0.00, 0.03, 0.01
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20070620/46d2de16/attachment-0001.sig>


More information about the fedora-list mailing list