• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 332
  • Last Modified:

incremental backup restore

experts out there , I have  a question on incremental backup related to a file not data.
my understanding is that incremental backup capture the changes from previous day and backup the file not the change data inside the file .For an example
I have a file1 , the changes on this file takes place everyday .
my backup schedules run on Sunday the full backup  and rest of the days are incremental backup.
so the backup software back this file everyday , this case i pick the last day and restore it if i need to recover.
Am i correct on this?
if it is more than one files (mass restore) then i can go from last day restore but not to overwrite,that is, Friday restore and tell not to overwrite. Thursday tell not to overwrite etc go to full backup last.

or restore the full backup first then monday tell the backup to overwrite, Tuesday tell the backup to overwrite and so on.
3 Solutions
David AtkinIT ProfessionalCommented:

Yes an incremental backup will only backup the files that have changed since the last  incremental backup.  If you have a problem with the file then you would restore it from your last available backup. If as you say, the file changes every day and the last backup was done yesterday then you should be able to restore from the previous day.

I don'y fully understand the second part of your question about the overwriting.  Can you confirm what you mean please?

What backup software are you using our of interest?
Somewhat off topic and thinking laterally:

Depending on the volume of data, it may make more sense to do a full backup/synchronisation every day.
This eliminates the hastle of incremental restoring.

You could rotate backup disks every day of the week,
or use a program that always keeps a full backup of a chosen number of days.

For example ....
I keep all development work in a particular group of folders.
I use KLS Backup (http://www.kls-soft.com/main/index.php) to keep full backups for the past 10 days.
These are kept/created in 10 individual zip files.
Each day when a new backup is created the oldest zip file is automatically wiped.
Restoring data is a doddle using this method.

During intense developing periods, you could have hourly backups.
A restore from full + incremental backups normally requires you first restore the last full backup, then you restore each of the incremental backups in between that full and the day you want to restore to.  This can be a lot of work and time.

Instead, there is a scheme called differential backups, wherein you take a full backup, and when you take your daily backups after that, you don't reset the archive bit -- so each differential backs up all the files that have changed since the last full -- so you only need to restore from at most the full, and one differential.  The penalty is that a differential backup will likely take up some amount more space than an incremental.

If this particular file (or directory) is important to you, there's no reason you can't run a daily full backup of just that file/directory, appending it to the incremental job that backs up the rest of your server.  Some backup programs make this easy, and some make it more difficult -- but it is possible, and means that you only need the latest tape for a restore of the key file.

Your question, "my backup schedules run on Sunday the full backup  and rest of the days are incremental backup.
so the backup software back this file everyday , this case i pick the last day and restore it if i need to recover.
Am i correct on this?" concerns me.  It sounds like you've never done a test restore.  If that is correct, your system and data are in danger.  If you haven't tested your restores, you don't know if you *can* restore.  In addition, it's a fact of human nature that doing things under pressure leads to mistakes.  Unless you understand the restore process before you need to use it, the chances of you making a mistake -- and possibly wiping out your backup, or overwriting key data with a wrong, older version -- is high.   Use your backup application and test your restores -- setting a different restore/output directory so that you can be sure you've gotten the right file without overwriting the current "good" one by mistake.

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now