LTO Program Frequently Asked Questions

http://www.lto.org/About/faq.html

Use Robocopy for backup

robocopy <sourse> <destination> /e /mir /np /tee /mt:4 /log:backup_log.txt
robocopy <sourse> <destination> /e /mir /np /z /tee /mt /log+:backup_log.txt
pause

/e = copy all sub-folders, even empty ones
/mir = mirror (check the files in the destination, and only copy newer files)
/np = no progress counter
/log: = create a logfile
/log+: = This option ensures that the results of the 2nd and 3rd ROBOCOPY are appended to the log file created in the 1st ROBOCOPY line.
/tee = Output from ROBOCOPY written to both the log file and the cmd window.
/mt = ROBOCOPY also has the ability to perform faster multi-threaded copying by simply using the option /mt. I can choose the number of threads to use by specifying a number between 1 and 128 after the /mt option, or if I just specify /mt without a number then the it will use 8 threads by default. In the example below, I use 4 threads to copy to my USB drive, and 8 threads (no number) to copy to my network drive.
/z = This option implements a "retry" for the copying. If I were part way through the copying process, and I lost connection with the network, then ROBOCOPY would automatically restart the copying at the point of failure once the network connection was re-established.

#################################################################################################
WARNIG : Use the /MIR option with caution - it has the ability to delete a file from both the source and destination under certain conditions. This typically occurs if a file/folder in the destination has been deleted, causing ROBOCOPY to mirror the source to the destination. The result is that the same files in the source folder are also deleted. To avoid this situation, never delete any files/folders from the destination - delete them from the source, and then run the backup to mirror the destination to the source.
#################################################################################################

For more details

SQL differential backup and restore

A differential backup creates a copy of all the pages in a database modified after the last database backup. Differential logs are used primarily in heavily used systems where a failed database must be brought back online quickly. Differential backups are smaller than full database backups; therefore, they have less of an effect on the system while they run.

For example, a site executes a full database backup on Sunday night. A set of transaction log backups is made every four hours during the day, with the backups from one day overwriting the backups from the day before. Each night the site makes a differential backup. If one of the data disks for the database fails at 9:12 A.M. on Thursday, the site can:

1. Back up the current transaction log.
2. Restore the database backup from Sunday night.
3. Restore the differential backup from Wednesday night to roll the database forward to that point.
4. Restore the transaction log backups from 4:00 A.M. and 8:00 A.M. to roll the database forward to 8:00 A.M.
5. Restore the log backup taken after the failure. This will roll the database forward to the time of the failure.

Consider using differential database backups when:

• Only a relatively small portion of the data in the database has changed since the last database backup. Differential database backups are particularly effective if the same data is modified many times.
• You are using the Simple Recovery model and want more frequent backups, but don't want to do frequent full database backups.
• You are using the Full or Bulk-Logged Recovery model and want to minimize the time it takes to roll forward transaction log backups when restoring a database.

A recommended process for implementing differential database backups is:

1. Create regular database backups.
2. Create a differential database backup periodically between database backups, such as every four hours or more for highly active systems.
3. If using Full or Bulk-Logged Recovery, create transaction log backups more frequently than differential database backups, such as every 30 minutes.

The sequence for restoring differential database backups is:

1. Restore the most recent database backup.
2. Restore the last differential database backup.
3. Apply all transaction log backups created after the last differential database backup was created if you use Full or Bulk-Logged Recovery.

Reducing Recovery Time

Using database, differential database, and transaction log backups together can reduce the amount of time it takes to restore a database back to any point in time after the database backup was created. Additionally, creating both differential database and transaction log backups can increase the robustness of a backup in the event that either a transaction log backup or differential database backup becomes unavailable, for example, due to media failure.

Typical backup procedures using database, differential database, and transaction log backups create database backups at longer intervals, differential database backups at medium intervals, and transaction log backups at shorter intervals. For example, create database backups weekly, differential database backups one or more times per day, and transaction log backups every ten minutes.

If a database needs to be recovered to the point of failure, for example, due to a system failure:

1. Back up the currently active transaction log. This operation will fail if the transaction log has been damaged.
2. Restore the last database backup created.
3. Restore the last differential backup created since the database backup was created.
4. Apply all transaction log backups, in sequence, created after the last differential backup was created, finishing with the transaction log backup created in Step 1.

Note  If the active transaction log cannot be backed up, it is possible to restore the database only to the point when the last transaction log backup was created. Changes made to the database since the last transaction log backup are lost and must be redone manually.

By using differential database and transaction log backups together to restore a database to the point of failure, the time taken to restore a database is reduced because only the transaction log backups created since the last differential database backup was created need to be applied. If a differential database backup was not created, then all the transaction log backups created since the database was backed up need to be applied.

For example, a mission-critical database system requires that a database backup is created each night at midnight, a differential database backup is created on the hour, Monday through Saturday, and transaction log backups are created every 10 minutes throughout the day. If the database needs to be restored to its state at 5:19 A.M. on Wednesday:

1. Restore the database backup created on Tuesday night.
2. Restore the differential database backup created at 5:00 A.M. on Wednesday.
3. Apply the transaction log backup created at 5:10 A.M. on Wednesday.
4. Apply the transaction log backup created at 5:20 A.M. on Wednesday, specifying that the recovery process only applies transactions that occurred before 5:19 A.M.

Alternatively, if the database needs to be restored to its state at 3:04 A.M. on Thursday, but the differential database backup created at 3:00 A.M. on Thursday is unavailable:

