- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: Hot backups with fbackup
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-23-2002 07:46 AM
тАО07-23-2002 07:46 AM
SolutionOur databse is mirrored, and I have been performing recoverable automatic backs for several years. Via the following steps. My actual scripts are highly automated and gets its information from a table. So I listed the steps and put examples to each step. This should be enough info for you to figure out how to doit. It took about 2 hours to write the script and tables. I have a program that scans the logfile of the scripts which reports any errors. Some one mentioned fbackup file size limitations. Once the mirrors are mounted you can back them using any method. Make sure you backup the archive logs so that you do forward recovery of the database.
Rory
# Step 1. Set up databases for hot backups by putting them
# in backup mode
#
A: alter system archive log stop;
b: For all of the tablespaces:
alter tablespace tablespace begin backup;
# Step 2. Split mirrors
#
# split the mirrored logical volumes using a single lvsplit command
# instead of separate ones, as this will ensure that
# the drives are consistent in time. This assumes all of lvols are in the same volume group.
A. /usr/sbin/lvsplit /dev/vg01/lvol /dev/vg01/lvol2 /dev/vg01/lvol3
B./usr/sbin/lvsplit /dev/vg02/lvol /dev/vg02/lvol2 /dev/vg02/lvol3
#Step 3. Resume normal database operation. NOTE When automated the database is down in backup mode for a very short time! --less than a minute.
A: alter system archive log start;
b: For all of the tablespaces:
alter tablespace tablespace end backup;
# Step 4. Mount the split filesystems. You need to run fsck on hfs., the veritas doesn't seem to need any thing done.
# filesystem check (fsck) the formerly mirrored logical volumes
# the 'b' extension to the names indicates they're the copies
/usr/sbin/fsck -p /dev/vg01/lvolb
/usr/sbin/fsck -p /dev/vg01/lvol2b
/usr/sbin/fsck -p /dev/vg01/lvol3b
mount /dev/vg01/lvol1b /mnt/db1
mount /dev/vg01/lvol2b /mnt/db2
mount /dev/vg01/lvol3b /mnt/db3
# Step 5. Back up the database
# Use fbackup graphs pointing to backup mount points
# Step 6. Unmount the split filesystems
#
umount /dev/vg01/lvol1b
umount /dev/vg01/lvol2b
umount /dev/vg01/lvol3b
# Step 7. Merge filesystems to re-establish mirroring
#
lvmerge /dev/vg01/lvol1b /dev/vg01/lvol1
lvmerge /dev/vg01/lvol2b /dev/vg01/lvol2
lvmerge /dev/vg01/lvol3b /dev/vg01/lvol
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-23-2002 09:11 AM
тАО07-23-2002 09:11 AM
Re: Hot backups with fbackup
First I would like to thank everyone for the lively and pointed discussion regarding this question. We have been researching this question for about 2 months now and have learned there is not easy answer.
Rory, thank-you for your explaination and well laid out scenario. It just so happens that we do use Mirror/Ux and have been testing the split mirror backup. One further question though. If per chance we were to have a disaster and lost both copies of the mirrored data, how would we recover the data? Would we frecover the data to the mirror drive set and then lvsync them, since the backup is really of the mirror directory, in your example the 'b' version?
Thanks again for your time answering these questions.
Dewy
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-23-2002 08:17 PM
тАО07-23-2002 08:17 PM
Re: Hot backups with fbackup
To add to what Mr. Rory said:
============================================================
Before you split the mirrors, you should also issue an ALTER SYSTEM SUSPEND;
From the backup and recovery guide:
Making Backups in a Suspended Database
After a successful database suspension, you
can back up the database to disk or break the mirrors. Because suspending a
database does not guarantee immediate termination of I/O, Oracle recommends
that you precede the SUSPEND statement with a BEGIN BACKUP statement to
place the tablespaces in hot backup mode.
You must use conventional operating system backup methods to back up split
mirrors. RMAN cannot make database backups or copies because these operations
require reading the datafile headers. After the database backup is finished or
the mirrors are re-silvered, then you can resume normal database operations
using the RESUME statement.
Backing up a suspended database without splitting mirrors can cause an extended
database outage because the database is inaccessible during this time. If
backups are taken by splitting mirrors, however, then the outage is nominal. The
outage time depends on the size of cache to flush, the number of datafiles, and
the time required to break the mirror.
That quote was taken from:
http://technet.oracle.com/docs/products/oracle8i/doc_library/817_doc/server.817/a76993/osbackup.htm#940
So, I you won't be using many RMAN features on the split mirror database. You
can use RMAN to basically "copy the file". You'll be taking advantage of the
recovery catalog but thats about it. RMAN will just be copying files. You can
also use RMAN with a standby (data guard) database to offload backups to another
machine.
see
http://technet.oracle.com/docs/products/oracle8i/doc_library/817_doc/server.817/a76990/usingrma.htm#441865
for details on backing up a split mirror database with RMAN.
============================================================
Hope this helps!
Best Regards
Yogeeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-23-2002 08:22 PM
тАО07-23-2002 08:22 PM
Re: Hot backups with fbackup
A few more from my notes about COLD v/s HOT backups!
============================================================
Why would you be doing cold backups at all???
You do not want to do the split mirrors. You will obviate many of the benefits
and features of RMAN. You should just be doing HOT backups with RMAN (no need
to "alter tablespace begin/end backup" with RMAN).
You can do the split mirrors with RMAN but its just like doing the backup
without RMAN. You will lose the features available in RMAN that aren't
available without RMAN.
Just do hot backups right now. They are not any harder then cold backups. Your
system should be 100% available right now, today, nothing special need be done.
But -- the bottom line is -- you should have ALWAYS been doing hot backups.
Split mirrors, unless you have triple mirroring, will open you up to failure
during your backup and re-silvering window. Just do a plain old hot backup, its
all you need or want. Don't over complicate the issue with split mirrors,
re-silvering, datafile copies instead of RMAN backups and such.
Hot backups and cold backups are not significantly different from each other in
many respects. there are much FEWER options with cold then hot but they are
very similar.
by the way -- it is really not HOT vs COLD, rather it is ARCHIVE LOG vs
NO-ARCHIVE log. Whether you do hot or cold is up to you.
Lets take an example. We are in ARCHIVE LOG mode. I did a backup last night at
12am. At 8am this morning I did a non-recoverable action -- I did a create
table as select without logging it and dropped the table I just copied (i did a
"reorg" if you will). At 8:30am -- the disks that held the datafiles all
failed. So, what can I do? I can restore my backup from lastnight and either:
o recover it to 7:59:59 AM (or any point in time between 12am and 7:59:59).
I'll have my entire database back to what it looked like at that point in time.
I'll have my table before I dropped it. We won't have the newly created table
of course.
o recover it completely. Now I'll have all of my data EXCEPT that table since
it was not logged.
in the real world, we would have backed up our datafile we did the create
table as select without logging IMMEDIATELY after doing that operation to make
it so we would NOT lose this data. We would tend to want to HOT BACKUP this
file
Now, lets say we did the same thing in noarchive log mode. I did a backup last
night at 12am. At 8am this morning I did a non-recoverable action -- I did a
create table as select without logging it and dropped the table I just copied (i
did a "reorg" if you will). At 8:30am -- the disks that held the datafiles all
failed. So, what can I do?
o I can restore the database to 12am. Period, zippo, thats it, nothing else.
So, just to re-iterate -- it is not HOT vs COLD, its archive log vs no-archive
log and you need to backup (probably in HOT mode) datafiles that are affected by
non-logged operations ASAP after doing them to protect yourself. (eg: in my
example above, I would have created the table as select, BACKED UP the affected
file(s), dropped the old table. At no point in time would I have lost any data)
============================================================
Hope this helps!
Best Regards
Yogeeraj
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-24-2002 02:40 AM
тАО07-24-2002 02:40 AM
Re: Hot backups with fbackup
"fbackup(3009): WARNING: File number NNN was not successfully backed up" for an active file.
This maybe reflects the metalink warnings about using fbackup with a changing inode.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-24-2002 03:06 AM
тАО07-24-2002 03:06 AM
Re: Hot backups with fbackup
Concerning tar (and other classic Unix backup tools) almost every database is pushing the 2Gb limit and these tools cannot be used for large files.
Bill Hassell, sysadmin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО07-24-2002 03:46 AM
тАО07-24-2002 03:46 AM
Re: Hot backups with fbackup
I can reproduce this now and fbackup generally objects to the active logfile. cp just copies it.
Regards
SMF
- « Previous
-
- 1
- 2
- Next »