Jump to content

Recommended Posts

Hi Kids,

 

Simple question for you lot but not so much for a newbie like me...

 

What does the following actually state:

Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2             7.6G  1.8G  5.5G  25% /
/dev/sda1             190M   25M  156M  14% /boot
tmpfs                1014M     0 1014M   0% /dev/shm
/dev/sda5             7.6G  387M  6.9G   6% /opt
/dev/sda7              46G  4.0G   40G  10% /u01
/dev/sda6             3.8G  1.4G  2.3G  38% /var

 

What location is my databases stored on? What location is my webdocs stored on? Oh I know that one, its /var/www/vhosts/...

 

But where is safe to put nightly database backups so it doesnt fill up the partition where web file are stored? (I've done that before and the website went down all weekend!)

 

Any help and advice would be appreciated.

 

Many thanks

Link to comment
https://forums.phpfreaks.com/topic/150903-filesystem-space-and-locations/
Share on other sites

/var is the location for variable data and is generally where databases and the like are stored.

 

However, given that / has 5.5G free and you don't have a seperate partition for /home, I'd make a backup directory within your /home/<user> directory and save them there.

I have no idea what /u01 is! Its a dedicated server set up by a hosting company and we are just collating our websites onto one server (I'm no systems administrator though!)

 

So really, I could put our (very large) database backups in a directory on /home? This is different from the web content?

 

Any idea how I can find out what /u01 is? or how I get to it?

 

Thanks again

I should really post another topic but if you have any insight to the next question that would be great.

 

Is there a .sh script to back up each table individually into a directory then .zip/.tar it up. Then if I need a specific table I can look in the .tar rather than the whole 300Mb+ file?

 

Many thanks

You plan on losing one table?  That's not likely to happen.

 

Hrmmm, a quick google came up with this:

 

 

http://ocaoimh.ie/2005/06/28/simple-mysql-backup/

 

 

Surely something more elegant is out there though.

 

 

You could always use something besides just a shell script by the way.  Like PHP or Perl or something.

Backing up your web root is pretty simple (not tested).

 

webroot=/path/to/webroot
backdir=/path/to/backupdir

stamp=`date +%u`

[ ! -d ${stamp} ] || mkdir -p ${backup}

if [ -d ${webroot} ] ; then
  tar -cjf ${backupdir}/${stamp}.tar.bz2 ${webroot}/
fi

 

You really should be looking into incremental backups or something however to save yourself some space.

Hi there, thanks for all the replies. As I said I'm bit of a newbie - only know a few things on RedHat to get me through it.

 

The idea is to backup the database and then backup the web content into a directory and renamed to the date for example: 2009_03_25.sql and 2009_03_25.tar on a nightly or weekly basis.

 

I was then looking for a script to run to delete some of the older files, thinking of trying to keep the last 14 days worth everytime the "clean up" script runs?

 

I will give your code a go and see what happens, the last time I managed to .tar up every individual file on the server!

 

Any ideas on the code .sh to run which will delete files less than 10 days old?

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.