Jump to content

Storing Filemaker Server Backups on a SAN drive


bledrew1

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

Recommended Posts

I struggle to figure this out. I'm told that in our completely VM environment that we use a SAN architecture which should provide the speed and the ability to present the volume as a local drive. None of the material that I find in the forums seem to deal with the VM environment and translating is somewhat difficult.

I'm arranging a test server so configured to see if this would work. The problem we're looking to solve is that it would reduce the enormous drain on our NetBackup resources by backing up the Filemaker BUs on a SAN volume rather than from the Filemaker Server itself. I know there is an option to have the Filemaker Server schedule backup script include running a Windows script to copy the BU to a network drive after it completes. In our case with data in excess of 2TB it simple would be too slow.

Bill

Wizards of the Coast

 

Link to comment
Share on other sites

Hi Bill,

Some of this was covered already on the RealTech email list.

The reason that you don't find any materials is just because (when properly deployed) SAN disks are exposed to the VM instance as just local drives.  To put it simply: Windows and FMS do not know it that the the C drive (or D or E or whatever) is actually on a SAN, it sees it as just a local drive.

So you don't have to worry about copying FMS backups to the SAN through an OS script.  The SAN (again - when properly deployed) will just be a local drive that you can have FMS back up to.

I've said "when properly deployed" a few times now.  With that I mean a typical fibre channel connection between the physical host that runs the VM instances and the SAN infrastructure (think of those as basically a big box full of SSDs).  Cleary the most important factor here is the speed between the OS and the SAN.

There are poor ways to deploy a SAN (anything but fibre channel basically) and there are also NAS which are not to be confused with SANs.  NASes are a big no-no since they mimic disk i/o operations through the network card.  Network speeds are a mere fraction of normal disk i/o speeds and network traffic is a lot more fragile than true disk i/o interactions which is why those are a no-no.  SANs deployed through network interfaces are equally bad (iSCSI for instance).

 

Edited by Wim Decorte
Link to comment
Share on other sites

  • 3 months later...

My point is that a SAN is typically not "visible" when properly deployed.  It looks to the machines as just another internal hard drive and that means that you can use it for backup destinations etc.

But if the SAN is only reachable through a network cable and a mapped drive letter (as opposed to dedicated fibre-channel hardware when properly deployed), then: no.  Because that makes it a NAS (network attached storage) and not a SAN.

Link to comment
Share on other sites

Better stay clear of any Virtual SAN solutions also.

I read a very informative White Paper written by Todd Duell on FMS14 deployment in general:

Still, I think FMI Inc. could do a good job in providing some sort of knowledge centre focused on performance and capacity issues. Playing with the big guys also means providing in-depth information. Ofcourse the number of hardware options is enormous, but don't tell me it's because FMI cannot recommend PC hardware because they are a subsidiary of Apple...

 

Link to comment
Share on other sites

52 minutes ago, typewriter said:

but don't tell me it's because FMI cannot recommend PC hardware because they are a subsidiary of Apple...

 

I don't think that's the issue at all.

Problem is that it is impossible to recommend the proper hardware (Mac or Windows) without an in-depth knowledge of:

- the current stats

- the current design

- the current deployment

- the projected growth in # of users, added functionality

 

For instance: I get called in a lot to help solve performance problems.  Almost invariably processing power is the constraint and adding more cores to the server helps resolve the issue.  But only to a point.  If the design is of such a nature that there is one table that everyone reads from and writes to all the time then adding more cores is not going to help much after a certain point.  The extra cores help in offloading reads/writes to other tables and anything that is thrown at the server through PSoS and server-side schedules.

But the design is usually at the core of all issues: an abundance of unstored and summary calcs, busy layouts where all of these are shown (over and beyond what the user really needs for the job at hand), layouts with umpteen portals, some or all of them sorted or filtered,...

I never recommend server hardware without spending time to see what the bottlenecks are.  I can't see how FMI - who is even more removed from those solutions - could do a better job than I can.

That's why they gave us monitoring tools.

1 hour ago, typewriter said:

 

I read a very informative White Paper written by Todd Duell on FMS14 deployment in general:

 

As an important aside, I've only made it through page 1 of this pdf and there are already two very important things wrong with that info... I will ping the author about it.

1) EA works with 3 types of deployments, not 2: AD, OD ... *and* local accounts and groups on the FMS machine itself.  That is often overlooked

2) contrary to what Todd is saying, FM *does* work in a mixed environment.  You *can* have internal FM accounts and EA accounts in the same solution

Link to comment
Share on other sites

10 hours ago, Wim Decorte said:

2) contrary to what Todd is saying, FM *does* work in a mixed environment.  You *can* have internal FM accounts and EA accounts in the same solution

You not only *can*, you must have internal accounts, since [Full Access] accounts should only be internal.

Link to comment
Share on other sites

8 hours ago, Fitch said:

since [Full Access] accounts should only be internal.

Well, you must have at least one local [Full Access] account, but other administrators may have external authentication.

The local account will be your lifeline if your solution is taken off-line.

Link to comment
Share on other sites

Why is this discussed as two separate things? 1) FileMaker Server and 2) backup drive on SAN? Why not make one VM with enough resources to do both tasks?

I usually mount iSCSI volumes and it works like if local.

If this approach spends more or less resources than a simple backup I'm not aware of.

Edited by ggt667
Link to comment
Share on other sites

On December 30, 2015 at 7:35 AM, typewriter said:

 

I read a very informative White Paper written by Todd Duell on FMS14 deployment in general:

Still, I think FMI Inc. could do a good job in providing some sort of knowledge centre focused on performance and capacity issues. Playing with the big guys also means providing in-depth information. Ofcourse the number of hardware options is enormous, but don't tell me it's because FMI cannot recommend PC hardware because they are a subsidiary of Apple...

 

First, the small portion of the referenced White Paper that I have read appears to contain numerous errors. So we will need to sort that out here in due course.

Second, FileMaker's ownership by Apple is not really relevant here.  FileMaker Server runs on Windows Server platforms in many, many places...including some places you might not expect it to run.

Third, there are a number of excellent references from FIleMaker, Inc. about FileMaker Server in various versions. I have attached one to this message.

Steven

server_configuration_guide_en_14.pdf.zip

Link to comment
Share on other sites

This topic is 2985 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.