ADSM-L

Re: Full backup whit client NT

2015-10-04 18:07:24
Subject: Re: Full backup whit client NT
From: Sal Salak Juraj [SMTP:IMCEAMS-KEBALINZ_CENTRAL_sal AT MSMAIL.KEBA.CO DOT AT]
To: ADSM-L AT VM.MARIST DOT EDU
dan thomspon wrote on June the 7.:

~
~ As many of the ADSM gurus on this forum would probably point out,
there is
~ rarely a reason to do archive or full backups as this goes against
ADSM's
~ design.  I am curious about the customer requirement that is driving
your
~ intention to run a montly archive.  There is most likely an easier
method
~ of providing this.

Dan,
I believe the primer of backup is not be conform with any tool.s design,
this only can be good technique.
The primer of backup sulution has to be satisfaction of  user
requirements
(as long as users  understand what they want).


~  .. curious about the customer requirement that is driving your
~ intention to run a montly archive.

At our site, our users/customers have
simillar requirements.
Here  simplified and shortened:

1)  protection against errors:
 keep backup of few last file versions for few weeks
 This is perfectly covered by INCREMENTAL.

2)  limited disaster protection (disk crash, etc.) : be able to restore
file system in last known good state.
 This is protected by INCREMENTAL, as lon as you did not try to run it
after disk crash ( files become expireed, and you have to labor with
-fromtime etc..)
3) project backups: backup all files belonging to single development in
3) project backups: backup all files belonging to single development in
defined stages, keep them for defined period of time (usually years), be
able to restore them on any node. This is because of guarantee - we have
to be able to correct errors in our software even couple years after we
have sold it. (well, large monoplostics companies like ...  do not do
this - but we do it)
This is only supported by ARCHIVE, and even by ARCHIVE far less then
perfectly.

4) project stupidity protection:
keep full backups of whole file systems for long time periods in
addition to project backups. Considering the complexity of typical
projects and interconnections between projects it  is realistic that
should project manager will forgett to include a file in a project
backup. Regular file system backup will possibly help to find the
correct file.
Only supported by ARCHIVE.

5) consistency constraints:
some file groups, e.g. databases or SCM repositories are only
meaningfull, if they are in consistent state, which means backed up at
the very same time.
Supported by ARCHIVE or SELECTIVE.

6) legal reasons
require us to keep some of file systems restorable in original state for
couple of years (mostly in the state of the last month.s day).

7) long term protection of development environment :
again, bcause of guarantee reasons,
and because of need to be able to develop again on old pieces of code
with old tools,
we have to restore development envioronment in same state as it was at





the time the project was written. This time point can go couple of years
back.
Not supported by INCREMENTA (at least not realistic). With exeptions
supported by ARCHIVE.


8) convenience:
most users have no idea of ADSM design, no interess in underlying
technology and no budget and willingness to learn it. But they know since
years their sysadmin regulary saved tapes  with full backups. And they
rely on this behaviour.
Not supported by INCREMENTAL.


regards,
Juraj Salak

--- Message part 1.2: PCDATA --------------------------------------
 ==> Message part  1.2 is a PCDATA file that has been sent separately.
 ==> Message part  1.2 is a PCDATA file that has been sent separately.
 ==> Subject:       Re: Full backup whit client NT

 ==> Document Name:
<Prev in Thread] Current Thread [Next in Thread>