K2000 Backup Best Practices (4268543)

For insurance against disaster, be that failed hardware or a failed upgrade, it is important to plan and implement a backup plan to avoid loss of data. The K2000 itself cannot be backed up but critical data (such as Images, tasks, Scripted Installs) can and should be backed up on a regular basis.

Backing up the Data consists of two tasks:

1. Exporting the data (to the \\k2000\restore share)
2. Copying the data off of the restore share to an external storage server of some type

Both of these tasks can be done manually or as scheduled jobs depending on environmental needs. Either way is fine but both ways have drawbacks to be addressed.

The main problem with running backups manually is remembering to do so on a regular basis. Since both Exports and copying the data to off site storage can take hours depending on the amount of data at hand, running them manually can be problematic. Scheduled backups also have issues such as insuring the off site storage server has room for all the data being backed up, scheduling the Export and Off site transfer jobs so they don't overlap and hang the process, and maintaining the ID/PW/address of the off site storage server.

Setting up Exports of your data:

The steps for setting up exports are detailed here:https://support.quest.com/k2000-systems-deployment-appliance/kb/115080

Even though an item is scheduled to be exported, it will not be exported unless the “Version” and the “Version backed up”  (shown on the Exports screen) are different.  The line showing the item will be either white or yellow in such a case. This is done so multiple copies of the same version are not constantly being exported into the restore share. While this does save space on the restore share, and consequently on the remote storage server, it also means the backup files should not be deleted off the storage server out of hand as the object (Image, Scripted Install, PO task, etc) will not be exported again until its version number changes. This means if an object is exported and copied to the off site storage (more on that later) and deleted from the restore share and then subsequently deleted from the off site storage for any reason, you will no longer have a backup of that object and it will not be exported again unless it is edited and saved, which increments the version number (causing the object to show up as yellow on the exports list). This means management of the off site storage server is critical to ensure needed backed up objects are not accidentally deleted because there is no easy way to instruct the K2000 to start over and export everything from the beginning.

What to export:

Do export:  ASR (MAC) Images, Kimages, Boot environments,  WIM images, Scripted Installations, Tasks, User states
Don't export (unless you know you need it ) The Database,  network inventory, and network scans
Don't export Driver folders unless you know you have something in them you will need.  Note that drivers listed here correspond to folders listed in the \\K2000\drivers share. As of K2000 version 3.5 there should be little in these folders as driver feed drivers (and manually built driver feeds) reside in \\K2000\drivers_postinstall instead of \\K2000\drivers

Things to consider:

The total size of the items to be exported and the available disk space on the K2000. Each exported object is placed in the K2000 restore share as two files: a pkg file containing the data and an xml file describing the contents of the package file. Both files must be kept together and are needed in order to restore the object) As these files are written to the restore share, their size is subtracted from the total free space of the K2000. Once the available freespace dips below 20GB many standard operations on the k2000 may begin to fail for lack of space to complete. Therefore it is critical that the total size of the exported objects does not exceed the available free space (minus the 20GB of reserve space needed for a healthy K2000).

If the total size of the data to be backed up is greater than the available free space, then would be a good idea to break the export/off board transfer into 4 tasks (2 export/transfer pairs) and run them at different times of the week. This would require the “Clean up Restore” (see below) box to be checked on the Off-Board transfer set up page.

It is critical that enough time be allowed between the export job and the transfer task to ensure the exports complete before the transfer task starts in order to avoid hanging the transfer task which requires a Level 3 ticket to fix. To that end it is recommended leaving 24 hours between the time you expect the export task to complete and the start of the transfer task. This gives a safety margin so a slow export task will not collide with the transfer task.

Setting up Off-Board Package Transfer for exported objects:

The steps for setting up the off-board package transfer are detailed here:https://support.quest.com/k2000-systems-deployment-appliance/kb/115080

Things to consider:

The Off-board storage server must have sufficient size (in terms of disk space) for the ID used to contain all the data on the K2000. In fact it should have much more free space than the total data as multiple version of a task should be backed up in case an object needs to be reverted to an older version for some reason.

How much impact will pushing the backup data have on the available network band width and what other resources might that impact. If the Off-board storage server is used for other applications will they impact the transfer duration or will they suffer detrimental effects during the transfer process.

On the Off-board package transfer set up page, if the “Clean up Restore” box is checked, after each object is copied to the remote storage server (Off-Board server) it will be deleted from the K2000 restore share freeing up needed space on the disk. Using this option is a great way to save space on the K2000 but requires careful management of the files stored on the Off-Board storage server to avoid deletion of needed backups.

How often one needs to back up is directly dependent on the amount of changes made to the K2000 data over time. Most find a weekly backup is sufficient but its solely a function of the environment you have and the risk you are willing to assume.   Most people start the exports on Friday nights and the off board transfer sunday morning (2am ) but again this depends on your environment.

If you choose to set up automatic Exports/Off-Board transfer keep in mind you may from time to time need to back things up manually as need arises.