Monthly Archives: April 2008

We are Paid to Backup not Restore

Published April 20, 2008 | by Jaspreet | in Data Protection, Technology & Innovation
1

“We are paid to Backup not Restore … “, this was the company slogan at my last job.

And the team really followed it well, seriously. Look at the existing backup solutions, they have tons of options for backup and most of these options are derived for pre-historic tape-based backups. In fact most of the solutions confuse backup with archival. Take a look at following backups options -

  1. Backup Rule Engines
  2. Complicated Scheduling and archival times
  3. Naming a backup or scheme or snapshots

But, there are hardly any options for restore :-? , besides they hardly even work :(

I guess restores can be made much better, with options like -

  1. Self-serve, web based restore.
  2. Give and option to restore just a part of backup.
  3. Search a file in Restore.
  4. Restore based on Timeline. ( Choose a date and restore based on that date. )
  5. Support compression for faster restores (just like backups).

With Druvaa inSync we tried to address most these issues. Now with upcoming 2.0 we plan to add file-searching and time-line based restores.

So, how fast is inSync really ?

Published April 18, 2008 | by Jaspreet | in Data Protection, Druva inSync, Products
4

We still couldn’t figure out what makes the traditional backups so slow and resource hungry.

But, we benchmarked insync against normal network copy using a HP dual core machine configured for 50 users. Here are the results -

You can download the PDF (117KB) and other related documents from http://www.druvaa.com/download/insync.html

Should the results differ for a larger set of users ? Looks difficult, but would soon try and publish (upcoming) version 2.0 benchmarks with larger set of users.

- Jaspreet

Painpoints with Traditional Backup

Published April 16, 2008 | by Jaspreet | in Technology & Innovation
1

Backup is a necessary evil. At Druvaa, our goal is to get rid of the evil part of backup. The first step in that process is to find out the pain points of traditional backup.

  • Backup schedules: Traditionally, a backup is a scheduled process that runs at fixed intervals. In case of a failure, the data updates since the last backup are lost. The recovery point objective (RPO) is weaker with traditional backup. Refer to Understanding RPO and RTO for a discussion on RPO.

  • Backup slots: Traditional backup process is resource heavy. Also, the server appplication needs to be quisced to get a consistent backup image. This implies that the regular server activity cannot continue during backup. Hence, backup is schduled to run during a timeslot when the regular application activity is not present or is present at a lower scale. As the amount of data and the time to backup grows, it becomes harder to find time-slots for scheduling backup. The increase in the number of business hours also puts additional pressure on the backup slots.

  • User interface: Traditional backup interface is complex due to the concepts of full/incremental backups and schedules. Due to the coplexity of the user interface, it becomes harder to let the end user control the backup process. Typically, the administrator configures the backup for enduser desktop/laptop. The configuration remains static and cannot easily adapt to dynamic data layout. Instead, the end user is asked to arrange his/her data to suit the backup configuration.

  • Backup media: Traditional backup is performed on media like magnetic tapes or optical disks. Complete automation (using robotic media libraries) of the backup process is too costly. In absence of an automated process, an administrative attention is required to manage the backup media. Maintaining the backup media also requires administrative effort. The restore operation also requires administrative attention because the right backup media needs to be loaded.

  • Special hardware: Tradional backup is performed using media like magnetic tapes that require special hardware like tape drives. Special hardware means additional procurenement and maintenance cost.

  • Restore operation: With traditional backup, the end user cannot restore her files by herself. Typically, a service request is sent to the administrator, thus increasing the time taken for restore. The recovery time objective (RTO) is weaker with traditional backup. Refer to Understanding RPO and RTO for a discussion on RTO.

In the next post, I’ll discuss possible approaches to address the painpoints of traditional backup.