1. Restore the database backup created on Wednesday night.
2. Restore the differential database backup created at 2:00 A.M. on Thursday.
3. Apply all the transaction log backups created from 2:10 A.M. to 3:00 A.M. on Thursday.
4. Apply the transaction log backup created at 3:10 A.M. on Thursday, specifying that the recovery process only applies transactions that occurred before 3:04 A.M.

Backup Strategy while using De-duplication

Ever since the rise of deduplication, backup designs have become somewhat sloppy. Many backup deduplication appliance vendors encourage the use of full backups since that practice makes their deduplication ratios look better. It also simplifies the communication between the software and hardware; necessary because of the lack of integration. Compare these designs to the designs of the pre-deduplication era of backup software where backups were carefully architected to balance the amount of data that needed to be transferred with the available backup window and the available bandwidth. Does good backup design still have a place in the modern era of backup technology or has deduplication eliminated the need for good design?

The Similarities of Incremental Backup and Deduplication

Deduplication achieves its efficiency by comparing segments of new data being received with segments of data that is already stored. If that data is the same, instead of storing it an additional time, a link is established to the original segment. Incremental backups reduce data footprint as well. They do this by only sending data that has changed since the last backup has been executed. While similarities within the file will cause redundancy, incremental backups still reduce the amount of backup storage required by only storing changed files.

Both incremental backup and deduplication attempt to create the same result, a reduction in the amount of storage needed by the backup process. Repeated full backups store a net new image every time the same backup job is run. The problem is that with full backups most of the data between backup iterations hasn’t changed, so as a result, much of this data backed up in a ‘full’ is redundant. Deduplication remedies this problem by identifying the redundant data segments and establishing pointers to the original data set, but it does however, still send all the data across the network and requires the deduplication engine to process and compare this entire set of inbound data. Incremental backups remedy this problem by only sending the files that have actually changed. But they do not identify redundancies within those files or within the data that is already on the backup target.

The Differences between Incremental Backup and Deduplication

There are two key differences between incremental backups and deduplicated full backups. The first is the amount of data transferred across the network to the backup server or appliance. With incremental backups only the files that have changed since the last backup need to be sent, comprising a fraction of the data compared to a full backup. Many deduplication methods are ‘target side’, meaning the deduplication engine resides on the storage system. Since the data reduction benefit of deduplication doesn’t occur until the backup has been processed by the deduplication engine all the data in that full backup must be sent across the network to the backup target. There is a technology called source side deduplication, a method in which the deduplication engine resides in the software agent that’s run on the servers to be backed up (the clients). By performing data comparisons before sending unique segments to the backup server, the source-side method reduces the amount of data that must cross the network. But there are issues with its impact on the client being backed up, while the deduplication comparisons are being made. The backup agent on the host must "check in" with the main repository to confirm each segment’s redundancy. This happens millions of times each backup job and can significantly reduce processor performance on that host. There are also challenges with integrating source side deduplication into application API sets to make sure that a clean backup is performed.

Incremental backups represent a way to reduce network traffic without the burden of source side deduplication. If they can be combined with target side deduplication this could represent the best balance of performance and minimal client impact.

The second difference is the size of the backup database. The role of the database is to provide a simpler restore process by leveraging the database to provide a browsable point and click restore. Even if repeated full backups are being stored efficiently with deduplication, each of the files being backed up is logged into the backup application’s database every backup iteration. As any backup administrator will tell you the size of the backup meta data store can become very large and unwieldy. Every so often something needs to be purged from that database to keep the size in check and to prevent corruption or performance issues. Depending on the backup application this can have varying effects on the ability of the backup administrator to recover data. Typically all the data can still be recovered, it just becomes much more difficult to find the needed files since they’re no longer in the primary backup database.

Incremental backups don't cause this same problem because only the files that change are being backed up. This keeps new entries in the database to a minimum which means a longer period of time where a point and click type of restore can be achieved.

Breaking The Myth of Incremental Backup - Slow Recoveries

Despite those issues with full backups they have always been the most appealing way to backup data. If you could do a full backup and still meet your backup window, you often did it. There is a certain comfort in knowing that all the data has been protected and is stored together. This was especially true in the era of tape-only backups. If there was a disk failure the backup administrator did not want to wait for the tape library to mount tapes 20 or 30 times for the backup applications to pull all the various versions of the different files. With disk based backup though, the problem of waiting for tape mounts during an incremental restore goes away. There is no media handling, the backup application can move to another incremental backup set as quickly as you can change directories.

Deduplication and Incremental Backup - Better Together

In reality this should not be an ‘either/or’ discussion, regarding incremental backups and  deduplication. The ideal situation is an incremental backup combined with deduplication. As stated earlier, even though an incremental backs up only changed files, it does backup the whole file. If that file happens to be a 200GB database and the design is to run a month’s worth of incremental backups, one each night, you’ll create 30 copies of that database. Basically a full backup of a database and an incremental (as long as you are not using the incremental backup capabilities of the database) are the same thing, since even small in the database will trigger an incremental, which backs up the entire file. However when those copies are received by the backup server with target side deduplication the redundancy between the files are found and eliminated, saving disk backup target space.

The rest of the environment is going to be made up mostly of files that are unchanging. With either form of deduplication you are performing the extra work of identifying redundancies in files that we already know are 80% or greater likely to be redundent. Why not just eliminate them all together with an incremental. Doing a system wide incremental to deduplicated disk solves the rest of the backup problem by eliminating the need to send these files to the deduplication device and ever needing to do a comparison. Deduplication then eliminates the redundancy between the incremental jobs. From the previous example, the 30 copies of the database for the most part would see significant reduction since databases don’t change much between iterations. Also if the backup jobs are directed to a disk based, deduplication aware backup appliance then restores from incremental backup jobs would be just as fast as restores from a full backup.

