Highlighted
Knowledge Partner
Knowledge Partner

Re: OES11 backup vendors

On 04.05.2012 12:56, magic31 wrote:
>
> gleach1;2174116 Wrote:
>> Based on my experience the only backup software i'd even both with is
>> sesam
>>

>
> + one for Tivoli TSM (in it's favor as being a very solid backup
> solution). We have a couple of OES11 servers running the 6.2.4 client
> against TSM Server 5.5 and one TSM 6.3 server. With the xattr NSS
> option set it is working well.


Any backup software that needs the xattr set on NSS volumes (e.g is
*not* using TSA) doesn't work well in my book. It's a mutual exclusion.

It may be ok for *some*, but certainly not for everybody. Think of
compression. Consider DFS. Both are killer features you can only back up
properly through software that uses TSA.

Thats said, I would *NEVER* ever consider any backup software not using
TSAs as a general proper solution to backup NSS.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: OES11 backup vendors

mrosen;2193795 wrote:
Thats said, I would *NEVER* ever consider any backup software not using
TSAs as a general proper solution to backup NSS.


Before working with Tivoli I was accustomed to using CommVault (as also BackupExec and ArcServe.. but these last two are not enterprise solutions imo). I was skeptical at first with Tivoli and not having TSA support. As customers were using it and wanted to keep doing so it was sort-of a forced choice at first. For me the experiences with Tivoli and OES these last 4 to 5 years have shown it works well. Next to the daily routines, we run full test DR scenarios for different sites - 8 to 12 times a year. I have not seen any issues due to not using TSA and Tivoli with OES2 and now OES11. Linux is in that effect a different beast than NetWare was.

Your point for DST is valid, as it means it's harder to do a restore (as in having to look and check two locations vs one).

One strong option Tivoli has is the ' forever incremental'. This keeps backup windows to a minimum and each day a full backup can be made, also on those servers running terrabytes of data and millions of files. Having TSA in de mix can (severely) slow the backup done and is much more prone to tuning and versioning.
The client also compresses the data before sending it to the server and all data is stored in compressed format with the Tivoli data stores.
Most NSS volumes in our setups don't have compression set on the volume.. so not much of an issue.

Different experiences and POV's... I don't share the *NEVER* consider view. But it has to be considered properly indeed. No fun like having to grab for a backup that ain't in working order and won't restore properly.


Cheers,
Willem
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: OES11 backup vendors

Willem,

On 04.05.2012 17:06, magic31 wrote:
>
> Your point for DST is valid, as it means it's harder to do a restore
> (as in having to look and check two locations vs one).


Not only that. With such a backup solution, you can't use the feature to
demigrate files based on their access. TSA connections don't count as
access. Everything else does.


> Most NSS volumes in our setups don't have compression set on the
> volume.. so not much of an issue.


....for you. 😉 As I said, it can work fine for some, but you need to be
aware of it's ramifications.


CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: OES11 backup vendors

mrosen;2193913 wrote:
Willem,

On 04.05.2012 17:06, magic31 wrote:
>
> Your point for DST is valid, as it means it's harder to do a restore
> (as in having to look and check two locations vs one).


Not only that. With such a backup solution, you can't use the feature to
demigrate files based on their access. TSA connections don't count as
access. Everything else does.


> Most NSS volumes in our setups don't have compression set on the
> volume.. so not much of an issue.


....for you. 😉 As I said, it can work fine for some, but you need to be
aware of it's ramifications.


CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
Untitled Document


