Storing Filemaker Server Backups on a SAN drive

[bledrew1]

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

 

[Wim Decorte]

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 September 22, 2015 by Wim Decorte

[typewriter]

So, you would not recommend using a SAN for Progressive Backups either, I guess?

[Wim Decorte]

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.

[typewriter]

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:

http://174.65.97.190:8080/pages/filemaker/downloads/496.pdf

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...

 

[Wim Decorte]

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:

http://174.65.97.190:8080/pages/filemaker/downloads/496.pdf

 

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

[Fitch]

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.

[typewriter]

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.

[ggt667]

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 December 31, 2015 by ggt667

[Fitch]

@typewriter I didn't word that very well. I was referring to the security implications of externally authenticating full access accounts. See for example:

https://community.filemaker.com/message/68323

[Steven H. Blackwell]

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:

http://174.65.97.190:8080/pages/filemaker/downloads/496.pdf

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