Use your Computer as a Production Machine (3):
| Category: PC KNOW HOW | Date: 2002-06-27 |
MULTI-LEVEL BACKUP
Before embarking on regular backups, you should consider which backup strategy is best for you. From my own experience I recommend multi-level backup.
For a clever backup strategy you should, first of all, organize your harddisk (see preceding article of this series). In addition to that, you should consider three points:
Which of my files are the most "volatile" ones, i.e. they are modified virtually on a daily base? In other words, if I would have to restore a file from its backup, at which files would I lose the most working hours? (That is, if I cannot recur to their yesterdays state but only, say, to the state one week ago.)
What is the total backup size (in megabytes)? In other words, how much of my productive time will be occupied by the backup process?
How can I access these files (by the least coding effort, of course)? What backup medium am I going to use?
In view of these questions, I came to the conclusion that three types of files should be kept apart:
Those files at which I should be able to recur to backups that are one day old at maximum. If they were older, I would suffer a dramatic loss that could seriously impede my business. They are usually small. But they are of many different types of files (marked by the extension in the files name.) The backup process should not take more than a few minutes. Restoring individual files should be possible at any time, with just a minor effort. These files are subject to DAILY backup.
Those files that are modified not daily but, say, ONCE PER WEEK in average. They are of medium size. Instead of their extension, they are rather characterized by the sub-directory in which they are stored. (Here the organization in a tree of sub-directories comes in handy.) I would postpone the backup process to a time that is not so crucial for production, say to Saturday afternoon, just before ending a weeks work.
Those files that are never modified but would mean a dramatic loss if they are still needed to restore, e.g. in case of a complete system crash. Typical instances are files that once were downloaded from the Internet, for free or even paid. If they would have to be restored and no backups were available, I would have to download them again and pay once more for the connection time and their purchase price. Even if they were free, I could not be sure if I would find the URL again and if they were still ready for free download. They are what makes the "LONG-TERM backup".
When I bought my current computer, I did two things. (And I m going to do it again in some 2-3 years, when my current computer will be "scrap iron" again and the next generation of computer hardware will be here):
I asked my computer vendor from whom I purchased my current computer to take the harddisk out of my previous computer (that was "scrap iron" at that time) and to build it into the new one. So I could not only save my old files. Moreover, I had one additional harddisk partition that I reserved exclusively for daily backups. Thus the daily backup will basically just be a copy process from one partition of the harddisk to another; strictly internal to the computer, about the most efficient kind of copying you can have. By compression I would be able to bring the total size of a daily backup down to some 40 MB. Consequently all the daily backups over about one month time would fit into that partition. Retrieving individual files from a compressed archive is a matter of seconds. If I memorized at WHICH DAY I did WHAT, I would be able to recur exactly to backup files dating back 3-4 weeks.
For many years already I am working with two computers, the desktop machine (thats the one to be backed up) and a laptop. The latter, of course, is smaller in its harddisk and much slower. Still, for the weekly and for the long-term backups it would be fine. I only needed to purchase a network card. By it I would be able to download the some 500 MB of a weekly backup in about 30 minutes.
If you are not in that comfortable position to have two computers, you can do the same with one computer only. To be on the safe side, you should strive to equip your computer with a backup medium that can be physically separated from the machine that was backuped. (Just in case your harddisk should be inaccessible one day, or any serious physical damage happened.) You can do that by purchasing any mass-storage medium (e.g. a JAZ or ZIP drive).
Having done that, I only needed to prepare two batch programs. I would design them such that daily backup and weekly backup could be done by a single key press.
Coding of these batch programs will be the subject of the next, final article of this series.
About the Author
Article by Gunter Gerdenitsch, owner of 1st Components Design, Universal Software Components for Computer Applications without Programming 1st-components.com, 1CD offers a product line called "DLG" for building applications without programming.
:To contact see details below.
gunter@1st-components.com
http://www.1st-components.com
Before embarking on regular backups, you should consider which backup strategy is best for you. From my own experience I recommend multi-level backup.
For a clever backup strategy you should, first of all, organize your harddisk (see preceding article of this series). In addition to that, you should consider three points:
Which of my files are the most "volatile" ones, i.e. they are modified virtually on a daily base? In other words, if I would have to restore a file from its backup, at which files would I lose the most working hours? (That is, if I cannot recur to their yesterdays state but only, say, to the state one week ago.)
What is the total backup size (in megabytes)? In other words, how much of my productive time will be occupied by the backup process?
How can I access these files (by the least coding effort, of course)? What backup medium am I going to use?
In view of these questions, I came to the conclusion that three types of files should be kept apart:
Those files at which I should be able to recur to backups that are one day old at maximum. If they were older, I would suffer a dramatic loss that could seriously impede my business. They are usually small. But they are of many different types of files (marked by the extension in the files name.) The backup process should not take more than a few minutes. Restoring individual files should be possible at any time, with just a minor effort. These files are subject to DAILY backup.
Those files that are modified not daily but, say, ONCE PER WEEK in average. They are of medium size. Instead of their extension, they are rather characterized by the sub-directory in which they are stored. (Here the organization in a tree of sub-directories comes in handy.) I would postpone the backup process to a time that is not so crucial for production, say to Saturday afternoon, just before ending a weeks work.
Those files that are never modified but would mean a dramatic loss if they are still needed to restore, e.g. in case of a complete system crash. Typical instances are files that once were downloaded from the Internet, for free or even paid. If they would have to be restored and no backups were available, I would have to download them again and pay once more for the connection time and their purchase price. Even if they were free, I could not be sure if I would find the URL again and if they were still ready for free download. They are what makes the "LONG-TERM backup".
When I bought my current computer, I did two things. (And I m going to do it again in some 2-3 years, when my current computer will be "scrap iron" again and the next generation of computer hardware will be here):
I asked my computer vendor from whom I purchased my current computer to take the harddisk out of my previous computer (that was "scrap iron" at that time) and to build it into the new one. So I could not only save my old files. Moreover, I had one additional harddisk partition that I reserved exclusively for daily backups. Thus the daily backup will basically just be a copy process from one partition of the harddisk to another; strictly internal to the computer, about the most efficient kind of copying you can have. By compression I would be able to bring the total size of a daily backup down to some 40 MB. Consequently all the daily backups over about one month time would fit into that partition. Retrieving individual files from a compressed archive is a matter of seconds. If I memorized at WHICH DAY I did WHAT, I would be able to recur exactly to backup files dating back 3-4 weeks.
For many years already I am working with two computers, the desktop machine (thats the one to be backed up) and a laptop. The latter, of course, is smaller in its harddisk and much slower. Still, for the weekly and for the long-term backups it would be fine. I only needed to purchase a network card. By it I would be able to download the some 500 MB of a weekly backup in about 30 minutes.
If you are not in that comfortable position to have two computers, you can do the same with one computer only. To be on the safe side, you should strive to equip your computer with a backup medium that can be physically separated from the machine that was backuped. (Just in case your harddisk should be inaccessible one day, or any serious physical damage happened.) You can do that by purchasing any mass-storage medium (e.g. a JAZ or ZIP drive).
Having done that, I only needed to prepare two batch programs. I would design them such that daily backup and weekly backup could be done by a single key press.
Coding of these batch programs will be the subject of the next, final article of this series.
About the Author
Article by Gunter Gerdenitsch, owner of 1st Components Design, Universal Software Components for Computer Applications without Programming 1st-components.com, 1CD offers a product line called "DLG" for building applications without programming.
:To contact see details below.
gunter@1st-components.com
http://www.1st-components.com
Copyright © 2005-2006 Powered by Custom PHP Programming