For the de-migrate, do you mean the default setting of say:
If file accessed more than 2 times in a 24-hour time period, shift back to Primary? (I'm paraphrasing)?

I was under the impression that any "server" side activity (ie, NRM inventory, etc.) that "touched" files didn't count for DST, but rather connections made via NCP?

(I'm just asking). We use nasty NetBackup and have never noticed any of the backups causing a shift (or NRM), although to be honest, it would be VERY VERY rare to run 2 backups of the DST volume within a 24-hour time period (one of the point of DST is that you plop the least-used stuff over there and then don't have to back it up again for a long time).

Again, just asking out loud in case it helps anyone else (I totally agree that ideally TSA-aware software should be used, although it looks like Commvault/Tivoli have resolved the issue with "synthetic" backups, whereas Symantec REQUIRES non-TSA to do this).
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: OES11 backup vendors

Kevin,

On 04.05.2012 19:56, kjhurni wrote:
> For the de-migrate, do you mean the default setting of say:
> If file accessed more than 2 times in a 24-hour time period, shift back
> to Primary? (I'm paraphrasing)?


Correct.

> I was under the impression that any "server" side activity (ie, NRM
> inventory, etc.) that "touched" files didn't count for DST, but rather
> connections made via NCP?


Nope. All "regular" access count. NCP, CIFS, AFP, SCP, POSIX, you name
it. *Just* TSA does not. NRM opening a txt file? Counts. NRM doing a
file content search? Counts. Local AV scanner doing a scheduled AV scan?
Count. And so on, and so on. Same thing as with compression/decompression.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: OES11 backup vendors

Hi all

We using DST and BackExec since about 3 years. To to avoid this pitfall, we
do a backup pre-script with "mount -o remount,noatime /media/nss/V001" and
at end of job "mount -o remount,atime /media/nss/V001".

Anyway, since BackExec do not support OES11 ans 64Bit NSS, may be we will
move to SEP...

regards
Markus


>
> Nope. All "regular" access count. NCP, CIFS, AFP, SCP, POSIX, you name it.
> *Just* TSA does not. NRM opening a txt file? Counts. NRM doing a file
> content search? Counts. Local AV scanner doing a scheduled AV scan? Count.
> And so on, and so on. Same thing as with compression/decompression.



0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: OES11 backup vendors

Hi.

On 05.05.2012 12:31, markusernst wrote:
> Hi all
>
> We using DST and BackExec since about 3 years. To to avoid this pitfall, we
> do a backup pre-script with "mount -o remount,noatime /media/nss/V001" and
> at end of job "mount -o remount,atime /media/nss/V001".
>
> Anyway, since BackExec do not support OES11 ans 64Bit NSS, may be we will
> move to SEP...


Just to avoid some confusion here:

1. BackupExec does not support OES11 (yet). Totally unrelated to it's
bitness.

2. BackupExec also does not *work* technically with OES11, which only
has one reason, and that is that the RALUS client checks the version,
and refuses to work with anything other than OES2. If you fool it into
believeing it is OES2, it starts to work (but of course is still not
supported, and additionally, now your OES install is also technically
unsupported).

3. BackupExec supports and works on 64Bit OES2. The common statement
that BE has a problem or doesn't support 64Bit NSS is wrong.

CU,
--
Massimo Rosen
Novell Knowledge Partner
No emails please!
http://www.cfc-it.de
CU,
--
Massimo Rosen
Micro Focus Knowledge Partner
No emails please!
http://www.cfc-it.de
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: OES11 backup vendors

Hi Massimo

1) I know, we had opened a SR at Symantec about OES11 (and 64bit NSS), but
they points to link at 3) below

2) Yes, there is a workaround to edit /etc/novell-release, but I think this
is not suitable for real environment ...

3) It work with , but it's not supported by Symantec:
http://www.symantec.com/business/support/index?page=content&id=TECH175581
Page 16, remark 5:
Supported with Novell Open Enterprise Server (OES) 2.0 SP1-SP3, with
NSS,
NDS, GroupWise and iFolder on 32-bit and 64-bit platforms for SUSE 10
only.
(NOTE:NSS only supported on 32-bit)

regards
Markus

>
> 3. BackupExec supports and works on 64Bit OES2. The common statement that
> BE has a problem or doesn't support 64Bit NSS is wrong.
>
> CU,
> --
> Massimo Rosen
> Novell Knowledge Partner
> No emails please!
> http://www.cfc-it.de



0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.