SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Pastimes : Computer Learning -- Ignore unavailable to you. Want to Upgrade?


To: mr.mark who wrote (3117)4/22/1999 1:11:00 PM
From: jw  Respond to of 110652
 
<<does anyone here have a working knowledge of iomega jaz drives?>>

mr.mark, sorry I have no experience yet with jaz drives. Have a couple 800MB iomega tape backups drives bought at egghead auction that haven't been installed.

Regards, /jw



To: mr.mark who wrote (3117)4/22/1999 1:22:00 PM
From: PMS Witch  Read Replies (1) | Respond to of 110652
 
Backups in general:

I don't have an Iomega drive, but here's what usually happens during backup in the general sense.

A:
You back up files. You delete a file. You back up files again. Your backup usually contains the deleted file unless you take steps to remove it. If deleting the file is the only change you made, the backup usually runs but finds nothing to do.

B:
You load 6meg package. You uninstall it. You load 8meg package. Files removed with uninstall are usually gone. Uninstall doesn't always remove all. A BIG complaint of many people. (Shared files often remain.) When you load 8meg package, files of similar name get overwritten, original files not removed remain, files with new names get copied. Backup will pick up all files it finds; it can't tell the difference between current package files and 'left overs' from earlier package.

If you did a backup of the earlier package, then an incremental backup after installing the later package, you'll store all files found. If backup finds files of similar name, it'll store the latest version it finds, assuming the file has changed and you wish to save those changes. IF UNINSTALL REMOVED ALL FILES, YOUR BACUP WOULD BE 'PURE' NEW PACKAGE. Not very likely!

C:
You back up your files. You delete one sentence from one file. You back up again. In deleting your sentence, you've created a newer version of the file. Backup will save this newer version, replacing the original in the backup. The sentence is lost during your EDIT, and not during your BACKUP.

Backup programs usually simplify life for themselves through the use of temporary files. Once the work is finished, they rename and remove files, leaving your system the way they found it.

I don't want to complicate matters, but some 'Code Management Systems' actually store your data along with the changes you've made. You have the option of restoring to the last OR ANY PREVIOUS version you've stored. Programmers often find their changes don't work and need 'back out' of recent changes once current problems become known. These are a different type of backup.

Hope this helps. If I've said something incorrect, please point out my error. I need to learn this stuff too.

Cheers, PW.

P.S. I heard someone jokingly telling another that if you reduced the size of the font you're using, your documents will occupy less disk space. After having a laugh myself, I realized small fonts translate into more characters per line; hence, fewer 'new line' characters needed per document. Not everything we hear is TOTALLY crazy.



To: mr.mark who wrote (3117)4/22/1999 2:13:00 PM
From: Richard Babusek  Read Replies (1) | Respond to of 110652
 
The backup options and strategies available are function of your software, not the medium. Most allow one to accomplish the level of safety necessary.

Incremental backup uses save sets, and a log of save sets. This allows one to be able to recreate your system to the state of existence at the time the save set was accomplished.

So if you do an incremental backup immediately prior to upgrading your system, and discover the software upgrade is not what you wish, or the older version for some reason was better suited to your purposes, you can just restore to that save set. This wouldn't usually be necessary, you would just restore certain files. But if your installation had a major negative impact on your system, and you weren't sure how much damage was done, you could restore to exactly were you were as of any date.

Depending on the importance of your system, how many users etc., you may have a strategy that uses several save set strategies. Backup medium X may have several save sets that go back in time beyond what will ever be used, but include some that must be saved. In order to be able to recapture the medium, you would start a new medium Y, while saving medium X, until it's contents becomes obsolete, when it can be reused.

Some archiving strategies are also usually offered to minimize storage space. An advantage to allowing one backup system to control these functions is the activity logs that are maintained.

So my suggestion is to get familiar with the options and functions of a good commercial backup package, and apply a strategy that does what you need.

I personally have alternative named sets, say A & B for each logical drive. I let the current set grow ‘till it needs four zips, then erase the old set (4 zips), call it the current set, and start over.

Ricardo