Jump to content
Server Maintenance This Week. ×

Backing up


This topic is 7957 days old. Please don't post here. Open a new topic instead.

Recommended Posts

In light of my recent tragedy, I have been re-thinking my backup method.

Right now, I have a script that runs at closing to save a copy of the file to a backup folder. The thing is that this folder is only cleaned out by users arbitrarily, and it can become quite large if they have not cleaned it out for a while.

I am sure that you guys have dealt with this and have much more experience at backing up solutions. Your methods and thoughts are greatly appreciated and should benefit everyone, including me.

Ken

Link to comment
Share on other sites

Yes, I should probably elaborate.

This is a single-user marketing program that would house a maximum of about 1500 records. The importance I think really is up to the users, but if I was an agent I would rate its importance at about 7 on a scale of 1 to 10. I know that other databases that I have worked with in mult-user environments, we have servers with RAID configs and tape backups that are about as effective as it gets. But I do not have to administer in this case.

Thanks

Ken

Link to comment
Share on other sites

Here's how I dealt with backing up: I have a single user kiosk solution for very inexperienced users. Rather than give them the option to backup, which I know they won't exercise, I play paternalistic. Whenever they exit, I automatically backup all files to a Backup Folder. These files are automatically zipped by a routine I wrote in WinBatch so they don't take up much room. The solution will never have over 10,000 records so the zipping is very quick. On the exit screen, I also give them an option of backing up to a removeable drive like a Zip or Jazz (also thru WinBatch): all they have to supply is a drive letter. While we all know hard drives rarely explode, it's really small insurance. The net is, the easier I can make it for them, the more likely it will get done.

I also wrote a FM kiosk utility that does nothing other than to restore those zipped files because I don't allow them to use the recover function which works only part of the time.

After clobbering my solution a number of times, I also have automated my own backups pretty much the same way.

Link to comment
Share on other sites

I utilize a similar "EXIT" backup system. My theory... KISS... "Keep It Simple, Stupid"!!!

I developed a multi-user (3 user), 20,000 record solution for a group of 'older users' (60-70 years young)!!!

One computer (called Server) 'hosts' the files... the others computers (called Workstations) access the 'hosted' files. The 'Workstations' have 'Share Points' that the 'Server' connects to automatically. The users always start the FMP files on the 'Server' first. A 'Shutdown' script on the 'host' will write (export) a "Backup" text file to a specific directory on the 'Server' and then write (export) a "Backup" text file to a specific directory on the 'Workstation' 'Share Points'. The 'Shutdown' script 'locks' the screen and goes to a 'backup' layout with a progress bar and explaination to tell the users what is happening.

Over the years... 12 years... I have learned alot about how I will start to THINK when I get to be 60 years young...

Some things I have implemented... because I LEARNED to do so...

-- Many, Many, Many Backups...

- The 'Shutdown' script writes (exports) "Backup" text files to different directories on different days...

-- Everyday to the "EVERYDAY BACKUP" directory on the 'Server'

-- Monday, Wednesday, Friday to the "MWF BACKUP" directory on one 'Workstation'

-- Tuesday, Thursday, Saturday to the "TTS BACKUP" directory on the other 'Workstation'

-- Many, Many, Many Archives...

- The 'Shutdown' script writes (exports) "Archive" text files to different directories on different weeks...

-- Every Friday to the "WEEKLY ARCHIVE" directory on the 'Server'

-- Every 1st & 3rd Friday to the "1-3 ARCHIVE" directory on one 'Workstation'

-- Every 2nd & 4th Friday to the "2-4 ARCHIVE" directory on one 'Workstation'

-- DON'T ALLOW USER RECOVERY...

- If there is a problem... I want to be the one to do the 'recovery'. ME, ME, ME, and ONLY ME!!!

-- Data integrity is too important to risk the chance of 'these' users attempting the recovery.

Some Reasoning...

- Why backup to other computers? ALL users take "the easy way out"... meaning... if they have to insert tapes, diskettes, etc., THEY WON'T!!! This system happens automatically without user intervention and without the worry of them using the incorrect tapes, diskettes, etc. Each computer has ONE BACKUP directory with ONE BACKUP file. In addition, each computer has ONE ARCHIVE directory with ONE ARCHIVE file.

- Why write (export) to text files for the backups? The backup files are 'hidden' in directories where the users typically won't find them. But... if they or anyone else (can you say... grandchildren) should happen to see them, they can't 'inadvertently' open them in FMP and start using them. Also, 'exporting' them as text files using the same file name will 'over-write' the previous text file in that directory.

- Why do I want to do the recovery? JOB SECURITY!!! And... I know that it gets done correctly! When a problem occurs, it typically happened a few days ago and the users were unaware. So, using the most recent backup probably has some problems in the data. I typically have to go back through the various backups to see when the problem occured. Because of this... I may have to merge data from a couple of backup files. This is typically beyond 'most' users comprehension.

All that said... it been a GOOD 12 year learning experience!!!

Bob Kundinger

Link to comment
Share on other sites

This topic is 7957 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.