Archive for August 19, 2011

Keys and values in Registry

Posted: August 19, 2011 in Active Directory, Registry, Server 2008
Tags: , , ,
0

Keys serve as containers in the registry. Keys can contain other keys (subkeys). Keys can also contain value entries, or simply, values. These are the ‘‘substance’’ of the registry. Values comprise three parts: name, data type, and value. The name identifies the setting. The data type describes the item’s data format. The value is the actual data. The following list summarizes data types currently defined and used by the system:

 

  • Binary Value: This data type stores the data in raw binary format, one value per entry. The Registry Editor displays this data type using hexadecimal format.
  • DWORD value: This data type stores data as a four-byte number (32-bit), one value per entry. The Registry Editor can display this data type in binary, hexadecimal, or decimal formats.
  • QWORD value: This data type stores data as a 64-bit number, one value per entry. The Registry Editor can display this data type in binary, hexadecimal, or decimal formats.
  • Expandable string value: This is a variable-length string that includes variables that are expanded when the data is read by a program, service, and so on. The variables are represented by % signs; an example is the use of the %systemroot% variable to identify the root location of the Windows Server 2008 folder, such as a path entry to a file stored in systemroot\System32. One value is allowed per entry.
  • Multi-String value: This data type stores multiple string values in a single entry. String values within an item are separated by spaces, commas, or other such delimiters.
  • String value: This data type stores a single, fixed-length string, and is the most common data type used in the registry.
Advertisement

What is a backup?

Posted: August 19, 2011 in Active Directory, Backup, Server, Server 2003, Server 2008, System Information
Tags: , , , ,
2

A backup is an exact copy of a file (including documentation) that is kept on a storage medium (usually in a compressed state) in a safe place (usually at a remote location) for use in the event that the working copy is destroyed. Notice that we placed emphasis on “including documentation”, because every media holding backups must include a history or documentation of the files on the media. This is usually in the form of labels and identification data on the media itself, on the outside casing, and in spreadsheets, hard catalogs, or data ledgers in some form or another. Without history data, restore media cannot locate your files, and the backup is useless. This is why you can prepare a tape for overwriting by merely formatting the label so that the magnetic head thinks the media is blank.

 

Various types of backups are possible, depending on what you back up and how often you back it up, as the following list describes:

  • Archived backup: A backup that documents (in header files, labels, and backup records) the state of the archive bit at the time of copy. The state (on-off) of the bit indicates to the backup software that the file has been changed since the last backup. When Windows Server 2008 Backup does an archived backup, it sets the archive bit accordingly.

 

  • Copy backup: An ad hoc “raw” copy that ignores the archive bit state. It does not set the archive bit after the copy. A copy backup is useful for quick copies between DR processes and rotations or to pull an “annual” during the monthly rotation

 

  • Daily backup: This does not form part of any rotation scheme. It is just a backup of files that have been changed on the day of the backup. We question the usefulness of the daily backup in Backup, because mission-critical DR practice dictates the deployment of a manual or automated rotation scheme. In addition, Backup does not offer a summary or history of the files that have changed during the day

 

  • Normal backup: A complete backup of all files (that can be backed up), period. The term normal is more a Windows Server 2008 term, because this backup is more commonly called a full backup in DR circles. The full backup copies all files and then sets the archive bit to indicate (to Backup) that the files have been backed up. You would do a full backup at the start of any backup scheme. You would also need to do a full backup after making changes to any scheme. A full backup, and documentation or history drawn from it, is the only means of performing later incremental backups. Otherwise, the system would not know what has or has not changed since the last backup.

 

  • Incremental backup: A backup of all files that have changed since the last full or incremental backup. The backup software sets the archive bit, which thereby denotes that the files have been backed up. Under a rotation scheme, a full restore would require you to have all the incremental media used in the media pool, all the way back to the first media, which contains the full backup. You would then have the media containing all the files that have changed (and versions thereof) at the time of the last backup.

 

  • Differential backup: This works exactly like the incremental, except that it does not do anything to the archive bit. In other words, it does not mark the files as having been backed up. When the system comes around to do a differential backup, it compares the files to be backed up with the original catalog. Differential backups are best done on a weekly basis, along with a full, or normal, backup, to keep differentials comparing against recently backed up files.