Jim,
Have you tried to create a cluster resource for the shared disk? The scheduler
service will then failover with the disk and you will not need to manually
start it every time there is a change in cluster node ownership.
At a high level:
In addition to what you have already done.
Use
Создай 3 пула:
- дисковый для стл (на пару гигабайт)
- ленточный
- контейнерный
И направь туда данные в соответствии с тестами.
Стл можно не перенсьраивать т.е при копировании в контейнер пусть будет тем же.
С уважением,
Ефим
> 29 авг. 2018 г., в 10:08, Loon, Eric van (ITOPT3) - KLM
>
Yea, we use the replication approach for many of our machines to an offsite DR
facility too.
But they had to learn the hard way that it may good for recovery it doesn't
address their need for having historical options of recovery, so backups I was
asked to reinitiate the backups.
For some
Hi Zoltan,
In that case prepare yourself to be stuck on 7.1.7 forever. I have had a
meeting with some developers about the new security implementation and made
some suggestions for code changes. One of them was the ability to set an admin
to transitional permanently because they tend to move
Rick,
Thank you for the notes. My company collapsed both cluster servers into a
single VM that is replicated via some vSphere magic to out alternate data
center for resurrection during a DR. I currently have no cluster backups. I
was providing notes on my TSM v5 cluster backup configuration
Eric,
I fully agree and can appreciate the dilemma. We did some quick testing of
8.1.2 on a test server and it locked up one of our admin account when going
back to 7.1.7x so we setup duplicate/test admin ids. As I mentioned, we
can't even think about going forwards until we stop using the web