Better Than Source Side Deduplication?

Target side deduplication and incremental backups could be an even better solution than source side deduplication. While source side deduplication sounds good in theory, in practice it can be problematic. Aside from the issues mentioned earlier about redundancy verification between the client and backup server, source side deduplication has issues with backing up large single files, like databases in particular, because of this verify time. The method to determine if a file has changed is already built into most modern operating systems and may not require the addition of a complex agent to perform that function. Additionally the combination of incremental backup with deduplication gives much of the network bandwidth gains and all of the back up storage efficiency gains.

Deduplication Where You Need It Most

Where deduplication is most beneficial beyond just saving disk storage capacity is when the backup needs to be replicated to a cloud storage area or to a remote office. Then every ounce of redundant data that can be eliminated is worth the extra time to process since WAN bandwidth is so precious. Deduplication is the key enabler to off site vaulting of backups.

Summary

The key is to integrate the deduplication process with the incremental backup process so that the backup application has full knowledge of how data is being transferred to it and how data is being stored. Products like the Unitrends Recovery Appliance that integrate the ability to do incremental backups, full backups, deduplication and deduplicated replication have a full understanding of not only where data is stored but also an understanding of where the best location to recover that data is in the event of a lost file or down server. Integration is a key requirement for these functions to deliver on their promise and not become a separate process to manage and worry about.

Source

Backup RTO and RPO explained

Recovery Time Objective

This is a critical metric for illustrating the risk of potential downtime.  SNIA defines the term as follows:

The maximum acceptable time period required to bring one or more applications and associated data back from an outage to a correct operational state

Thus RTO is a measure of how fast data can be recovered.  As you can imagine, there are a range of options for reducing RTO and in general, the shorter the RTO, the higher the cost.  Common solutions for RTO reduction include, disk-based backup, CDP technology and array-based snapshots.  Each of those approaches bring a benefits in RTO, but may add capital expense and operational complexity.

The other element to consider is that not all applications should be treated the same.  For example, RTO requirements on a mission-critical Oracle database are likely to be very different from those on filers holding personal data.  In the former case, a lengthy outage could dramatically impact the business while in the latter, it could cause annoyance with a minimal business impact.

When considering a solution you should look at its RTO metrics and analyze how they align with your business objectives.  Additionally, remember that RTO and product cost are often inversely related and so while a short RTO might be nice for all applications, the resulting costs may not meet your budgetary requirements.

Recovery Point Objective

RPO addresses the granularity of recovery and the frequency of backup.  SNIA defines it as follows:

The maximum acceptable time period prior to a failure or disaster during which changes to data may be lost as a consequence of recovery.

The question to ask yourself is, “how much data can I afford to lose if an outage were to occur.”  In the traditional nightly backup model, you are potentially at risk of losing up to 24 hours worth of data.  You could reduce the RPO by performing more frequent backups during the day.  Alternative approaches include CDP or snapshots.  However, these can add cost and complexity.

Like RTO, RPO requirements can vary by application.  Critical applications with large change rates may require shorter RPOs versus infrequently changing lower tier applications.  Meeting these divergent needs typically requires different approaches to creating data backups.  However, in general the more granular the RPO, the more expensive the solution.  Thus, RPO must be reviewed in the context of application criticality and budget.

Read more

Veeam FastSCP - LogonUser: (0x569): Logon failure on Windows 2008 Server

Trying to install Veeam Backup and FasctSCP on Windows 2008 Server and getting error message while configuring service account.

LogonUser: (0x569): Logon failure: the user has not been granted the requested logon type at this computer.

To solve this you will need to change the Local Security Policy of the server.

Open Local Security Policy or run secpol.msc. Navigate to Security Settigns>Local Policies>User Right Assiggment and add the account to allow 'Log on as a service' rights.

HP StorageWorks Tape Drives - Drive Cleaning Matrix

The following matrix summarizes the cleaning requirements, and/or guidelines for various members of the HP Tape Drive families. The matrix should be used in conjunction with the specific cleaning procedures and troubleshooting information provided for each type of drive operating environment, i.e. Library, Autoloader, Internal or External Standalone, Hot Plug, etc.

http://goo.gl/2qRsD

Symantec backup job status shows as "Cancel Pending" for a long time

1. Click on "Tools" > " Backup Exec Services" to open the servicesmgr.exe
2. Click on "Restart all services" (In most cases, this process will get to the bengine service and appear hung)

3. 6. Locate and highlight the following services .

    Pvlsvr.exe(Backup  exec device and media service)

    Beengine.exe(Backup exec job engine service)

    Beremote.exe(backup exec Remote Agent for Windows Server service)

5.Right Click on the above services in order and click on "End Process Tree" to terminate this process.

6.Close the task manager and return to the services manager

7.After the services are terminated in Windows-

8."Restart all services" process in the services manager should continue and complete.

LTO Ultrium Roadmap

