Backup Database

[AlastairP]

Just a note about backups:
If I copy the entire database and application to another location, for instance to a USB thumb drive as a backup, I get corrupted tables.
There was no user logged in to the app at the time.
This seems to happen on the larger tables more consistantly, but can happen on the smaller tables.

The largest table is approx 70,000 records

But if I copy the entire database to another folder on THE SAME DRIVE all is OK.

Would this be anything to do with having long field names?
Or could this be something else entirely?
(I am in the process of building Ver 2 of the app, with no long field names - but that's another story)

I need to implement a solid backup policy.
At this stage, we are intending to use a large capacity HDD in a caddy.

I would appreciate any comments or feedback on the subject.

 

[GriffMG]

Sounds more like a problem with the USB drive.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Olaf Doschke]

True, I would also suspect that thumb drive.

But what is the corruption? If a dbf is large and you copy, you copy the header bytes first, adding data is still possible, so even though you swear no user was in the database, that would change the dbf header after it's copied and before it's fully copied, so on the thumb drive you end with a dbf with a reccount header defect.

That's what I also encountered.

What could contribute to this is offline files, caching and other os level mechanisms.

It's better to put a backup process into after hours.

Bye, Olaf.

 

[Olaf Doschke]

clearer:

...that (eg inserting new records) would change the dbf header after it's copied, but before the whole dbf file is fully copied...

Bye, Olaf.

 

[Mike Lewis]

I agreee with the others. In principle, if you can safely back up to another folder on the same drive, you should be able to safely back up to another drive.

Also, I would definitely not abandon long field names because of this. It's highly unlikely that there's a connection between long field names and corrupted backups. But, even if there was, it would be better to find the cause of the corruption than to do without the benefits of long field names.

Of course, if you've another reason to get rid of long field names, that's another story. But it's hard to imagine why you would want to do that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[AlastairP]

The table corruption is when I try to open the table, I get a message something like "Table is corrupted, try repairing" etc

I will try a few more scenerios and see where the problem lies

I will say this: when copying to the thumb drive, the USB stick is plugged in to a workstation.
The workstation is connected to the server by way of remote desktop.
Perhaps I should have mentioned this in the original post.

Alastair

 

[GriffMG]

I certainly think there is scope there for the data to be corrupted in transit - you might be better off using another technique to get the data from your server to the desktop/USB

I think in the first instance I would try copying to the HDD of the desktop.

Is it possible to map a drive to the server? or to map a drive to somewhere else that the server can also map a drive to?

Alternatively, can the server be set up with a web server (IIS?) that can provide your files via http: (perhaps zipping them up?).

Good luck

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

 

[Mike Lewis]

Alastair,

Judging from the wording of the message, it could be that the link between the DBF and the DBC is broken; or that it's pointing to the wrong place. That in turn suggests that it might be a problem with relative paths.

You might find this link useful:
Fixing broken backlinks in DBC and DBF files

By the way, can we assume that you correctly ejected the USB drive after copying to it?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

The exact message you get with a wrong reccount in the dbf header is "Table ... has become currupted. The table will need to be repaired before using again."

What you can do for a simple repair is changing Byte 4-8 in the dbf file or simpler do this with each corrupted table

SET TABLEVALIDATE TO 0
USE thetable.dbf
APPEND BLANK
DELETE
USE

This will correct the reccount in the header, if it's just that corruption. There might be more broken, VFP is not specific about a table corruption type.

It it solves your corruptions it's another hint my assumption about the adding of records during copying is correct and the reason, this makes you face an overall problem on top of the single table corruptions: you might have new records in dbfs pointing to parent records not exisintg in your backup, if that parent table was already fully copied before the child table.

Also about copying via remote desktop: if you copy from remote desktop via clipboard functionality, make sure you don't use the clipboard for anyhing else during copy progress, even a short text snippet will make the file copy fail. That's really a bummmer about remote desktop I came across.

I also stand to my earlier advice: Create a job for backups and let it run after hours, eg at night. There surely are better backup options, eg check out robocopy or beyond compare, or any other synching software enabling you to define a decent file copy/mirroring job.

Bye, Olaf.

 

[DSummZZZ]

Another thing to keep in mind is you're at the mercy of the USB driver developer. A lot of USB devices and/or their drivers - especially thumb drives - are not that 'solid', especially when it comes to large files.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[AlastairP]

Thanks for that,
Yes olaf, that is the error message I got.

A dedicated backup facilty in the server room is the answer.
Like you said, scheduled to run after hours.

I will set this up.

Regards
Alastair