Information Systems:Backup Server - Revision history

Aaront at 15:57, 16 October 2019

2019-10-16T15:57:54Z

Norwinu at 16:22, 10 October 2019

2019-10-10T16:22:34Z

Darrenf at 16:48, 4 April 2019

2019-04-04T16:48:52Z

Darrenf: /* Future considerations */

2016-11-09T18:30:55Z

Future considerations

Norwinu at 18:56, 15 July 2016

2016-07-15T18:56:43Z

Norwinu at 18:56, 15 July 2016

2016-07-15T18:56:27Z

Norwinu at 18:46, 15 July 2016

2016-07-15T18:46:00Z

Norwinu at 18:44, 15 July 2016

2016-07-15T18:44:38Z

Norwinu at 18:40, 15 July 2016

2016-07-15T18:40:22Z

Darrenf at 18:03, 15 July 2016

2016-07-15T18:03:45Z

← Older revision		Revision as of 15:57, 16 October 2019
Line 34:		Line 34:
	[[Category: IBM System x Servers]]		[[Category: IBM System x Servers]]
	[[Category: Backups]]		[[Category: Backups]]
		+
		+
		+	==ERRORS/FAILED BACKUPS==
		+	If a backup fails , at this time using the backupexec software IT must go into the software and push forward the next backup. The backups become hung until the appropriate drive tape is inserted, this is important on holidays and general failures. Always check the schedule to make sure the next backup will occur.

@@ Line 1: / Line 1: @@
-=History and overview=
+==History and overview==
 The Backup server is an IBM System x3550 originally purchased in the summer of 2010.  The purpose and intent of the server was to house the [[Information Systems:Symantec BackupExec | Symantec BackupExec]] software and have a tape library connected to facilitate backups of all the Windows based servers in production.  To begin with, the server only had one SAS controller card for the tape library.  The controller card then had a "SAS Splitter" that broke out into two connections, one for each tape drive in the library.  This proved unworkable and the splitter was traded back to the reseller for a second SAS controller card that was installed inside the server.  From then each tape drive had a single SAS cable connected to its own controller.  Note that the two controller cards are different models, one being 3GB and the other 6GB.
@@ Line 17: / Line 17: @@
 Do not install anti-virus software, especially Symantec anti-virus software on the Backup server.  Performance will be unusable and there are direct incompatibilities when Symantec Endpoint Protection and BackupExec are installed on the same server.  These incompatibilities remain even though Symantec divested the BackupExec product to Veritas in 2015.
-=Future considerations=
+==Future considerations==
 If uniPHARM is successful in its implementation of a VMware infrastructure, BackupExec will need to be replaced with some other software package such as Veeam.  The low quality of the technical support provided by Veritas does not justify continuing to use BackupExec especially when the hardware it is housed in is 6 years old.  The only obstacle to a wholesale change in backup software would be the ability of the replacement package to read tapes created by BackupExec.  Veritas has set an end of support date for BackupExec 15 on November 7, 2017.
-=Oh And By The Way=
+ '''Oh And By The Way'''
-The technical support contract expired for Veritas BackupExec in August of 2018.  Management decided to not renew.  If the BE16 software is having any difficulties after that date, it will be bad.
+ The technical support contract expired for Veritas BackupExec in August of 2018.  Management decided to not renew.  If the BE16 software is having any difficulties after that date, it will be bad.
 [[Category: Servers - Hardware]]

@@ Line 19: / Line 19: @@
 =Future considerations=
 If uniPHARM is successful in its implementation of a VMware infrastructure, BackupExec will need to be replaced with some other software package such as Veeam.  The low quality of the technical support provided by Veritas does not justify continuing to use BackupExec especially when the hardware it is housed in is 6 years old.  The only obstacle to a wholesale change in backup software would be the ability of the replacement package to read tapes created by BackupExec.  Veritas has set an end of support date for BackupExec 15 on November 7, 2017.
 [[Category: Servers - Hardware]]

