I deleted the unused themes and still no joy.
I then copied my .fmp12 file to my MacBook ready to do a side by side manual update of the known good file and decided to run the Recover process on it.
Bingo! It came up with no errors!!
I copied it back to my I Mac and ran Recover on that file again and it also came up with no errors.
Good news, but I am none the wiser, except that I will use Recover to backup in future.
1 of 1 people found this helpful
Not sure what you mean bu using Recover to back up.
The recover process leaves the original file untouched, but makes a copy. I have found that depending on the issues is finds, you can go back into the original file and remove the items that recover indicated were bad, then run recover on the original file again and have it report building a new file with out detecting a problem.
At one point I had a chance to discuss this with Alexi Folger of FileMaker after sitting through one of her devcon presentations on File recovery and she indicated that this was a valid method. Depending on the issue there are times when it can't work.
For normal development I have a Mac Mini running as an FMS server. It backs up files under active development once per hour. I find that this protects the files fairly well.
I took a look at Manage Themes. It doesn't look like it lets you delete default themes like Classic. So I'm not sure if you can delete an internal theme.
Thanks for your response Bruce.
Yes backing up once per hour or so is the right thing to do. I should and will use a server for my Macs very soon. As it stands my back ups are manual and I simply forget to do them at that sort of interval and in this case it would not have mattrered if I was backing up a damaged file. I would still need to fall back to the most recent known good copy.
I like the idea of using Recover to copy as it validates the file contents.
I thought more about the issue I had which "repaired itself". I suspect the development file I was using may have been so fragmented that the Recover tool was unable to locate all fragments and the act of compressing and transporting the file to another device created a new unfragmented file. So in fact there was nothing instrinsicly wrong with the file itself.
1 of 1 people found this helpful
Backups really slow the system down for users. FileMaker Server has a wonderful feature called Progressive Backups that can update every 5 minutes. It is very fast because it only updates changes made in the last 5 minutes and not the whole database. And then I do full backups at night when no one is on and the slow down doesn't impact users. Also, the scheduled backups can indclude the validate function to verify your backups are good.
It is a "bug"
> when I run the Recover:
8476 Recovering: theme 'com.filemaker.theme.classic' (1)
This item changed
on ech of the four themes.
That sounds fantastic. I'm new to Fm and have not had a chance to check out server yet, although I have beed assured it is very good.
So with the Progressive Backups I guess Server just "freezes" the database for a few seconds while it grabs the latest data, is that the case? If it is so then my clients will be in raptures or at least should be. My existing client base averages just 5 users per site and those "average" clients are an absolute nightmare where backup is concerned. When damage occurs I expect approximately 60% to not have a recent valid backup.
I'll check it out and become more familiar with that resource.
I think you mean "run Recover on a backup"
It is a good idea to run Recover, once in awhile, just to check the log for "problems"
I have posted more notes here:
> Good news, but I am none the wiser, except that I will use Recover to backup in future
The progressive backups have an equal or larger impact on the disk i/o and processor then the regular backup, because it does creates a full backup set on on each run. It does *NOT* just backup the latest changes. Here's what it does:
- during the interval it keeps a log of changes
- at the end of the interval it takes the oldest backup it has and creates a full new set and rolls those changes into the files
- then it deletes the oldest back-up set
So foregoing regular backups in favor of progressive backups:
- is not going to save resources on the server
- only gives you a 5 and 10 minute-old backup set, nothing more
Progressive backups are meant to complement the regular backup strategy, not replace it. If it is important to be able to go back to various restore points during the day then progressive backups alone will not help you. It will only give you the last 10 minuts, not a backup for every hour of the last say 4 hours.
They are great for giving you a restore point with minimal lost of data, but they are not great for being able to find a restore an accidentally deleted data from an hour ago, or two hours ago.
If backups have a noticeable impact on the users then I would venture to say that the server is not properly up to the task. So instead of cutting backups, a new server would seem to be in order.
I do not know what happens under the hood on Progressive backups. But I have several clients that used to run full backups every hour and some of them had a very large performance hit to the point where staff quit doing work at the top of the hour since it was so slow. When I began implementing Progressive Backups, no one could even tell the backups were going. So from a lot of personal experience, I disagree that Progressive Backups use the same amount of cpu resources as full backups. I do not know why they don't, but real world experience shows a sizeable performance improvement when going to Progressive Backups than when doing full backups that was clearly recognized by staff of multiple companies. I do agree that Progressive Backups do not replace regular backups which I mostly schedule at night. But their implementation has really improved the performance hits that we used to have on full backups during working hours.
A lot depends on the design of the solution. If it is one monolitic file vs. multiple files with archive data separate from active data, then that makes a huge difference.
I was reacting mostly to your blanket statement of "Backups really slow the system down for users". To a lot newcomers here that translates into "uh oh, go to reduce the backups - backups are going to make me look bad".
In a good deployment backups do NOT slow the user experience down. A good deployment takes into account what the system is, how the backups works and finds the best solution design/deployment design to make sure it does not. Things like backup speed are not after-thoughts, the need to be considered right up front.
I agree that backups and their impacts on performance should not be an after thought. But often, as a consultant, I come in only after they are having problems. And we look at the server and storage systems, etc., and other performance issues from sloppy development. I guess that is what keeps me paid <grin>.
I still think what you are saying is contrary to what FileMaker said at Devcon 2012 regarding performance and Progressive Backups and it is contrary to the experience I have had in the field. I do not have the underlying explanation, but I concur with FileMaker that they run much quicker and with less impact on server performance. Let me quote FileMaker exactly:
"After the initial full backup is complete, the Database Server only copies the changes from the hosted file to the progressive backup folder. Progressive backup can run more quickly than a scheduled backup, with less impact on server performance."
I guess that is what keeps me paid
No <grin> here. I have been making my pay for the last 15 years rectifying bad deployments. And I have been "preaching" as a presenter to half of all devcons about the same subject.
In fact most of my reputation is based on posts like these and the white papers that I've published on the subject and the devcon presentations I've made on the subject.
What I am saying can be different than what you have been experiencing on your deployments. And that's fine. In fact I'd encourage you to say differently so that we can pool our resources.
The relevant part of your own quote is "After the initial full backup is complete". And that's the part that depends on the design etc. All that I am asking you to do is not make statements like: "Backups really slow the system down for users"
That statement is simply not true. And stated like a fact it could lead people to abondon regular backups.
"After the initial full backup is complete, ... Progressive backup can run more quickly than a scheduled backup, with less impact on server performance."
Note the "Can run more quickly" in that sentence. Not "Will"