I would also like to point out you should *never* backup SQL databases via file method while running. You either have to shut down the SQL server and backup the files, or use another tool such as mysqldump/pg_dump/etc. to dump the live data.
You should know that tar will not get other important things such as partition table and boot sector. You could add a (dd if=/dev/sda of=/tmp/mybootsec.dd bs=512 count=1) and then add /tmp/mybootsec.dd to your tar. An even better way would be to use sfdisk and dump the partition table to a file. Then it can be restored on a different sized disk. Be aware that tar does not support ACL (Access Control Lists), so if you're using them, then you need to use fgetacl and dump a list. Or can use enhanced "star." I would also recommend you avoid grabbing the dynamic system directories such as /proc, /dev, /sys, and /dev/shm. A little known and seldom used feature of GNU/tar is incremental backup feature, (-g) that is very helpful. One final note about direct filesystem access. In Linux, not everything you see is the current state of the OS. For example, if service X opens a data file, and something deletes that file, it will be missing on the filesystem to all new processes. But the original service X can continue to use it and run as if it wasn't ever deleted as long as it doesn't close the file handle. This can cause consistency problems if the backup is on a running server. Safest method is to shut down the service, backup, then start again. But that may not be an option for you. You can use dd for entire disk backup as well. However, this doen't lock the disk from use on a running system. (dd if=/dev/sda of=/mnt/smbmount/serverbackup.dd) I'd highly recommend a gzipped pipe if you are sending over a network or on USB drive as throughput is an issue. (dd if=/dev/sda | gzip -9 > /mnt/smbmount/serverbackup.dd.gz) As a bonus, if you wipe your free space with zeros before this, then gzip will compress all free space out of the backup and save a lot of room. This may seem like a lot of information, but use what fits your needs. If you have SQL databases, go for the *dump commands. If you're just grabbing user data, then tar/rsync are good tools. If you want an easy system backups, try using a program such as BackupPC http://backuppc.sourceforge.net/ cheers sV On Mon, Oct 5, 2009 at 7:47 AM, Craig Falconer <[email protected]>wrote: > Bryce Stenberg wrote, On 02/10/09 16:53: > >> First question – is it right that ‘tar’ does not need to run using >> ‘sudo’, as in it can still access all the files? >> > > Wrong - tar is a running process that has the same file access as the user > it runs as. If you run it as root, you can read all files. > If it runs as a user, it can only read the files they'd have access to. If > you're starting it from cron, its likely you're running as root. > > Secondly, does it backup all open files as well? (in windows ntbackup use >> to choke on open files) >> > > Depends... a file that is opened read/write should be skipped, but a file > opened read-only will backup okay. > > And this brings me to the other type of backup >> > ... windows backups > > Firstly you need to decide what you require from the machine if it was > rogered. > > 1 User data > 2 email > 3 sql databases > 4 /etc > 5 /root > 6 /usr/local > 7 /opt > plus a list of installed packages, and anything else critical. > > OR you can do some kind of rsync backup to another machine with a large > drive and use that to restore. > > RAID1 is good, and disks are cheap enough these days. > > > > -- > Craig Falconer > >
