RE: [U2] Files reporting as changing during backup...
I will need to look more into the SUSPEND.FILES . -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of John Jenkins Sent: Wednesday, August 09, 2006 5:40 PM To: u2-users@listserver.u2ug.org Subject: RE: [U2] Files reporting as changing during backup... SUSPEND.FILES ON - this is a minimum. What you are seeing is fairly predictable if the database is not quiescent. Best Bets: 1. SUSPEND.FILES ON Then one of: a. a SAN snap while suspended After just yesterday having one of our mirrored drives fail (although it wasn't an actual drive failure, but the RAID controller was screaming none the less. (we are atrributing this to a power fluctuation problem on the motherboard - just one more reason we need to replace our equipment ASAP). I'm not so keen on breaking any mirrors just at this time, because I KNOW, one of those drive will fail, while the mirror is broken. b. split a mirror while suspended - backup the mirror offline - and re-sync c. tar backup to a disk file [ fastest online method ] Is there a way to transfer a tarballed file on disk to tape, so that it can be untarred from tape as if it were originally backed up to tape? Then SUSPEND.FILES OFF I suppose, we could put restrictions during the 45 min it takes to tar up no one could work. Optionally you could uvbackup to a disk file and then tar backup the uvbackup separately (possibly after a compress). However while this will give you file integrity it will also take longer to run (it respects locks) and will not maintain referential integrity if the database is still being updated. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Files reporting as changing during backup...
SUSPEND.FILES ON - this is a minimum. What you are seeing is fairly predictable if the database is not quiescent. Best Bets: 1. SUSPEND.FILES ON Then one of: a. a SAN snap while suspended b. split a mirror while suspended - backup the mirror offline - and re-sync c. tar backup to a disk file [ fastest online method ] Then SUSPEND.FILES OFF Optionally you could uvbackup to a disk file and then tar backup the uvbackup separately (possibly after a compress). However while this will give you file integrity it will also take longer to run (it respects locks) and will not maintain referential integrity if the database is still being updated. If the database is not quiescent the database you will lose referential integrity at best - at worst some files may be corrupted when you restore them. Always remember the reason you take a backup is to secure and protect the business interest in the data. The possibility of a bad backup only serves to give a false sense of security. Even if you can recover the damaged files it is not guaranteed and it is still down time and affects the business. Remember to test the recovery procedures full-bore from time to time - if you haven't tested recovery from your backup strategy [without notice !!] you will never know if it works. You will know it works after the system has been reasonably exercised and applications have successfully used and reconciled recently updated files and data after recovery - not just after the data has been restored. (Oh the stories) A blast from the past: salutary tale - sorry I just *had* to put this one down - 1. When taking a full backup each weekend and an incremental backup every night please change the tape - yes - I mean at all - not just every now and then. 2. If you get a catastrophic disk failure keep your backup tape (Note: the only one - see changing tapes above) until the disk is replaced, formatted and restored. You know - the one that (once) had all (or at least some) of the data on it. The one you still overwrite in the daily tape cycle every night. The daily tape cycle that (now) has no data on it. 3. Please feel free to ask your application software supplier for your own system's root password because no one left in the Company (mass cull) knows it. 4. You might feel a little embarrassed if you have to also ask not only which room the computer is in but which office and which site.. (Answer: the empty one in another city with no people in it and a drift of mail behind the door - see mass cull above). 5. Don't get cross at your software supplier if they don't know your system's root passwords (see 3 above). 6. Feel free to be relieved at finding the root password written on the wall next to the light switch (no brownie points though for this faux pas though). 7. Oh yes - embarrassment is no longer sufficient and we have to resort to outright chagrin if you had also not renewed the hardware maintenance when notified (see both drift of mail and mass cull above) and you have to wait months for new disk drives (no support contract / waiting list / etc). 8. Please do not feel offended if your application supplier cannot install the application software on your (only file system remaining) root file system as it does not have enough space - a quart into a shot glass does not fit. So the system is down. You have no data backup at all. (After many weeks delay) you have just received your new hard disks (paying full market value) and cajoled the engineer into installing, making file systems, formatting and mounting them (as no one knew how to do it (see mass cull above). You want your application supplier to get your application back (easy - clean install. You can luckily tick the box on this one as you are still (just) inside their annual software maintenance period. :-) Please do not take it personally when you ask your application provider to reload your many wealth of gathered data (personnel records / sales history / stock .) and they ask you for good backup tapes they can use first. (See 1 [changing tapes] and 2 [stopping backups after a catastrophic failure] above). Oh yes - you are now inside the notice period for your application maintenance and have to pay another year for support on the application which is now back up but which has no data. /end of salutary tale Regards JayJay --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
