|
We're
using advanced client for offhost backups, using nbu_snap (using the media
server as the data mover, not doing Flashbackup). Currently only on MP4,
haven't got around to MP5 yet though it is supposed to include fixes for some of
the issues we have had, namely :
1. Doesn't work properly with vnetd, so some traffic still attempts
to go over random ports. A problem if you have a firewall between your
media server and client.
2. Cache size was limited to < 1 Tb (not sure why we found this,
we're not using anything like this size cache now).
3. Filesystem size was limited to < 2 Tb (may still
be).
4. Backups were failing when files changed in size during the
backup (rather than ending with a status code 1).
I have
found that occasionally the cache will not be cleared down if a backup fails,
though haven't bottomed out exactly how it has to fail for this to be the
case. So it may be worth writing some scripts to monitor the status of the
cache & snapshotted filesystems.
So in
your example, A, B and C should all run but sometimes if B fails it won't clear
up properly ... and if the cache is then not empty enough for C, it will also
fail. It should start, because as I understand it the cache is only used
as changes are made to the original filesystem.
cheers, Phil
All,
Anyone have any "gotchas" to report using block level, copy-on-write
backups using the nbu_snap (Solaris only) method with NBU 5.1 MP5's
Advanced Client?
I'm
getting closer to implementation time here, and my biggest concern is the
cache size at the moment.
One
thing I'm concerned about is using a single job to back up all raw disk
devices on the system. In the event of a full cache and subsequent
failed backup on a particular stream, can anyone confirm that the cache will
clear prior to the next stream in the file list for the job? Or does the
job have to be restarted completely?
Here's the scenario...
Job
list is:
/dev/rdsk/A
/dev/rdsk/B
/dev/rdsk/C
Where A is successful, B fills up
the cache and craps out. Does C start?
Thanks,
Jon
(in an environment where I can't just plug
in a cache that's as big as my largest disk
unfortunately)
This message may contain privileged and/or
confidential information. If you have received this e-mail in error or
are not the intended recipient, you may not use, copy, disseminate or
distribute it; do not open any attachments, delete it immediately from your
system and notify the sender promptly by e-mail that you have done so.
Thank you.
Egg is a trading name of the Egg group of companies which includes:
Egg plc (reg no
2448340), Egg Financial Intermediation Ltd
(reg no 3828289), and Egg Banking plc (reg
no 2999842). Egg Banking plc and Egg
Financial Intermediation Ltd are authorised
and regulated by the Financial Services
Authority (FSA) and are entered in the FSA
register under numbers 205621 and 309551
respectively. These members of the Egg group
are registered in England and Wales.
Registered office: 1 Waterhouse Square, 138-
142 Holborn, London EC1N 2NA.
This e-mail is confidential and for use by
the addressee only. If you are not the
intended recipient of this e-mail and have
received it in error, please return the
message to the sender by replying to it and
then delete it from your mailbox. Internet e-
mails are not necessarily secure. The Egg
group of companies do not accept
responsibility for changes made to this
message after it was sent.
Whilst all reasonable care has been taken to
avoid the transmission of viruses, it is the
responsibility of the recipient to ensure
that the onward transmission, opening or use
of this message and any attachments will not
adversely affect its systems or data. No
responsibility is accepted by the Egg group
of companies in this regard and the
recipient should carry out such virus and
other checks as it considers appropriate.
This communication does not create or modify
any contract.
|
