Originally posted by lyx0m
The way to backuop anytthing keeping the permisions woulld be:
tar cvpf /dev/st0 <whate_ever_path>, now, if you plan to backup on a daily basis y would suggest to put via cron:
00 23 * * * tar cvpf /dev/st0 /etc/httpd /var/www
this will allow you to backup automatically at 11pm everyday.
If you want to backup an entire system, I wond use another disk ass mirror and would type
dd if=<disk_device> bs=1024 of=<your_mirror_disk_device>
or you can send it to tape:
tar cvpf /dev/st0 / /etc /usr /var /tmp /opt /sbin (it depends how did you create your partitions and how big they are)
I see that you use tar cvpf
Is it the p attribute that preserves the permissions?
This is an excerpt from the tar man page
p Restore the named files to their original modes, and ACLs if applicable, ignoring the present umask(1) . This is the default behavior if invoked as super-user with the x function letter specified. If super-user, SETUID and sticky information are also extracted, and files are restored with their original owners and permissions, rather than owned by root. When this function modifier is used with the c function, ACLs are created in the tarfile along with other information. Errors will occur when a tarfile with ACLs is extracted by previous versions of tar .
Also, I am testing a backup script that I've written and I've included some exclude attributes in the tar.
tar -czvfp /hd1.tar * --exclude-from backup-x
In the same directory that my backup script is located, I placed another file called backup-x which contains a list of files and directories that should be excluded from the backup process. I placed all of my large application installation files into a folder called apps and excluded the contents because I do not want to back up those large files every night when they do not change from day to day.
I also found that my script ran into a file called libnss_ldap-2.3.1.so that stopped the script and had an overrun loop that required me to hard reboot my server. That was before I used the 'p' attribute so it might have been a permissions issue (not allowing tar to copy the ldap file and edit permissions for security reasons probably).
I excluded the libnss_ldap-2.3.1.so file in the backup-x file. Do you think that will be a fatal mistake if and when have to do a restore?
Other exclusions included the name of the .tar files resulting from the backup, otherwise you end up backing up your backups, which is a major waste of space and might result in a never-ending loop.
One other thing...I forgot to use the standard suffix for my tar file which should have been .tgz since I was tarring and gzipping within one command. For a quick summary on tar and gzip see Redhat.com compression
What is st0 that you use in your example?
I see it in the /dev/ where there are 128 st# items stored. If I try to open it in pick or vi, it says it is not a file. Is this kernel base or something?