As data recovery from voice logging system becomes more widespread, we examine the history of voice logging systems.

Voice logging data recovery...

The necessity for the commercial logging of voice communications from telephone lines dates back to the early 1950's although there is evidence of patents for telephone answering and recording devices as early as 1903. The original commercial voice logging devices utilized analog magnetic tape as the recording media. The spools of 1/4” reel to reel tape were 10 1/2” in diameter and mounted on very large stable tape decks.

It is believed the earliest use for these cumbersome devices was used by both military and commercial logging of voice data for air traffic control. Although Magnasync Corporation were one of the early commercial manufactures of these devices the British company Racal became a market leader in voice logging. Racal Recorders designed and manufactured the voice logging systems and Racal Zonal the magnetic tape. Again these early magnetic tape voice logging systems utilized 1/4” magnetic tape on reel to reel spools. Both 1/2” and 1” tape was also used. These wider tapes allowed up to 64 simultaneous tracks of voice to be logged using analog recording techniques.

After our client’s mail server stored on a RAID-5 was maliciously damaged by one of their employees, we were instructed by their solicitor to conduct a full forensic examination of the evidence. It was suspected that the server’s hard drives were concealing inappropriate correspondence. The hard drives had been removed and the circuit boards, physically destroyed. To exasperate the situation, backups had been securely erased and could not be retrieved.

Our technicians removed the RAID server from site to ensure preservation of the evidence. Before acquisition and analysis could begin, it was necessary to render the hard drives serviceable in order to take an exact sector level duplicate. We are one of the few computer forensic experts that also specialise in data recovery. The hard drives were dismantled in our clean room and rebuilt using donor parts.

We were then asked to establish whether or not there was sufficient evidence to show that activity was performed during a seven day window and whether the evidence of this activity had been forensically wiped (in addition to physical destruction of the hard disk drives in the RAID). Our data recovery engineers then imaged all the repaired hard drives in the RAID array, taking care to maintain the integrity of the evidence and adhering to Association of Police Chief Officers (ACPO) guidelines at all times.

Thankfully there was no media damage to the platters and we were able to image the drives without error. The acquired images were verified using hash functions and the data parameters calculated in order to rebuild the data on the server.

In our many years of experience in the data recovery sector, we have heard many stories about customers attempting to recover their lost data by themselves.

Note: some software-based data losses are very easily recoverable using a reputable data recovery software package, like Ontrack EasyRecovery. The data loss issues that we are referring to here are related to physical failures.

We collected the most common ones, and here you can read what you shouldn’t do in order to recover your data.

1. Leave your hard drive in the freezer

There is an urban legend that says that leaving your hard drive in the freezer or refrigerator will fix it. This is not true at all. By doing this the only thing that you will achieve is a frozen and broken hard drive.

2. Restart the computer many times

When the computer is not working properly, and makes unusual noises many people restart several times. By doing this they believe the problem will repair itself. The best thing to do in this situation if you are unsure what happened to your hard drive, we recommend you to switch it off and call a reputable computer repair or data recovery company.

When a Windows SQL Server database is faulty, you can restore files in the database using backup images.

Prerequisites

• The SQL Server master database is intact, and the SQL Server can be started correctly.
• The full virtual machine has been backed up at least once.

Context

Procedure

1. Log in as user Administrator to the virtual machine.
2. Choose Start > All Programs > Symantec NetBackup > NetBackup Agents > NetBackup MS SQL Client.
The NetBackup Database Extension - Graphical User Interface page is displayed.
3. Browse to find SQL Server backup images.
1. Choose File > Restore SQL Server Objects.
The Backup History Options dialog box is displayed.
2. Select the SQL host whose backup images you want to browse. Select the date range.
• Select or enter the name of the virtual machine host in SQL Host.
• In Source Client, keep the default value or type the source client name. Keep the default value same as SQL Host as an example.
• In the Time filter area, set the start and end dates of browsing for backup images.
3. Click OK.
The Restore Microsoft SQL Server Object dialog box is displayed.
4. Click the plus sign (+) to expand the instance and database to be recovered.
4. Select the VMware backup image of the database that you want to recover.
indicates the VMware backup image of a database.
5. In the Restore options area, set Scripting to Restore selected object. Click Restore.
The NetBackup Database Extension dialog box is displayed.
6. Click Yes to start the restore.
The NetBackup Database Extension dialog box is displayed indicating that the SQL Server database is being recovered.
7. Click OK.

Overview

Reading the SQL Server and SQL Server Agent errorlog files from time to time is a good idea. You can find errors that shouldn't be there. You can find messages that indicates misconfiguration. Or security issues. Also, to know the frequency for some messages can be valuable. The problem is that nobody wants to open a text file with thousands and thousands of messages and read through it.

There are of course tools and software out there to help with this, but sometimes nothing beats actually looking at the errorlog file. Every time I have look in an error file on a production server, I find surprising messages. This is regardless of whatever monitoring software is in place. Every time.

When going through an errorlog file, we want to make sure we catch the serious errors and other unexpected messages. We also quickly want to discard messages that we aren't interested in. And you don't want to spend more than about 30 minutes per SQL Server the first time you go through its errorlog files. Over time, you probably trim things so this process is just a few minutes. Here you find how I handle these things.