Released Generations Include:
Generation 5
With capacity of 3 TB (assuming a 2:1 compression), the latest generation in the LTO family provides data transfer speed of up to 280 MB/s (assuming a 2:1 compression) and adds a new partitioning feature and Linerar Tape File System specification to provide enhanced file control and data management. The LTO Ultrium format generation 5 specifications were made available to licensees in January 2010.
Generation 4
Delivering 1.6TB (2:1 compression) and up to 800 GB native per cartridge, Ultrium format Generation 4 provides data transfer rates of up to 240 MB/second (2:1 compression), the LTO Ultrium format generation specification was made available to licensees in late December 2006.
Generation 3
Featuring capacities of 800 GB (2:1 compression) and up to 400 GB native per cartridge, Ultrium format Generation 3 provides data transfer rates of up to 160 MB/second (2:1 compression) for the third generation of the 8-channel version. Generation 3 licenses became available on July 26, 2004 with products appearing in late 2004.
Generation 2
With a cartridge capacity of up to 400 GB (2:1 compression) and up to 200 GB native, Ultrium format Generation 2 provides data transfer rates of up to 80 MB/second (2:1 compression). Licenses for Generation 2 became available in April 2002 with products appearing in late 2002.
Generation 1
First licensed in 1998, with product appearing in 2000, Ultrium format Generation 1 provides cartridge capacities of up to 200 GB (2:1 compression) and up to 100 GB native with data transfer rates of up to 40 MB/ second (2:1 compression).

Future Generations
Generation 6
Capacity: 8 TB (assuming a 2.5:1 compression)
Data transfer speed: up to 525 MB/s (assuming a 2.5:1 compression)
Generation 7
Capacity: 16 TB (assuming a 2.5:1 compression)
Data transfer speed: up to 788 MB/s (assuming a 2.5:1 compression)
Generation 8
Capacity: 32 TB (assuming a 2.5:1 compression)
Data transfer speed: up to 1,180 MB/s (assuming a 2.5:1 compression)

HP Ultrium Drive and LTO cartridges caring notes

Caring for HP Ultrium LTO cartridges

Under optimum environmental conditions, Hewlett-Packard LTO cartridges are currently specified to 1,000,000 passes over any part of the tape. In operational terms, this can be translated to about 2000 full backup or restore operations. Under severe environmental conditions, particularly where the tape drive is used at very low humidity or if certain areas of the tape are accessed frequently, the number of backup operations should be limited even further.

Caution: Ensure that only one label is stuck to the label area of the cartridge. Never use non-standard labels, and never stick anything to the cartridge other than in the label area.

 

Using of HP Ultrium LTO cartridges

Only use Ultrium LTO cartridges in temperatures in the tape drive's operating range from 10C to 35C (50°F to 95°F) and 20 to 80% relative humidity (noncondensing). If you expose cartridges to temperatures outside the operating limits, stabilize them before you use them. To do this, leave the cartridges in the operating environment for 24 hours.

 

Storing HP Ultrium LTO cartridges

Store cartridges at temperatures between 16°C and 32°C (61°F and 90°F ) with a relative humidity between 20% and 80%.

Always keep the cartridges in a clean environment.

Always store cartridges in their plastic cases when not in use.

 

Maximizing life of HP Ultrium LTO cartridges

Do not touch the tape surface.

Do not attempt to clean the tape path or tape guides inside the cartridge.

Do not leave cartridge tapes in excessively dry or humid conditions.

Do not leave cartridges in direct sunlight or in places where magnetic fields are present (for example, under telephones, next to monitors or near transformers).

Do not drop cartridges or handle them roughly.

Do not stick more than one label onto cartridges; extra labels can cause the cartridges to jam in the tape drive.

 

Avoiding condensation of HP Ultrium LTO cartridges

Condensation can be a problem for tape drives and cartridges. To minimize the chance of condensation, stay within the specifications for using and storing cartridges above and observe the following guidelines:

1.  Position the drive where the temperature is relatively stable -- away from open windows, heat sources and doors.

2.  Avoid leaving cartridges in severe temperature conditions, for example, in a car standing in bright sunlight.

3.  Avoid transferring data (reading from and writing to cartridges) when the temperature is changing by more than 10°C (18°F) per hour.

4.  If you bring a cold tape drive or tape cartridge into a warm room, allow time for it to warm to room temperature before using it. For example, if you have

moved the drive from a cold car to a warm room, allow time for the drive to reach room temperature (up to 24 hours if the temperature change is extreme).

 

Cleaning strategy  of HP Ultrium Drive

Ultrium drives have been developed to have a minimal cleaning requirement. The Use cleaning cartridge orange LED on the tape drive will flash when the drive needs cleaning. Only insert a cleaning cartridge into the tape drive when the light flashes.

IMPORTANT: It is essential to use only HP Ultrium cleaning cartridges with HP Surestore Ultrium tape drives. Cleaning cartridges from other media manufacturers will not be accepted by the drive. Use of HP cleaning media will ensure your tape drive is fully protected.

 

HP Ultrium LTO cleaning cartridges

You must use only HP Ultrium cleaning cartridges to clean the tape heads. A cleaning cartridge is supplied with each tape drive. Do not use swabs or other means of cleaning the heads. The cleaning cartridge uses a special tape to clean the tape heads. A cleaning cartridge can be used up to 15 times. If the cleaning cartridge is ejected immediately then it has expired or it is not an HP Ultrium cleaning cartridge. Discard it and use a new one.

 

Cleaning the tape heads on a HP Ultrium Drive

1.  Insert a cleaning cartridge into the drive. The tape drive automatically loads the cartridge and cleans the heads. During the cleaning cycle the orange 'Use Cleaning Cartridge' LED will be on and the green 'Ready' LED will flash. At the end of the cleaning cycle, the drive ejects the cartridge. The cleaning cycle can take up to 5 minutes. If the cleaning cartridge ejects immediately, it has expired or it is not an HP Ultrium cleaning cartridge. In this case, discard the cleaning cartridge and repeat the operation with a new one.