@@ Line 18: / Line 18: @@
 =Future considerations=
-If uniPHARM is successful in its implementation of a VMware infrastructure, BackupExec will need to be replaced with some other software package such as Veeam.  The low quality of the technical support provided by Veritas does not justify continuing to use BackupExec especially when the hardware it is housed in is 6 years old.  The only obstacle to a wholesale change in backup software would be the ability of the replacement package to read tapes created by BackupExec.
+If uniPHARM is successful in its implementation of a VMware infrastructure, BackupExec will need to be replaced with some other software package such as Veeam.  The low quality of the technical support provided by Veritas does not justify continuing to use BackupExec especially when the hardware it is housed in is 6 years old.  The only obstacle to a wholesale change in backup software would be the ability of the replacement package to read tapes created by BackupExec.  Veritas has set an end of support date for BackupExec 15 on November 7, 2017.
 [[Category: Servers - Hardware]]

@@ Line 2: / Line 2: @@
 The Backup server is an IBM System x3550 originally purchased in the summer of 2010.  The purpose and intent of the server was to house the [[Information Systems:Symantec BackupExec | Symantec BackupExec]] software and have a tape library connected to facilitate backups of all the Windows based servers in production.  To begin with, the server only had one SAS controller card for the tape library.  The controller card then had a "SAS Splitter" that broke out into two connections, one for each tape drive in the library.  This proved unworkable and the splitter was traded back to the reseller for a second SAS controller card that was installed inside the server.  From then each tape drive had a single SAS cable connected to its own controller.  Note that the two controller cards are different models, one being 3GB and the other 6GB.
-The Backup server does have two 1GB NICs but only the primary is used even though both are cabled.  In some environments (hopefully ours in the future) there is either a [[Information Systems:Network Infrastructure Design|separate backup network or a VLAN]] that allows backups to be streamed without mixing in with other traffic.  As of 2016, the backups do stream over the flat network and performance is acceptable.
+The Backup server does have two 1GB NICs but only the primary is used even though both are cabled.  In some environments (hopefully ours in the future) there is either a [[Information Systems:Network Infrastructure Redesign|separate backup network or a VLAN]] that allows backups to be streamed without mixing in with other traffic.  As of 2016, the backups do stream over the flat network and performance is acceptable.
 The Backup server does not have an IMM or RSA card installed but it is connected to the Server Room KVM.

← Older revision		Revision as of 18:40, 15 July 2016
Line 1:		Line 1:
⚫	[[Category: Servers - Hardware]]
⚫	[[Category: IBM System x Servers]]
⚫	[[Category: Backups]]
−
	The Backup server is an IBM System x3550 originally purchased in the summer of 2010. The purpose and intent of the server was to house the Symantec BackupExec software and have a tape library connected to facilitate backups of all the Windows based servers in production. To begin with, the server only had one SAS controller card for the tape library. The controller card then had a "SAS Splitter" that broke out into two connections, one for each tape drive in the library. This proved unworkable and the splitter was traded back to the reseller for a second SAS controller card that was installed inside the server. From then each tape drive had a single SAS cable connected to its own controller. Note that the two controller cards are different models, one being 3GB and the other 6GB.		The Backup server is an IBM System x3550 originally purchased in the summer of 2010. The purpose and intent of the server was to house the Symantec BackupExec software and have a tape library connected to facilitate backups of all the Windows based servers in production. To begin with, the server only had one SAS controller card for the tape library. The controller card then had a "SAS Splitter" that broke out into two connections, one for each tape drive in the library. This proved unworkable and the splitter was traded back to the reseller for a second SAS controller card that was installed inside the server. From then each tape drive had a single SAS cable connected to its own controller. Note that the two controller cards are different models, one being 3GB and the other 6GB.

