Re: [Veritas-bu] How to properly calculate the Catalog
You make some good points, Bob.
-Original Message-
From: bob944 [mailto:bob...@attglobal.net]
Sent: Sunday, March 15, 2009 6:47 PM
To: veritas-bu@mailman.eng.auburn.edu
Cc: wcplis...@gmail.com
Subject: RE: [Veritas-bu] How to properly calculate the Catalog
That formula in the manual is completely worthless. I can't
believe they still publish it. The SIZE of the data you're
backing up has NOTHING to do with the size of the index. What
matters is the number of files or objects.
[...]
I could backup a 200 TB database with a smaller NBU catalog than
[snipping the obvious (though perhaps not to NetBackup beginners):
since 99% of the catalog is a list of paths and attributes of files
backed up, a list of a million tiny files and a list of a million
giant files are going to occupy about the same catalog size.]
To get the real size of the index:
1.Calculate number of files/objects [...]
(I say 200 bytes or so. The actual number is based on the
average length of your files' path names. 200 is actually
large and should over-estimate.)
Um, to quote some guy...
That formula [...] is completely worthless.
Just kidding. Files-in-the-catalog times 200 is very old-school.
And right out of the older manuals which used 150, IIRC.
There are a couple of things to take into account here.which made me
move away from files*150--aside from the drudgery of figuring out
file-count stats per client per policy per schedule per retention.
1. smaller sizes using the binary catalog introduced in 4.5. No
idea what the file formats are, but in perusing various backups,
there appears to be a lot of deduplication of directory and file
names happening.
2. catalog compression, which may or not be important to the
calculations. Using compression, IME, reduces catalog size by
two-thirds on average, thus tripling catalog capacity for users with
longer retentions.
3. Full backups versus incrementals. The *imgRecord0 file is
usually the largest binary-catalog file for a backup; in an
incremental it is not appreciably smaller than in a full. So, in
the event that an incremental finds only, say, 10 changed files in a
100,000-file selection, the size of the catalog entry for that
incremental is nowhere near what one would expect from a small
backup--it's much closer to a full.
Though this is little predictive help to a new NetBackup
installation, getting a handle on catalog sizing for existing
systems is too easy: the number of files backed up and the size of
the files file are each lines in the metadata file. Dividing size
by files doesn't _really_ give you the number of bytes per file
entry, but it yields a great planning metric. This script:
#!/bin/sh
cd /usr/openv/netbackup/db/images
find . -name \*[LR] | \
while read metaname
do
if [ -f ${metaname}.f.Z ]
thenCOMPRESSED=C
elseCOMPRESSED=
fi
awk '
/^NUM_FILES/ { num_files = $2 }
/^FILES_FILE_SIZE/ { files_file_size = $2 }
END { if ( num_files 2 files_file_size 2 ) {
printf %4d (%s %11d / %11d ) %s\n, \
files_file_size / num_files, \
compressed, \
files_file_size, num_files, FILENAME
}
}
' compressed=$COMPRESSED $metaname
done
can be used to get a handle on catalog sizing. Sample output:
(first column is files_file_size divided by files in the backup; C
is for a compressed catalog entry, followed by the files-file size,
number of files and the pseudo-backupID)
33 (C 331651 /9884 )
./u2/123500/prod-std_1235118647_FULL
36 (C 1654789 / 45203 )
./u2/123500/prod-std_1235119960_FULL
33 (C 331497 /9884 )
./u2/123500/prod-std_1235202798_FULL
36 (C 1655827 / 45223 )
./u2/123500/prod-std_1235203103_FULL
33 (C 74293 /2236 )
./u2/123500/prod-std_1235286142_INCR
35 (C 79497 /2212 )
./u2/123500/prod-std_1235286246_INCR
33 (C 332661 /9884 )
./u2/123500/prod-std_1235808812_FULL
36 (C 1657187 / 45245 )
./u2/123500/prod-std_1235810235_FULL
32 (C 73757 /2236 )
./u2/123500/prod-std_1235890933_INCR
35 (C 79389 /2212 )
./u2/123500/prod-std_1235891054_INCR
101 ( 1001512 /9884 )
./u2/123600/prod-std_1236498790_FULL
102 ( 4644469 / 45185 )
./u2/123600/prod-std_1236498992_FULL
446 ( 1001548 /2243 )
./u2/123600/prod-std_1236664989_INCR
2092 ( 4646723 /2221 )
./u2/123600/prod-std_1236665069_INCR
Notice the last and third-last lines. They are a full and a diff of
the same filesystem. imgRecord0 makes up 3.25MB of the 4.64
files_file_size whether it's a full (45,185 files) or an incremental
(2221 files).
To loop back to the middle of this, I find that 100 bytes/file
uncompressed (35 compressed) is a good planning value for fulls on
most systems; the exceptions tend to
[Veritas-bu] Some Help Please - Status 89 on Win2k3 Standard Server SSO San Media
All hope I can have some help here. Logged a call 2 days ago with Symantec, due to the problem with this Server. NBU 5.1 MP5 Master and 6 SSO SAN Media Servers 1 Particular Server had a problem Thursday night with backup issues. It was reporting status codes of 41 and 89. Since then, the Full Backup ran and this failed with 89. The docuemnts seem to show its related to a Solaris box, but this is a Windows SAN Media Server. To the very best, no one has altered or changed anything on this box. The problem first started with restores causing the Server to lose what we call RPC connectivity. The only way to get the Server operating was to do a Power Down and Power On. Since then, its become worse. I have sent over 800mb logs now, and I wanted to post this out on the Forum in case anyone else has seen this. I still have a job running (saying its going to take 227,892 minutes to complete now!) If anyone has any ideas, truly appreciated. Regards Simon This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified. -o- Astrium Limited, Registered in England and Wales No. 2449259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] Backup speeds with new Ultra320 HBA + LTO3
Guys we have installed an Ultra320 HBA into an E220R in slot1 (66mhz) and attached dual scsi to an SL24 with 2 half heigh LTO3 drives. 1 Channel per tape drive. Single Master/Media combo This is all on Solaris 9 with Netbackup 5.0mp7. I wont go into the details but suffice to say the customer won't spend any money on backups but of course needs them to work. We only got the new SL24 due to the previous L1000 falling over constantly and not being able to get support on it easily. Anyway... I have installed all this, but am getting quite poor speeds on backups. doing a ufsdump or tar from base os doesnt get much speed and using netbackup gets higher speeds due to :- /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS = 16 /usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS = 262144 We have also added the tuning parameters into /etc/system for shared memory etc. I havn't messed with the st.conf and just let the drive do what it wants but was after any tips if that is the next area to focus on. Currently getting about 8 - 25mb/s on backups depending on amount of jobs running. e.g just doing a local backup of master server direct to the drive gets average :- r...@host-sl24# grep Kbytes/sec log.031609 15:26:35.390 [16237] 4 write_backup_completion_stats: successfully wrote 1 of 1 multiplexed backups, total Kbytes 6175485 at 10395.319 Kbytes/sec r...@host-sl24# I need to check the HBA is running at 320. I can't see any messages from dmesg or /var/adm/messages saying its been downgraded to ultra160 but it may be hidden elsewhere? Cheers ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] Backup speeds with new Ultra320 HBA + LTO3
On Mon, 16 Mar 2009, Dave Markham wrote: Guys we have installed an Ultra320 HBA into an E220R in slot1 (66mhz) and attached dual scsi to an SL24 with 2 half heigh LTO3 drives. 1 Channel per tape drive. Single Master/Media combo This is all on Solaris 9 with Netbackup 5.0mp7. I wont go into the details but suffice to say the customer won't spend any money on backups but of course needs them to work. We only got the new SL24 due to the previous L1000 falling over constantly and not being able to get support on it easily. Anyway... I have installed all this, but am getting quite poor speeds on backups. doing a ufsdump or tar from base os doesnt get much speed and using netbackup gets higher speeds due to :- /usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS = 16 /usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS = 262144 We have also added the tuning parameters into /etc/system for shared memory etc. I havn't messed with the st.conf and just let the drive do what it wants but was after any tips if that is the next area to focus on. Currently getting about 8 - 25mb/s on backups depending on amount of jobs running. e.g just doing a local backup of master server direct to the drive gets average :- r...@host-sl24# grep Kbytes/sec log.031609 15:26:35.390 [16237] 4 write_backup_completion_stats: successfully wrote 1 of 1 multiplexed backups, total Kbytes 6175485 at 10395.319 Kbytes/sec r...@host-sl24# I need to check the HBA is running at 320. I can't see any messages from dmesg or /var/adm/messages saying its been downgraded to ultra160 but it may be hidden elsewhere? Cheers ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu What speed is your NIC? Your SIZE data buffers is good but your NUMBER data buffers should probably be set to at least 32. The half-height drives may write a little slower but IMO they should be faster than that speed. Do you have both drives on the same port of the SCSI card? Only attach one drive per-port for maximum speed. What speeds do you get when you, e.g., FTP from boxA to the master? 100MiB/s? Justin. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] question on client names
The need to use FQDNs is, imho, a sign that you don't trust your DNS. FQDNs are a PITA if you ask me and I would rather take the time to make something as mission critical as DNS work right instead of hiding the real problem. To each his own, I've been on contracts before where the problem was systemic and that was the only way to get backups working without significant changes in procedures across the company but if your admins and network guys are doing their job you shouldn't have to. I guess my comment is just that 'you shouldn't have to use FQDN's' and if you don't have to I wouldn't. To each his own. Date: Sun, 15 Mar 2009 13:48:49 -0500 From: Ed Wilts c Subject: Re: [Veritas-bu] question on client names To: judy_hinchcli...@administaff.com Cc: VERITAS-BU@mailman.eng.auburn.edu Message-ID: 995e39b60903151148taacbbadv84f17f6c60a84...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On Fri, Mar 13, 2009 at 2:06 PM, judy_hinchcli...@administaff.com wrote: So I was just wondering. When you add servers to netbackup do you use short name or FQDN. Always, always use FQDNs. Short names are simply evil. .../Ed Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE ewi...@ewilts.org -- next part -- An HTML attachment was scrubbed... URL: http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20090315/ cd9e3a4b/attachment-0001.html Barclays www.barclaycardus.com This e-mail and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity who is the intended recipient. Unauthorized use of this information is prohibited. If you have received this in error, please contact the sender by replying to this message and delete this material from any system it may be on. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] question on client names
We have only used short names for all our backups. Geoff's comments are right on.. Our DNS works fine. The main thing is to be sure that forward and reverse look-ups work. Netbackup is very fussy about that. -- Carl Stehman Distributed Services Pepcoholdings, Inc. 701 Ninth St NW Washington DC 20068 202-331-6619 Stafford, Geoff gstaff...@barclaycardus.com Sent by: veritas-bu-boun...@mailman.eng.auburn.edu 03/16/2009 01:45 PM To judy_hinchcli...@administaff.com, ewi...@ewilts.org cc VERITAS-BU@mailman.eng.auburn.edu Subject Re: [Veritas-bu] question on client names The need to use FQDNs is, imho, a sign that you don?t trust your DNS. FQDNs are a PITA if you ask me and I would rather take the time to make something as mission critical as DNS work right instead of hiding the real problem. To each his own, I?ve been on contracts before where the problem was systemic and that was the only way to get backups working without significant changes in procedures across the company but if your admins and network guys are doing their job you shouldn?t have to. I guess my comment is just that ?you shouldn?t have to use FQDN?s? and if you don?t have to I wouldn?t. To each his own. Date: Sun, 15 Mar 2009 13:48:49 -0500 From: Ed Wilts c Subject: Re: [Veritas-bu] question on client names To: judy_hinchcli...@administaff.com Cc: VERITAS-BU@mailman.eng.auburn.edu Message-ID: 995e39b60903151148taacbbadv84f17f6c60a84...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On Fri, Mar 13, 2009 at 2:06 PM, judy_hinchcli...@administaff.com wrote: So I was just wondering. When you add servers to netbackup do you use short name or FQDN. Always, always use FQDNs. Short names are simply evil. .../Ed Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE ewi...@ewilts.org -- next part -- An HTML attachment was scrubbed... URL: http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20090315/cd9e3a4b/attachment-0001.html ___ Barclays www.barclaycardus.com ___ This e-mail and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity who is the intended recipient. Unauthorized use of this information is prohibited. If you have received this in error, please contact the sender by replying to this message and delete this material from any system it may be on. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu This Email message and any attachment may contain information that is proprietary, legally privileged, confidential and/or subject to copyright belonging to Pepco Holdings, Inc. or its affiliates (PHI). This Email is intended solely for the use of the person(s) to which it is addressed. If you are not an intended recipient, or the employee or agent responsible for delivery of this Email to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. If you have received this message in error, please immediately notify the sender and permanently delete this Email and any copies. PHI policies expressly prohibit employees from making defamatory or offensive statements and infringing any copyright or any other legal right by Email communication. PHI will not accept any liability in respect of such communications. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] question on client names
I have been of the same opinion. But with the new domains, I cannot install across the domains, so I have to do some special stuff to get the netbackup files up on the domain to upgrade those servers. This is where I am having the issue, so when I do the upgrade I need to be able to say these 4 servers are on a different domain and know that I have to do special steps. From: Stafford, Geoff [mailto:gstaff...@barclaycardus.com] Sent: Monday, March 16, 2009 12:28 PM To: Judy Hinchcliffe; ewi...@ewilts.org Cc: VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] question on client names The need to use FQDNs is, imho, a sign that you don't trust your DNS. FQDNs are a PITA if you ask me and I would rather take the time to make something as mission critical as DNS work right instead of hiding the real problem. To each his own, I've been on contracts before where the problem was systemic and that was the only way to get backups working without significant changes in procedures across the company but if your admins and network guys are doing their job you shouldn't have to. I guess my comment is just that 'you shouldn't have to use FQDN's' and if you don't have to I wouldn't. To each his own. Date: Sun, 15 Mar 2009 13:48:49 -0500 From: Ed Wilts c Subject: Re: [Veritas-bu] question on client names To: judy_hinchcli...@administaff.com Cc: VERITAS-BU@mailman.eng.auburn.edu Message-ID: 995e39b60903151148taacbbadv84f17f6c60a84...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On Fri, Mar 13, 2009 at 2:06 PM, judy_hinchcli...@administaff.com wrote: So I was just wondering. When you add servers to netbackup do you use short name or FQDN. Always, always use FQDNs. Short names are simply evil. .../Ed Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE ewi...@ewilts.org -- next part -- An HTML attachment was scrubbed... URL: http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20090315/ cd9e3a4b/attachment-0001.html ___ Barclays www.barclaycardus.com ___ This e-mail and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity who is the intended recipient. Unauthorized use of this information is prohibited. If you have received this in error, please contact the sender by replying to this message and delete this material from any system it may be on. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] question on client names
The problem is, if you have multiple sites, DNS is limited (at least in Linux/glibc) to 6 sub domains, after that, you're going to have problems. Better off with FQDN IMO. search Search list for host-name lookup. The search list is normally determined from the local domain name; by default, it contains only the local domain name. This may be changed by listing the desired domain search path follow- ing the search keyword with spaces or tabs separating the names. Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found. For environments with multiple subdomains please read options ndots:n below to avoid man-in- the-middle attacks and unnecessary traffic for the root-dns- servers. Note that this process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and that queries will time out if no server is avail- able for one of the domains. The search list is currently limited to six domains with a total of 256 characters. Justin. On Mon, 16 Mar 2009, Stafford, Geoff wrote: The need to use FQDNs is, imho, a sign that you don't trust your DNS. FQDNs are a PITA if you ask me and I would rather take the time to make something as mission critical as DNS work right instead of hiding the real problem. To each his own, I've been on contracts before where the problem was systemic and that was the only way to get backups working without significant changes in procedures across the company but if your admins and network guys are doing their job you shouldn't have to. I guess my comment is just that 'you shouldn't have to use FQDN's' and if you don't have to I wouldn't. To each his own. Date: Sun, 15 Mar 2009 13:48:49 -0500 From: Ed Wilts c Subject: Re: [Veritas-bu] question on client names To: judy_hinchcli...@administaff.com Cc: VERITAS-BU@mailman.eng.auburn.edu Message-ID: 995e39b60903151148taacbbadv84f17f6c60a84...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On Fri, Mar 13, 2009 at 2:06 PM, judy_hinchcli...@administaff.com wrote: So I was just wondering. When you add servers to netbackup do you use short name or FQDN. Always, always use FQDNs. Short names are simply evil. .../Ed Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE ewi...@ewilts.org -- next part -- An HTML attachment was scrubbed... URL: http://mailman.eng.auburn.edu/pipermail/veritas-bu/attachments/20090315/ cd9e3a4b/attachment-0001.html Barclays www.barclaycardus.com This e-mail and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity who is the intended recipient. Unauthorized use of this information is prohibited. If you have received this in error, please contact the sender by replying to this message and delete this material from any system it may be on. ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] Issue with NBU 6.5.3.1 scheduler
Since upgrading our largest NBU environemnts to 6.5.3.1 for the DST scheduler issue, we've run into another bug. On Sunday, policies that have a window crossing midnight are submitted again and run for that day's run. Initially, we thought this to be an issue with DST time change, but it repeated again. All schedules are setup as calendar schedules as recommended by Symantec retries allowed after runday is not checked backup windows match days selected. i.e. daily incremental have a window m-f, calendar matches this selection Here is the activity log for one of our many policies: Job Id Type State State Details Status Policy Schedule ClientMedia Server Storage Unit Elapsed Time Start Time End Time KB per Second Kilobytes Files Parent -- 514087 Backup Done0wat_watna02_ndmp_vol0 daily_dincr watna02 watbkp01 NDMP_watna02 00:41:49 03/15/2009 00:00:00 03/15/2009 00:41:49 15734 1443898 299 514087 513588 Backup Done0wat_watna02_ndmp_vol0 daily_dincr watna02 watbkp01 NDMP_watna02 00:06:59 03/14/2009 19:00:00 03/14/2009 19:06:59 12547 1151515 196 513588 512725 Backup Done0wat_watna02_ndmp_vol0 weekly_full watna02 watbkp01 NDMP_watna02 00:42:39 03/13/2009 19:00:00 03/13/2009 19:42:39 32806 1113134549985 512725 511855 Backup Done0wat_watna02_ndmp_vol0 daily_dincr watna02 watbkp01 NDMP_watna02 00:05:39 03/12/2009 19:00:00 03/12/2009 19:05:39 4718290116 197 511855 As you can see, it executes fine at 19:00, except for 03/15. +-- |This was sent by nate.burri...@glasshouse.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] Thomas Schulz/DE/ConSors ist außer Haus.
Ich werde ab 16.03.2009 nicht im Büro sein. Ich kehre zurück am 19.03.2009. Ich werde Ihre Nachrichten nach meiner Rückkehr beantworten. Cortal Consors S.A. Zweigniederlassung Deutschland, Bahnhofstraße 55, D-90402 Nürnberg, HR Nürnberg B 20075, USt-IdNr. DE225900761 Sitz der Cortal Consors S.A.: 1, boulevard Haussmann, F-75318 Paris cedex 09, Registergericht: R.C.S. Paris 327 787 909 Président du Conseil d'Administration (Verwaltungsratsvorsitzender) und Directeur Général (Generaldirektor) der Cortal Consors S.A.: Olivier Le Grand Leitung der Zweigniederlassung Deutschland: Martin Daut (CEO Deutschland), Olivier Le Grand, Richard Döppmann, Pascal Grundrich Before printing, think about environmental responsibility! ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] Issue with NBU 6.5.3.1 scheduler
Here is my policy: 2bppllist: INITIATING: version NetBackup 6.5 created: 2008103023 Policy Name: wat_watna02_ndmp_vol0 Policy Type: NDMP Active: yes Effective date: 07/25/2008 00:00:01 Mult. Data Streams: no Client Encrypt: no Checkpoint: no Policy Priority: 0 Max Jobs/Policy: Unlimited Disaster Recovery: 0 Collect BMR info:no Residence: NDMP_watna02 Volume Pool: 90day_biowat01 Server Group:*ANY* Keyword: ndmp Data Classification: - Residence is Storage Lifecycle Policy:no Granular Restore Info: no HW/OS/Client: NDMP NDMP watna02 Include: /vol/vol0/ Schedule: monthly_full Type:Full Backup Maximum MPX: 1 Synthetic: 0 PFI Recovery:0 Retention Level: 9 (infinity) Number Copies: 1 Fail on Error: 0 Residence: NDMP_watna02 Volume Pool: infinite_biowat01 Server Group:(same as specified for policy) Calendar sched: Enabled Friday, Week 1 Residence is Storage Lifecycle Policy: 0 Daily Windows: Friday 19:00:00 -- Saturday 08:00:00 Schedule: weekly_full Type:Full Backup Maximum MPX: 1 Synthetic: 0 PFI Recovery:0 Retention Level: 5 (90 days) Number Copies: 1 Fail on Error: 0 Residence: (specific storage unit not required) Volume Pool: (same as policy volume pool) Server Group:(same as specified for policy) Calendar sched: Enabled Friday, Week 2 Friday, Week 3 Friday, Week 4 Friday, Week 5 Residence is Storage Lifecycle Policy: 0 Daily Windows: Friday 19:00:00 -- Saturday 08:00:00 Schedule: daily_dincr Type:Differential Incremental Backup Maximum MPX: 1 Synthetic: 0 PFI Recovery:0 Retention Level: 5 (90 days) Number Copies: 1 Fail on Error: 0 Residence: (specific storage unit not required) Volume Pool: (same as policy volume pool) Server Group:(same as specified for policy) Calendar sched: Enabled Sunday, Week 1 Monday, Week 1 Tuesday, Week 1 Wednesday, Week 1 Thursday, Week 1 Saturday, Week 1 Sunday, Week 2 Monday, Week 2 Tuesday, Week 2 Wednesday, Week 2 Thursday, Week 2 Saturday, Week 2 Sunday, Week 3 Monday, Week 3 Tuesday, Week 3 Wednesday, Week 3 Thursday, Week 3 Saturday, Week 3 Sunday, Week 4 Monday, Week 4 Tuesday, Week 4 Wednesday, Week 4 Thursday, Week 4 Saturday, Week 4 Sunday, Week 5 Monday, Week 5 Tuesday, Week 5 Wednesday, Week 5 Thursday, Week 5 Saturday, Week 5 Residence is Storage Lifecycle Policy: 0 Daily Windows: Sunday 19:00:00 -- Monday 08:00:00 Monday 19:00:00 -- Tuesday08:00:00 Tuesday19:00:00 -- Wednesday 08:00:00 Wednesday 19:00:00 -- Thursday 08:00:00 Thursday 19:00:00 -- Friday 08:00:00 Friday 19:00:00 -- Saturday 08:00:00 Saturday 19:00:00 -- Sunday 08:00:00 2bppllist: EXIT status = 0 +-- |This was sent by nate.burri...@glasshouse.com via Backup Central. |Forward SPAM to ab...@backupcentral.com. +-- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] question on client names
On Mon, Mar 16, 2009 at 12:28 PM, Stafford, Geoff gstaff...@barclaycardus.com wrote: The need to use FQDNs is, imho, a sign that you don’t trust your DNS. I trust the DNS - I have extensive DNS experience and our company would be down without a fully functioning DNS infrastructure. Ours works. FQDNs are a PITA if you ask me and I would rather take the time to make something as mission critical as DNS work right instead of hiding the real problem. FQDNs make it absolutely clear what's going on. Remember, you can't do a backup using a short form name anyway - internally, you're resolving to a fqdn whether you like it or not. You're not only relying on FQDNs, but you're also relying on the search lists configured properly everywhere. You can take all the short cuts you want, but not taking the short cuts saves you headaches later, as MANY people have found out. .../Ed Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE ewi...@ewilts.org ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
Re: [Veritas-bu] question on client names
Resolving search lists doesn't mean they have to be configured correctly everywhere. Just for the server and the client involved in the current problem. That is to say while it needs to be configured everywhere to make each client work when their turn comes in the schedule it is a red herring to suggest that you need to concern yourself with that everywhere when troubleshooting a specific issue. If there's been an everywhere change it will become apparent due to the fact that most of the clients will fail. That kind of global failure due to bad planning can occur regardless of which method you use. (e.g. What happens if all your FQDNs are suddently invalid due to a domain name change?) In a related point: If you use short names and search lists then you don't have to go edit all your policies with new domain names if they change (and on occasion they do especially in mergers/acquisitions). You just have to edit the resolv.conf on each of the servers and clients. That can be easily scripted (as in fact it was here recently when we swapped out decommissioned named servers for new ones). In the very few cases where I've thought difference between searched name and FQDN might be a problem I've addressed it by adding entry to master/media server hosts file and the specific client. From: veritas-bu-boun...@mailman.eng.auburn.edu [mailto:veritas-bu-boun...@mailman.eng.auburn.edu] On Behalf Of Ed Wilts Sent: Monday, March 16, 2009 3:07 PM To: Stafford, Geoff Cc: VERITAS-BU@mailman.eng.auburn.edu Subject: Re: [Veritas-bu] question on client names On Mon, Mar 16, 2009 at 12:28 PM, Stafford, Geoff gstaff...@barclaycardus.com wrote: The need to use FQDNs is, imho, a sign that you don't trust your DNS. I trust the DNS - I have extensive DNS experience and our company would be down without a fully functioning DNS infrastructure. Ours works. FQDNs are a PITA if you ask me and I would rather take the time to make something as mission critical as DNS work right instead of hiding the real problem. FQDNs make it absolutely clear what's going on. Remember, you can't do a backup using a short form name anyway - internally, you're resolving to a fqdn whether you like it or not. You're not only relying on FQDNs, but you're also relying on the search lists configured properly everywhere. You can take all the short cuts you want, but not taking the short cuts saves you headaches later, as MANY people have found out. .../Ed Ed Wilts, RHCE, BCFP, BCSD, SCSP, SCSE ewi...@ewilts.org Please consider our environment before printing this e-mail or attachments. -- CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you. -- ___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
[Veritas-bu] dedup/replication
Hello- Without using OST, is there a way to get a physical tape copy from a deduped/replicated image? We have a local EDL/3DL replicating (de-duped data) to a remote EDL/3DL. We need to get a physical tape from the remote copy, but it has to NBU-aware. Thanks in advance! _ Windows Live™ Groups: Create an online spot for your favorite groups to meet. http://windowslive.com/online/groups?ocid=TXT_TAGLM_WL_groups_032009___ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
