Even if it is possible I don't think I'd want that. The RC data is integral to the solution, no - just as if it was physically embedded in the solution. Can you expand a bit on your use case for not wanting them in the backup?
The files are taking up too much real estate. The folder structure and documents are backed up frequently enough when the machine itself is backed up. If I want to do hourly back-ups of the database, I only want the database backed up, not 5GB worth of documents.
sounds like you are misunderstanding how FMS' backup mechanism works. It's more like time machine; if add only one bit of container data between two backup runs; on the next backup run FMS only consumes extra disk space for that one container, not the full 5GB. But FMS does keep your whole backup set together through hard linking to the previously occupied disk space for files that were not changed. It's pretty smart.
Do a manual backup, check the amount of free disk space in Finder. Then run the backup again and check the difference.
Like Jason Mundok, I backup twice a day, at 10 PM and noon. The backup include the RC folder and it always backs up the entire folder which is +40 GB. The photos last changed about 3 weeks ago, but it still backs up the entire set of photos each time. I don't want to use +43 GB of my backup device each day when the database is only approx. 3 GB. I don't do incremental backups, don't need that level of redundancy. Currently I have go to my backup file and remove the RC folder, then backup to my backup device, then put the RC folder back into the backup file. That way I have 10 days worth of backups locally and several years worth on backup device. It is time consuming, manual and would like a better way to do it.
But it doesn't... you can select the folder in Finder / Windows Explorer and it will report 40GB but that does not mean that an actual 40GB worth of disk space is consumed...
Unless you have your backup schedule set to only keep 0 old backup sets.
Do the test that I've posted previously and compare the remaining free disk space as reported in the OS.
You are correct in what you say, but imagine this. The Filemaker Backup program backs up the data to another drive on the FileMaker server. Applescript, when it works - manually otherwise, moves it to the folder to the Apple File Server. Retrospect moves it to a removable disk that I take home every night. That way if the drive FileMaker server is on crashes, I reinstall the system and FMS, copy the data over and away I go. If the FMS server dies, slap a new server in, restore the data from the Apple File Server and away I go. If the building burns, or earthquake hits, buy a new machine, bring the backup disk from home and away I go. I keep the last 10 days worth of FileMaker Backups on the FileMaker Server (backed up at noon and 10 PM) and the last month's worth of the data on the Apple File Server and have a backup for each day called Backup_2015-month-day-time (Backup_2015-02-04 for last night's backup) since the beginning of the year on back up disks. When you copy it to another volume or back it up, that folder, on the new device, will take, in my case, physically, +43 GB of space. Since I want a complete backup of the data each day so I can restore to a particular point in time quickly, each of those will take +43 GB of storage on the backup disk even though the photos only change in the fall. For example, someone last Thursday deleted the wrong record. I go to my remote volume, find folder Backup_2015-01-28 and remove the file with deleted data and install the new one. Quick and easy, or would be if the FMS Backup didn't backup the externally stored containers as well.
Ah, ok, Wim. I was looking at the folder itself and it was reporting the full 5GB for each backup. That's a bit confusing that it would report 5GB but not actually mean 5GB but I trust your knowledge on this. Thanks for the responses.
Interestingly, it sounds like when you copy those hard links, it sounds like it takes the actual 5GB (or whatever) and copies them. So you would be using all of that space on the remote drive. If I copied, say 5 backup folders, sounds like I'd get 25GB worth of external data.
Additionally I do find it odd that I can prevent the externally stored data as long as my database is stored in an "additional" folder rather than the default. I wouldn't mind turning that off since the folders where those files are stored is backed up each day anyway.
I agree with the feature request to disable external container storage backups, for exactly the reasons you mention - so much space used in the "backups of the backups".
Crazy idea: Replace the AppleScript based backups to the file server with rsync. It preserves and respect hard links and so the resulting file structure would be identical to the FMS backup structure, saved space and all.
It's a bit of shell scripting to get it done, but worth it once it's working...
Guys, has a best practice arisen for backing up files without backing up several gigs worth of container data?
I don't want to back up container data at all, because all of those files are stored elsewhere. Should I just move the tables that have external data into a separate file that doesn't get backed up?
As an aside, Wim's articulate description of the hard linking process has informed me as to why, when I delete several backup folders, that the available space on the drive barely budges the needle.
Now it makes sense. But I have to get the available space up somehow. It's too tight.
The best practice remains to back up everything you have so that you can restore easily.
FMS14 however has an option that if you use an additional folder for your data files and RC files that you can exclude the additional RC folder from backups.
One more thing to consider. The space saving/hard linking feature is Schedule specific.
If you have 4 individual schedules to back up at 10 AM, 1 PM, 4 PM and 7 PM you will use ~4 times the disk space as if you do this with 1 Schedule.
Yes, the useful FMS space saving/hard linking feature does not extend to many types of conventional copies made to external volumes unless you do something more custom as per Perren Smith's suggestion.
You might find this thread useful:
As posted earlier, here is a good thread + my thoughts at the time...
We often use a separate file for images and files for the reasons that you mention. There are some use cases where a customized approach like that can get you out of a tight spot!
This is an old thread, but here is what I do. I backup via the terminal. On the second line I delete all the external data. In that way I have daily backups that are small and monthly backups with all the info.
fmsadmin backup -u USER -p PASSWORD -o
find /Volumes/Storage/tmp/ -name RC_Data_FMS -print0 | xargs -0 rm -r