Line 20:		Line 16:

	If uniPHARM is successful in its implementation of a VMware infrastructure, BackupExec will need to be replaced with some other software package such as Veeam. The low quality of the technical support provided by Veritas does not justify continuing to use BackupExec especially when the hardware it is housed in is 6 years old. The only obstacle to a wholesale change in backup software would be the ability of the replacement package to read tapes created by BackupExec.		If uniPHARM is successful in its implementation of a VMware infrastructure, BackupExec will need to be replaced with some other software package such as Veeam. The low quality of the technical support provided by Veritas does not justify continuing to use BackupExec especially when the hardware it is housed in is 6 years old. The only obstacle to a wholesale change in backup software would be the ability of the replacement package to read tapes created by BackupExec.
		+
		⚫	[[Category: Servers - Hardware]]
		⚫	[[Category: IBM System x Servers]]
		⚫	[[Category: Backups]]

← Older revision		Revision as of 18:03, 15 July 2016
Line 4:		Line 4:

	The Backup server is an IBM System x3550 originally purchased in the summer of 2010. The purpose and intent of the server was to house the Symantec BackupExec software and have a tape library connected to facilitate backups of all the Windows based servers in production. To begin with, the server only had one SAS controller card for the tape library. The controller card then had a "SAS Splitter" that broke out into two connections, one for each tape drive in the library. This proved unworkable and the splitter was traded back to the reseller for a second SAS controller card that was installed inside the server. From then each tape drive had a single SAS cable connected to its own controller. Note that the two controller cards are different models, one being 3GB and the other 6GB.		The Backup server is an IBM System x3550 originally purchased in the summer of 2010. The purpose and intent of the server was to house the Symantec BackupExec software and have a tape library connected to facilitate backups of all the Windows based servers in production. To begin with, the server only had one SAS controller card for the tape library. The controller card then had a "SAS Splitter" that broke out into two connections, one for each tape drive in the library. This proved unworkable and the splitter was traded back to the reseller for a second SAS controller card that was installed inside the server. From then each tape drive had a single SAS cable connected to its own controller. Note that the two controller cards are different models, one being 3GB and the other 6GB.
		+
		+	The Backup server does have two 1GB NICs but only the primary is used even though both are cabled. In some environments (hopefully ours in the future) there is either a separate backup network or a VLAN that allows backups to be streamed without mixing in with other traffic. As of 2016, the backups do stream over the flat network and performance is acceptable.
		+
		+	The Backup server does not have an IMM or RSA card installed but it is connected to the Server Room KVM.

	The Backup server was also purchased with four large 300GB hard drives configured in a RAID5 set. The first 100GB was partitioned into the C: drive and the rest into a D:. The purpose and intent of this design was to take advantage of the deduplication technology in the BackupExec software present in 2010. The idea being that the daily backups from all the Windows servers would be streamed into the dedup database on the D: drive and then be written to tape in its deduped state. This design seemed to indicate that the amount of data written to tape would be smaller and allow for more data growth during the lifespan of the hardware. Unfortunately, it never really worked like that. The dedup software was buggy and slow and the BackupExec software wrote "hydrated" data to tape which completely undermined any value from the dedup feature. When the BackupExec license and support contract was renewed in the summer of 2011, the dedup feature was not renewed and the D: on the Backup server went unused. From then on the backup jobs streamed data from client servers directly to tape, bypassing any dedup step.		The Backup server was also purchased with four large 300GB hard drives configured in a RAID5 set. The first 100GB was partitioned into the C: drive and the rest into a D:. The purpose and intent of this design was to take advantage of the deduplication technology in the BackupExec software present in 2010. The idea being that the daily backups from all the Windows servers would be streamed into the dedup database on the D: drive and then be written to tape in its deduped state. This design seemed to indicate that the amount of data written to tape would be smaller and allow for more data growth during the lifespan of the hardware. Unfortunately, it never really worked like that. The dedup software was buggy and slow and the BackupExec software wrote "hydrated" data to tape which completely undermined any value from the dedup feature. When the BackupExec license and support contract was renewed in the summer of 2011, the dedup feature was not renewed and the D: on the Backup server went unused. From then on the backup jobs streamed data from client servers directly to tape, bypassing any dedup step.