When i include the / directory it also tar's the /lib /sys /proc /dev filesystems too (and more but these seem to be problem directories.)
Although i have never tried to restore the /sys /proc and /dev directories I have not seen anyone mention that your cant restore /lib but when i tried the server crashed and would not even start the kernel (not even in single user mode).
Can anyone let me know why this happened and provide a more comprehensive list of directories than the 4 mentioned as to what should and shouldn't be backed up and restored? Or point me to a useful site that might explain why you should or shouldn't backup each one?
There's no point in backing-up things like /proc because that's the dynamic handling of processes and memory working sets (virtual memory).
However, directories like /lib, although problematic to restore on a running system, you would definitely need them in a disaster recovery situation. You would restore /lib to hard disk in single user or cd boot mode.
So you need to backup all non-process, non-memory files for the backup to be sufficient to recover. It doesn't mean, however, that you should attempt to restore them on a running (multi-user) system.
Yes sorry i excluded the /proc /sys and /dev filesystems.
I will attempt to do a restore in single user mode next time then. I did think the /lib, /lib64 ..etc directories were required but after multiple attempts and the server dying each time i was wondering if i was missing something.
Cheers for your help guys, I had read those links you attached but none of them mentioned single user or cd-boot mode being required.
If we take an example of one of our Linux servers, it is running on an HP BL460c G7 blade, in a DR situation we would e restoring this onto a DL380 server.
Although never fully tested with Linux the idea was that we would have the DL380 server setup with the same version of Linux OEL5.5 and all the filesystems and partitions already setup with the same sizes.
So from the information above take the tarball and in single user mode unpack it. In this instance would we need the /dev directory?
Unfortunately this is something i have only had 5 working days to trial before and because of doing other work and the legth of time it took couldn't get it working, and now i have no spare hardware to test on but we are doing a DR trial soon and it is going to be important to get working. The more info i get the quicker i can hopefully overcome any issues i run into on the trial.
The /dev directory holds the device nodes for the hardware. It is the connection between the O/S and the actual hardware (eg, /dev/sda being a disk drive).
When you restore a backup to different hardware, these devices will be wrong for that hardware and will need to be rebuilt/reset to suit. I'm not a RedHat expert so I don't know exactly how that would be achieved. Perhaps RedHat experts on this forum can tell us how to restore to different hardware.
Anyway, the point is you need to backup all hard disk directories and ignore the directories which are really pseudo memory (eg, /proc). You need to distinguish between the two.
Work on the principle that it is better to have a backup containing stuff that is unnecessary and/or needs modification to suit new hardware rather than not have a copy of it at all.
Regarding DR procedure, perhaps you should focus on the service at hand not on OS based restore ?
Since you have a two identical machines on two locations, you can just have a kickstart file with additional configuration (additional packages, users, kernel limits etc.)
Then you can basically get the DR OS setup layer in several minutes via automated install.
Since you have OEL, i will presume that the service on that machine would be oracle database.
So using tools on your disposal (Storage based cloning, tape restore, oracle utilities via network rman, exp etc.) you can easily clone or restore just the service, in this case database on the DR site.
Hicks, looks like we might be OK on the /dev restore as looking around it seems it can be rebuilt using udev rather than needing to be restored.
Peasant, the rest of the process is OK, it is only the OS restore I am worried about (because its really the only bit I am responsible for). The rest is using tried and tested methods (albeit on a different OS).
Kickstart is one option i was thinking of, but then i would have to manually install Netbackup and run a netbackup restore to ensure that all the changes that have been made since the original kickstart was done get implemented. I was looking at having both options available, as it is quicker to untar a tarball on an already built OS than it is to build using kickstart and netbackup I would have only reverted to kickstart solution in the case of the OS going wrong for the reasons above.