2.  Remove the cleaning cartridge from the drive.

Note: The drive's TapeAlert feature will send a message to your backup application when the tape heads need cleaning or a cleaning cartridge has expired.

HP LTO Ultrium Cartridges - Overview and Features

Exhaustively tested, HP LTO Ultrium cartridges meet all your demands for maximum reliability when restoring data, offering high storage density, ease of management and scalable storage and backup performance. Covering five generations of capacity - LTO-1 (200 GB), LTO-2 (400 GB), LTO-3 (800 GB), LTO-4 (1.6 TB) and LTO-5 (3 TB) – and with transfer speeds of up to 1 TB/hr for LTO-5, there is a platform for every need and budget. From LTO-3 onwards, LTO Ultrium WORM cartridges enable the creation of compliant, permanent and tamperproof archives. From LTO-4 onwards, secure AES-256 encryption provides even higher levels of data security and compliance with the most stringent industry regulations to prevent unauthorized data access. From LTO-5 onwards, LTO Ultrium Linear Tape File System makes using tape as easy, flexible, portable and intuitive as using other removable and sharable media, such as a USB drive.

Netapp NDMP Backup Exec job fails with errot E0008488 after installing SP4 for Backup Exec 12.5

Problem

Backups done with the Symantec Backup Exec NDMP Option fail with the below mentioned errors depending on whether the backup selections were made from the user defined selections or NDMP Server node. The backups fail only when the checkbox "Display progress indicators for backup jobs. This requires additional time to pre-scan devices." is checked under Backup Exec User Interface menu - Tools - Options – Preferences. Note that the selected data is backed up

Solution

Under the Backup Exec Graphical User Interface (GUI) - Tools - Options - Preferences, uncheck the checkbox "Display progress indicators for backup jobs. This requires additional time to pre-scan devices."

 

HP LTO Ultrium Media - Cleaning the Tape Heads on a Ultrium Drive

You must use only Ultrium cleaning cartridges to clean the tape heads. A cleaning cartridge is supplied with each tape drive.

Do not use swabs or other means of cleaning the heads. The cleaning cartridge uses a special tape to clean the tape heads.

An Ultrium universal cleaning cartridge can be used up to 50 times with HP StorageWorks Ultrium 960 and 460 tape drives and up to 15 times with HP StorageWorks Ultrium 230 and 215 tape drives. If the cartridge is ejected immediately then it has expired or it is not an Ultrium cleaning cartridge. Discard it and use a new one.

1. Insert an Ultrium universal cleaning cartridge into the drive. The tape drive automatically loads the cartridge and cleans the heads.
   During the cleaning cycle the orange 'Clean' (Ultrium 960 and 460) or 'Use Cleaning Cartridge' (Ultrium 230 and 215) LED will be on and the green 'Ready' LED will flash.
2. At the end of the cleaning cycle, the drive ejects the cartridge. The cleaning cycle can take up to 5 minutes. If the cleaning cartridge ejects immediately, it has expired or it is not an HP Ultrium cleaning cartridge. In this case, discard the cleaning cartridge and repeat the operation with a new one.
3. Remove the cleaning cartridge from the drive.
4. The drive's TapeAlert feature will send a message to your backup application when the tape heads need cleaning, or a cleaning cartridge has expired

Automate Windows Print Server backup

Backing up Windows 2003 Print Server settings using printmig.exe:

Put this exe file on your  2003 server (let's say in c:\printerbkp).Create bellow batch file and create a new scheduled task to run this.

========================

del c:\printerbkp\printers.cab.5

ren c:\printerbkp\printers.cab.4 printers.cab.5

ren c:\printerbkp\printers.cab.3 printers.cab.4

ren c:\printerbkp\printers.cab.2 printers.cab.3

ren c:\printerbkp\printers.cab.1 printers.cab.2

ren c:\printerbkp\printers.cab printers.cab.1

c:\printerbkp\printmig -b c:\printerbkp\printers.cab –i

=======================

Backing up Windows 2008 Print Server Settings:

The printmig.exe utility does not work under Windows 2008, but there is another (similar) tool that can be used to backup the printers via a script.  This tool is not available on the server by default, it only gets installed when you install the "Print Services Tools" Feature.

Create a folder to hold the backups ("c:\printerbkp"), and use the following script to perform the actual backups and create a new scheduled job for it :

====================================

del c:\printerbkp\printers.printerExport.5

ren c:\printerbkp\printers.printerExport.4 printers.printerExport.5

ren c:\printerbkp\printers.printerExport.3 printers.printerExport.4

ren c:\printerbkp\printers.printerExport.2 printers.printerExport.2

ren c:\printerbkp\printers.printerExport.1 printers.printerExport.1

ren c:\printerbkp\printers.printerExport printers.printerExport.1

%WINDIR%\System32\Spool\Tools\printbrm -B -O FORCE -F c:\printerbkp\printers.printerExport

==========================

Job warning alert "The Symantec ThreatCon Level is not up-to-date" is generated in Backup Exec 12.5

Starting from Symantec Backup Exec 12.5 the need of installing Symantec Endpoint Protection Manager (SEPM) on Media Server has been removed. Backup Exec now directly polls the Internet to get Symantec ThreatCon status. The above issue in Backup Exec is encountered even when Symantec Endpoint Protection is not installed on the Media Server.

Above issue may be encountered if there is no access to the Internet OR if there is no response/a delay in response from the Internet.

Backup Exec 12.5 stall Error - e0008821

So every once in a while one of my policy based disk to disk to tape backup jobs will just hang or stall forever. It's really nifty since it will go well beyond the auto-cancellation period - you know the ' stop job if it takes longer than x hours' checkbox. The first few times it happened I wound up having to restart the whole backup server to get the job to cancel since no amount of effort on the front end GUI would fix it. After reboot it would show the failed job with a generic error code of e0008821. I even tried restarting the server that the job status claimed it was working on at the time of the hang. After a few more tries it occurred to me that the job status was lying to me and that it may actually be trying to communicate with the next server on the backup list. So to the command prompt I went. The results of netstat -aon | more

show that the server is currently communicating with port 10000 on another server. The catch is that while the job status said it was working on server A, the netstat showed it was only talking to server B at the time. So I went to server B and restarted the backup Agent and my stalled job suddenly started proceeding again. Of course, this isn't a great long term fix but it's not unusual for backup agents to need a good kick start from time to time. It would be nice if it was better at auto-recovery...

http://gnawgnu.blogspot.com/2009/12/backup-exec-125-stall-e0008821.html

This happens because the BE software is not able to communicate with the TAPE Drive.

Resolution:
1  : Open Backup Exec Console and go to the Device TAB...
2  : Right Click on the SERVER NAME and Click on "PAUSED"
3  : Right Click and click on "PAUSED" again

Now try any utility jobs like inventory or erase.

How to copy media server configuration to a file and apply the copied media server configuration.

Copy Media Server Configuration enables a copy of the configuration information for a media server to a configuration file that can be stored on a hard disk location on a network. Using this configuration file, the media server's configuration information can be applied to other media servers with the same version of Backup Exec in an environment.

 

Configuration information that can be copied includes :

  -  Jobs, including backup, restore, and report jobs

  -  Policies, templates and selection lists

  -  Logon information

  -  Media sets

  -  Other information such as job defaults, error handling rules, alert configuration, and default schedule data.

 

Items NOT migrated:

  -  Media sets that are not currently assigned to a job

  -  Single instance jobs (jobs not scheduled and are set to run only once)

 

Apply Copied Media Server Configuration:  Enables the media server configuration information to be applied that was copied using the task Copy Media Server Configuration to other media servers in the Backup Exec environment.

 

Solution

To copy media server configuration to a file (original server):

 

1. Navigate to the Backup Exec installation directory (<local_drive>:\Program Files\Symantec\Backup Exec) and run BEUtility.exe

2. Expand Known Media Server and then expand All Media Servers to see the Backup Exec server name on the right

NOTE:  If there are no servers listed, right-click on All Media Servers > select New Media Server > enter the name of the media server and click OK

3. In the right window pane, right-click the Backup Exec media server and select Copy Media Server Configuration

4. Enter the user name (Domain\User Name ) and password with administrative rights on the Backup Exec server
5. Browse/Enter the desired location of the configuration file and click OK

6. Click Close one the Operation Progress window shows completed

 

To apply copied media server configuration (new server):

1. Navigate to the Backup Exec installation directory (<local_drive>:\Program Files\Symantec\Backup Exec) and run BEUtility.exe

2. Expand Known Media Server and then expand All Media Servers to see the Backup Exec server name on the right

NOTE:  If there are no servers listed, right-click on All Media Servers > select New Media Server > enter the name of the media server and click OK

3. In the right window pane, right-click the Backup Exec media server and select Apply copied media server configuration

4. Enter the user credentials (Domain\User Name ) and password with administrative rights on the Backup Exec server

5. Browse/Enter the location of the configuration file which is to be copied and click OK

6. Click Close one the Operation Progress window shows completed

 

How to troubleshoot the error "A failure occurred querying the Writer status" (a000fed1 HEX or e000fed1 HEX or 0xfffffed1 HEX) that occurs when a backup or restore is attempted

Problem

How to troubleshoot the error "A failure occurred querying the Writer status" (a000fed1 HEX or e000fed1 HEX or 0xfffffed1 HEX) that occurs when a backup or restore is attempted

Error

Final Error Code: a000fed1 HEX (0xa000fed1 HEX) or e000fed1 HEX (0xe000fed1 HEX)
Final Error Description: "A failure occurred querying the Writer status."
Final Error Category: Resource Errors
Error Text In Job Log: "OFO: Initialization failure on: "Shadow?Copy?Components". Advanced Open File

Solution

On Windows Server 2003, the Backup Exec Shadow Copy Components file system implements a Volume Shadow Copy Service (VSS) Requester to protect critical operating system and application service data, and third party application and user data via VSS Application Writers. A VSS Application Writer is specific code within an application that participates in the Volume Shadow Copy Service framework to provide point-in-time, recovery-consistent operating system and application data. When a data protection operation of Shadow Copy Components is performed, the status of the involved VSS Application Writers must be queried to determine its status during the backup or restore.

During a Shadow Copy Components data protection operation, if a VSS Application Writer involved in the operation reports a failed status, then the data protection operation will fail  (Figure 1).

Figure 1
 

To troubleshoot this error, please perform the following steps immediately after a failed Shadow Copy Components backup has been identified:

 

1.  Open a command prompt on the server in question
 

2.  Type the following command: VSSADMIN LIST WRITERS (Figure 2)
 

Figure 2 - VSSADMIN sample output: No Errors
 

Figure 3 - VSSADMIN sample output: Errors Detected
 

 

3.  Review the output and identify the Last Error failure status for the specific VSS Application Writer that was involved in the data protection operation (Figure 3, failed "NTDS" VSS Writer). Ensure that the writers are all showing a State of "[1] Stable" and that Last Error is showing "No error."
 

If Last Error states:
 

- Retryable Error, then retrying the data protection backup operation might resolve the VSS Application Writer's initial failure
 

- Non-Retryable Error, view the Event Viewer's Application Log for information regarding the cause and possible solution to this issue.
 

 

   4. If the VSS Application Writer failure does not reset after a period of time, Backup Exec for Windows Servers continues to fail, or the native backup utility fails, then attempt to reboot the system and contact the specific company that produced the VSS Application Writer for further assistance.
 

Note: In most cases rebooting the server has resolved such issues, in case the issue is unresolved and the Writer continues to show failed status, please refer to the Microsoft Article mention below.
 

 

For more information regarding what may cause the Shadow Copy Components to fail, please refer to the Microsoft Article KB826936.
 

5.If the issue further persists one can try update the VSS package through "http://support.microsoft.com/default.aspx?kbid=833167" but in case if Service Pack 1 for windows 2003 is already installed then it will supplement this answer ID.
 

 

6. On the Windows Servers 2003 which already have SP1 installed if this issue comes, the solution is a Microsoft hotfiix KB903234 which is mentioned in Microsoft KB913648 will be helpful in fixing this issue.
 

 

7.How the update will help in fixing the issue?
 

The update that is described in this article(KB 903234) is designed to optimize the way that the Shadow Copy Client accesses snapshots. Without this update installed, the Shadow Copy Client opens every existing shadow copy for a particular volume. After you install this update, the Shadow Copy Client searches for unique versions of a shadow copy before the Shadow Copy Client opens the shadow copy. This new behavior significantly reduces the load that the Shadow Copy Client puts on the server.
 

 

8.Corresponding links
 

http://support.microsoft.com/kb/903234/en-us
 

&
 

http://support.microsoft.com/kb/913648/en-us
 

 

Note: For UMI V-79-32775-14 please see  http://support.veritas.com/docs/278779

Manually uninstalling the Remote Agent for Linux or UNIX Servers

Manually uninstalling the Remote Agent for Linux or UNIX Servers

You can manually uninstall the Remote Agent for Linux or UNIX Servers from local and remote Linux or UNIX hosts.

To manually uninstall the Remote Agent for Linux or UNIX Servers

1. Use a terminal session to connect to the target Linux or UNIX server as the root user.

2. Change to the following directory:

/opt/VRTSralus/bin

3. Do one of the following:

For HP-UX operating systems:

Delete the following line if it is found in the /etc/inittab file: /opt/VRTSralus/bin/VRTSralus.init.

For all other supported Linux- or UNIX-based operating systems:

Continue with the next step.

4. Stop the Remote Agent daemon by typing the following command:

./VRTSralus.init stop

5. Remove the Remote Agent package from the Linux or UNIX host by typing the following command for the appropriate operating system:

IBM AIX

installp -u VRTSralus

Hewlett Packard HP-UX

swremove VRTSralus

Linux

rpm -e VRTSralus

Sun Solaris

pkgrm VRTSralus

6. Change back to the root directory by typing the following command:

cd /

7. Remove additional files by typing the following command:

rm -r /etc/VRTSralus /opt/VRTSralus /var/VRTSralus

8. Type y if you are prompted to descend into the directories.

9. Type y if you are prompted to delete a directory.

10. If you find the following run time scripts, remove them by typing the following commands for the appropriate operating system:

IBM AIX

rm /etc/rc.d/rc5.d/S95VRTSralus.init

rm /etc/rc.d/rc3.d/S95VRTSralus.init

rm /etc/rc.d/rc2.d/S95VRTSRalus.init

rm /etc/rc.d/VRTSralus.init

Hewlett Packard HP-UX

rm /sbin/rc3.d/S95VRTSralus.init

rm /sbin/rc2.d/S95VRTSralus.init

rm /sbin/init.d/VRTSralus.init

Red Hat Linux, Asianux

rm /etc/rc.d/rc5.d/S95VRTSralus.init

rm /etc/rc.d/rc3.d/S95VRTSralus.init

rm /etc/rc.d/rc2.d/S95VRTSralus.init

rm /etc/rc.d/init.d/VRTSralus.init

Novell Open Enterprise Server 1.0/ SUSE Linux Enterprise Server 9 (32-bit only)

/sbin/insserv -r /etc/init.d/VRTSralus.init,start=2,3,5

rm /etc/init.d/rc5.d/SxxVRTSralus.init

rm /etc/init.d/rc3.d/SxxVRTSralus.init

rm /etc/init.d/rc2.d/SxxVRTSralus.init

rm /etc/init.d/VRTSralus.init

Novell Open Enterprise Server 2.0/ SUSE Linux Enterprise Server 10 (32-bit and 64-bit)

/sbin/insserv -r /etc/init.d/VRTSralus.init,start=2,3,5

rm /etc/init.d/VRTSralus.init

Solaris

rm /etc/rc2.d/S95VRTSralus.init

rm /etc/rc2.d/S91VRTSralus.init

rm /etc/init.d/VRTSralus.init

Install Symantec Tape Backup Exec Agent on Linux

The following are the steps of installing Symantec Tape Backup Exec Agent on Redhat Linux operating system after which the Backup Exec application can start taking backup on Tape drives from the Redhat Linux OS file system.

1. Copy the agent gnuzipped file to the server in /tmp/symantec folder, then extract the contents,

# gunzip BEWS_12.5.2213_LINUX-UNIX-MAC-SAP_AGENTS.tar.gz
# tar -xvf BEWS_12.5.2213_LINUX-UNIX-MAC-SAP_AGENTS.tar

[root@srdodb symantec]# ls
BEWS_12.5.2213_LINUX-UNIX-MAC-SAP_AGENTS.tar
installrams.pl
RALUS64
tools uninstallrmalDOCS installrmal ralusinst.conf uninstallralus uninstallrmal.plinstallralus installrmal.pl RALUSx86 uninstallralus.cmd VxIFinstallralus.cmd messages ramsinst.conf uninstallralus.pl winntinstallralus.pl perl rmalinst.conf uninstallramsinstallrams pkgs scripts uninstallrams.pl

2. Now update the hosts file and add the tape backup server entry in it,

[root@srdodb symantec]# vi /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost.localdomain localhost::1 localhost6.localdomain6
192.168.1.82 srdodb
192.168.2.60 tapebkupsrv

3. Shutdown the database and/or other applicaitons that are not requrired at this time, and start installing the agent now

[root@srdodb symantec]# ./installralus

Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers 12.5.2213

Enter the system names separated by spaces on which to install RALUS: (srdodb.domain.local)
Checking system communication:
Checking OS version on srdodb.domain.local ....................................................... Linux 2.6.18-128.el5
Checking system support for srdodb.domain.local ............................... Linux 2.6.18-128.el5 supported by RALUS

Initial system check completed successfully.

Press [Return] to continue:
Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers 12.5.2213
installralus will install the following RALUS packages on Linux target system: srdodb.domain.local

VRTSralus Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers
Press [Return] to continue:
Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers 12.5.2213
Checking system installation requirements:
Checking RALUS installation requirements on Linux target systems: srdodb.domain.local

Checking RALUS installation requirements on srdodb.domain.local:
Checking file system space ............................................................. required space is available
Installation requirements checks completed successfully.
Press [Return] to continue: Checking for prerequistes .................... Done
Checking for Port 10000 ...................................................................... Done

Remote Agent Media Server Configuration

To display the Remote Agent as a selection in a media server's backup selection tree, and to be able to specify a local
network for use between the Remote Agent and a media server, enter the names or IP addresses of the media servers that you
want the Remote Agent to communicate with.

An IP Address: XXX.XXX.XXX.XXX A Host Name: COMPUTERNAME
Enter a directory host:192.168.2.60
Do you want to add another name or address for this agent? [y, n] (n)n

Remote Agent User Group Setup

To perform backups, you must have a 'beoper' user group. This user group can be created only if you are not using NIS server.
Your system will be scanned to detect a NIS server, group and membership.

Press [Return] to continue:
Checking if system uses NIS server: ............................................................................ No
The installer will now check your system for the 'beoper' user group and root membership.
Press [Return] to continue: Checking for 'beoper' user group: ........................................................................ Not Found

Checking for 'root' user membership in 'beoper' user group: .............................................. Not Found
You can create 'beoper' user group manually or you can choose to have it created automatically.

Do you want installer to create 'beoper' user group? [y, n] (y)

Do you want to use specific group ID when creating 'beoper' user group? [y, n] (n)

Creating group 'beoper': ...................................................................................... Done

Do you want to add the 'root' user to 'beoper' user group? [y, n] (y)
Adding 'root' user to 'beoper' user group: ................................................................... Done

Press [Return] to continue:
Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers 12.5.2213

Checking Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers on srdodb.domain.local:
Checking VRTSralus package ........................................................................... not installed

Press [Return] to continue:

Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers 12.5.2213
Installing Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers on srdodb.domain.local:

Installing VRTSralus 12.5.2213 on egdodb.qia.local ............................................... done 1 of 1 steps
Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers installation completed successfully.
Press [Return] to continue: Copying new initialization scripts .................................. Done
Creating RALUS linkedname in rc2.d ............................................................................ Done
Creating RALUS linkedname in rc3.d ............................................................................ Done
Creating RALUS linkedname in rc5.d ............................................................................ Done
Updating RALUS files for beoper .................................................................................... Done

Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers 12.5.2213

Configuring Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers:

Creating configuration files ........................................................................................ Done

Symantec Backup Exec for Windows Servers Remote Agent for Linux/Unix Servers configured successfully.

Press [Return] to continue:
The response file is saved at:
/var/tmp/vxif/installralus1223014409/installralus1223014409.response
The installralus log is saved at:
/var/tmp/vxif/installralus1223014409/installralus.log

4. To start, stop or restart the agent use the following command,

[root@egdodb init.d]# cd /etc/init.d

[root@egdodb init.d]# ls VR*

VRTSralus.init

[root@egdodb init.d]# ./VRTSralus.init status

Symantec Backup Exec Remote Agent for Linux/Unix Servers
Usage: VRTSralus.init { start stop restart }

[root@egdodb init.d]# ./VRTSralus.init stop
Stopping Symantec Backup Exec Remote Agent ...............Stopping
Symantec Backup Exec Remote Agent: [ OK ]

[root@egdodb init.d]# ./VRTSralus.init start
Starting Symantec Backup Exec Remote Agent ......Starting
Symantec Backup Exec Remote Agent: [ OK ]

5. Now finally from the Tape backup server i.e, from Symantec Backup Exec application test a new backup job by picking some files/folders to include in the tape backup. Also test the restore on linux and windows server.