can't "Save a copy as..." of a shared db

On Fri, 1 Aug 2008 21:49:26 -0700 (PDT), iacon <tpradun.RemoveThis@gmail.com>
wrote:

>FM server has a backup system built into it, you can program it to run
>hourly, daily etc...
>
>This will save to the local machine but you can also tell it to save
>to any directory accessable to the machine. Have a better look in the
>server admin client, if you are using a PC it is a bit harder to find
>but it is there. It is in a wizard.

It's not there. You can backup databases but as far as I can tell you
can't save a clone.

--
FW


FileMaker Pro 8.5 Advanced on Windows XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server R2
 >> Stay informed about: can't "Save a copy as..." of a shared db 

The only way I know successfully to save a clone of a shared database
is:

1) In FM Server admin, close the database.
2) Open the database locally in FM Pro, NOT as a remote file. It'll
warn you that the file can't be shared but it'll open.
3) NOW you can save a clone.
4) Close the database in FM Pro and reopen it on FM Server.

No way to script that, not with Scriptmaker anyway. Is there a way to
save a clone of a remote database, let alone script saving it?

thanks

--
FW

FileMaker Pro 8.5 Advanced on Windows XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server R2
 >> Stay informed about: can't "Save a copy as..." of a shared db 

iacon <tpradun RemoveThis @gmail.com> wrote:

> Have a better look in the
> server admin client, if you are using a PC it is a bit harder to find
> but it is there. It is in a wizard.

If you have FM Server 9 in your local network, a web browser will do.
You get the server admin console by typing [servername]:16000.
[Servername] is the network name of the computer running FMS 9.
--
http://clk.ch
 >> Stay informed about: can't "Save a copy as..." of a shared db 

On Sat, 2 Aug 2008 13:10:42 +0200, clk.TakeThisOut@tele2.ch (Christoph Kaufmann)
wrote:

>iacon <tpradun.TakeThisOut@gmail.com> wrote:
>
>> Have a better look in the
>> server admin client, if you are using a PC it is a bit harder to find
>> but it is there. It is in a wizard.
>
>If you have FM Server 9 in your local network, a web browser will do.
>You get the server admin console by typing [servername]:16000.
>[Servername] is the network name of the computer running FMS 9.

I've got local access to Server, that's not the issue. Server won't
save a clone, at least I can't find a way.

--
FW

FileMaker Pro 8.5 Advanced on Windows XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server R2
 >> Stay informed about: can't "Save a copy as..." of a shared db 

On 2008-08-02 05:19:43 -0700, FastWolf <wolfsofast.TakeThisOut@NOSPAMcomcast.net> said:

> I've got local access to Server, that's not the issue. Server won't
> save a clone, at least I can't find a way.

You're quite insistent on this "saving a clone" thing, aren't you?

Perhaps if you let us know the purpose behind needing a clone, rather
than file+data, we could be more helpful.

If one truly needed incremental clones of a shared file, right now the
only way to do so using Server is to do the standard backup, remove the
backed up files to another drive, and do a Save As Clone either
manually or through a script on all the files. Then zip and store the
clones.

I can't really think of ANY reason to repeatedly save clones as a
standard backup technique.

As a developer, I keep the development copies of files on my working
drive. I upload clones to the server and import working data when I
make significant changes to structure. For development, though, it's
far more useful to having test data in the files, so I don't routinely
create or keep clones. Usually clones are only created when I have
immediate need for them.

Incremental clones created from files in use could be subject to
corruption, as you might not be aware if and when the server crashes. I
would not trust them to be useful in continuing development. My local
development files are backed up frequently, and if my computer or the
app crashes during development, I discard the current set and retreat
to a previous set, recreating the lost work. In this way, I know the
files I load up onto the server have never crashed. It's a bottom-line
attempt to prevent any possible corruption. It's not 100% certain, but
is considerably better than using or developing files that have lived
on the server for any period of time.

So let us know your actual purpose behind the need for clones, so we
can be maximally helpful.
--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA
 >> Stay informed about: can't "Save a copy as..." of a shared db 

On Sat, 2 Aug 2008 09:36:48 -0700, Lynn Allen <lynn DeleteThis @NOT-semiotics.com>
wrote:

>On 2008-08-02 05:19:43 -0700, FastWolf <wolfsofast DeleteThis @NOSPAMcomcast.net> said:
>
>> I've got local access to Server, that's not the issue. Server won't
>> save a clone, at least I can't find a way.
>
>You're quite insistent on this "saving a clone" thing, aren't you?

You betcha.

>Perhaps if you let us know the purpose behind needing a clone, rather
>than file+data, we could be more helpful.
>
>If one truly needed incremental clones of a shared file, right now the
>only way to do so using Server is to do the standard backup, remove the
>backed up files to another drive, and do a Save As Clone either
>manually or through a script on all the files. Then zip and store the
>clones.
>
>I can't really think of ANY reason to repeatedly save clones as a
>standard backup technique.

I have one very important client, an ambitious Web-based startup
company. I've built 2 stand-alone solutions for them for 2 different
tasks. One of them is hosted on FM Server 8. Even though I
*finished* the assignment a year ago, it has to be considered a work
in progress because every week they are asking me to make changes and
add functionality. I know it's madness to continue major development
on a solution that's online and live, but that's the deal. (Actually,
my 2 buddies who are Oracle progammers do this all the time, but on
vast, global corporate systems that are too large to back up.) When I
looked at the version I gave them a year ago (call it version 11) and
compared it with the version they have now (call it version 13) I
realized the differences were enormous. The incremental changes
really added up.

So as the solution continues to evolve I'd like to make sure there's
always a very current clone in case of file corruption. Yeah, it's a
long shot but I believe in being very, very thorough. These folks
need to have a fully-automated system for backup; I can't count on
them to do this on their own. Up to now I've been their automated
system, in that I connect remotely to their network and save a clone
manually. There are a lot of people that connect to this solution on
a 24/7 basis so closing it in FM Server and disconnecting everyone,
however briefly, doesn't go over real well. I was hoping to script it
so it could be a push-button, or even automated, process, that didn't
require the db to be closed to do it.

>As a developer, I keep the development copies of files on my working
>drive. I upload clones to the server and import working data when I
>make significant changes to structure. For development, though, it's
>far more useful to having test data in the files, so I don't routinely
>create or keep clones. Usually clones are only created when I have
>immediate need for them.

Hmmm ... I worry about file corruption. I want to have a clone BEFORE
I have immediate need for one.

>Incremental clones created from files in use could be subject to
>corruption, as you might not be aware if and when the server crashes. I
>would not trust them to be useful in continuing development. My local
>development files are backed up frequently, and if my computer or the
>app crashes during development, I discard the current set and retreat
>to a previous set, recreating the lost work. In this way, I know the
>files I load up onto the server have never crashed. It's a bottom-line
>attempt to prevent any possible corruption. It's not 100% certain, but
>is considerably better than using or developing files that have lived
>on the server for any period of time.

What I do is make additional copies of backed-up files and save them
in several different physical locations on the network, such as a NAS
server. I use a little freeware file sync utility to do all that for
me automatically. If there's a server/file crash I have very current
backups that 1) worked before the crash and 2) weren't on the server
when it crashed. And of course my own development files I keep on my
box and also save to external removable media. So when I have to
recover from a crash I can do it quickly with files I have confidence
in.

>So let us know your actual purpose behind the need for clones, so we
>can be maximally helpful.

Lynn, you and everyone here have always been extremely helpful and
receptive towards myself and I remain both grateful and honored.

thanks

--
FW

FileMaker Pro 8.5 Advanced on Windows XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server R2
 >> Stay informed about: can't "Save a copy as..." of a shared db 

FastWolf <wolfsofast.TakeThisOut@NOSPAMcomcast.net> wrote:

> Is there a way to
> save a clone of a remote database, let alone script saving it?

Use FMS admin console to save the database to your chosen backup
directory and work with the resulting file.

--
http://clk.ch
 >> Stay informed about: can't "Save a copy as..." of a shared db 

On Sat, 2 Aug 2008 16:55:33 +0200, clk.RemoveThis@tele2.ch (Christoph Kaufmann)
wrote:

>FastWolf <wolfsofast.RemoveThis@NOSPAMcomcast.net> wrote:
>
>> Is there a way to
>> save a clone of a remote database, let alone script saving it?
>
>Use FMS admin console to save the database to your chosen backup
>directory and work with the resulting file.

Of course! This makes perfect sense, thanks Christoph -- you've given
me the answer.

--
FW

FileMaker Pro 8.5 Advanced on Windows XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server R2
 >> Stay informed about: can't "Save a copy as..." of a shared db 

On 2008-08-02 15:30:13 -0700, FastWolf <wolfsofast.DeleteThis@NOSPAMcomcast.net> said:

> What I do is make additional copies of backed-up files and save them
> in several different physical locations on the network, such as a NAS
> server. I use a little freeware file sync utility to do all that for
> me automatically. If there's a server/file crash I have very current
> backups that 1) worked before the crash and 2) weren't on the server
> when it crashed. And of course my own development files I keep on my
> box and also save to external removable media. So when I have to
> recover from a crash I can do it quickly with files I have confidence
> in.

Thanks for the additional info. It does indeed illuminate your reasoning.

Well, reading on in the thread, I see Christoph has clarified matters
for you. That's what I would recommend, doing the normal backups and
then creating clones from them. You could easily script this so every
time you pulled a "cloneworthy" set of files and opened them on your
local drive it's easy to create the clones.

Other points to mention after reading your last post:

1. Make sure the backup copies stored elsewhere on the network are
compressed. Otherwise you court madness in having multiple same-name
files available for people to tamper with or connect to.
2. Check your backups on whatever media on a regular basis. We had a
large client tell us they were backing up religiously, only to find out
at the Worst Possible Moment that all the backups were corrupted and
unuseable. Took us a week of work and several miracles to reconstruct
the largest part of their data from backups stored at OUR location.
3. It's always possible to take a copy of backed up files from FM
Server. Not live files, of course, but you can have a single manual
backup schedule you can run from the server console anytime you need
to, and it will only pause users for a moment, not shut down. Then you
can download the files and make your clones.
4. Remember to have the client take off-site backups in addition to
your development machines. With a client with such intense data needs,
it's not amiss to have a formal Disaster Recovery Strategy, as our
recent California earthquake should have reminded us all.

I understand that if you have a large solution which will take a bit of
time to import data into, that the time it takes to create a clone may
delay getting the site back up in case of crash. I might suggest
another strategy:

1. Have "rolling" backups, with a backup being taken into a separate
folder at 10am, noon, 2pm, etc. every day of the week. (the standard is
to backup at the same interval in which it would be easy to re-create
lost data. For some companies that's weekly, others daily, others
hourly). Don't let those backups be overwritten for at least 72 hours
to a week. Yes, a lot of folders. Yes a lot of setting up schedules,
but what it means is that after a crash, you've got a good chance of
being able to pop up a really recent copy and get them up and running
right away.
2. Also have your clones of the most recent version. Once the interim
backups are in place, you can take the time to import the data into the
clones, then briefly take down the server and put them in place. The
result is a much shorter downtime, since the users don't have to wait
for the import to get the data flowing.
3. Be very VERY careful when working on live files over a remote
connection. This is the scenario which has caused catastrophic
corruption and schema-loss when the connection is lost during critical
operations such as field definition updating. People have reported
losing their entire Relationship graph, or all the tables, or sometimes
all the data. Scares the heck out of me, so I rarely do schema changes
live, even though my internet connection is pretty reliable. Scripting
changes and layout changes rarely cause this kind of corruption, but
the rule becomes "RUN A BACKUP IMMEDIATELY BEFORE MAKING ANY SCHEMA
CHANGES LIVE." That way if the worst happens, you can swap in the
files from 2 minutes ago.

Backing up, it's a way of life.
--
Lynn Allen
--
www.semiotics.com
Member Filemaker Business Alliance
Long Beach, CA
 >> Stay informed about: can't "Save a copy as..." of a shared db 

Thanks for being so generous with your experience and insight, Lynn.
Here's where I'm at on these ideas:

On Sat, 2 Aug 2008 20:20:00 -0700, Lynn Allen <lynn.TakeThisOut@NOT-semiotics.com>
wrote:

>Well, reading on in the thread, I see Christoph has clarified matters
>for you.

Christoph was kind and patient enough to give me the basic idea and
let me work out the obvious my own. [grin]

>Other points to mention after reading your last post:
>
>1. Make sure the backup copies stored elsewhere on the network are
>compressed. Otherwise you court madness in having multiple same-name
>files available for people to tamper with or connect to.

Never thought of this, you're right of course and I've been fortunate
not to have had problems with this yet.

>2. Check your backups on whatever media on a regular basis. We had a
>large client tell us they were backing up religiously ... Took us a
>week of work and several miracles to reconstruct
>the largest part of their data from backups stored at OUR location.

Oh yeah, been there and done that. I've always advocated doing
restores to test the process. A backup schreme without a tested,
proven restore is worse than useless.

>3. It's always possible to take a copy of backed up files from FM
>Server. Not live files, of course, but you can have a single manual
>backup schedule you can run from the server console anytime you need
>to, and it will only pause users for a moment, not shut down. Then you
>can download the files and make your clones.

Got it.

>4. Remember to have the client take off-site backups in addition to
>your development machines. With a client with such intense data needs,
>it's not amiss to have a formal Disaster Recovery Strategy, as our
>recent California earthquake should have reminded us all.

I've been trying to sell them on just such a strategy. They have
someone in-house who's their sysadmin and IT guy that supposedly takes
care of all that for them. They trust him but he is completely
clueless. They trust me too but they haven't hired me to be their
sysadmin; I'm not on their team, so to speak. Frankly no one over
there understands these concepts nor what's at stake. And of course I
can only help them with the solutions I built for them and the systems
that run them -- the rest of their network is awfully unprotected from
what I've seen. When I was working on the project last year I set
them up with an external hard drive for off-site backups and I hope
they've been diligent about using it. When -- when -- they do have a
disaster I will be able to restore what I built for them.

>1. Have "rolling" backups, with a backup being taken into a separate
>folder at 10am, noon, 2pm, etc. every day of the week. (the standard is
>to backup at the same interval in which it would be easy to re-create
>lost data. For some companies that's weekly, others daily, others
>hourly). Don't let those backups be overwritten for at least 72 hours
>to a week. Yes, a lot of folders. Yes a lot of setting up schedules,
>but what it means is that after a crash, you've got a good chance of
>being able to pop up a really recent copy and get them up and running
>right away.

Oh yeah, I'm hip to this too. I always do rolling backups, lots of
folders and files and whatever don't bother me. In this case I run
them every 12 hours and sprinkle them around the network, caching them
here and there. I just install my freeware file sync utility, set it,
test it, and forget it.

>2. Also have your clones of the most recent version. Once the interim
>backups are in place, you can take the time to import the data into the
>clones, then briefly take down the server and put them in place. The
>result is a much shorter downtime, since the users don't have to wait
>for the import to get the data flowing.

Agreed. The other advantage is, when I get them back online so
swiftly I get to look really really amazing by comparison with their
clueless sysadmin.

>3. Be very VERY careful when working on live files over a remote
>connection. This is the scenario which has caused catastrophic
>corruption and schema-loss when the connection is lost during critical
>operations such as field definition updating. People have reported
>losing their entire Relationship graph, or all the tables, or sometimes
>all the data. Scares the heck out of me, so I rarely do schema changes
>live, even though my internet connection is pretty reliable. Scripting
>changes and layout changes rarely cause this kind of corruption, but
>the rule becomes "RUN A BACKUP IMMEDIATELY BEFORE MAKING ANY SCHEMA
>CHANGES LIVE." That way if the worst happens, you can swap in the
>files from 2 minutes ago.

Well the way I work remotely is a little unusual. What I do is have
them keep a port on their firewall open for me to connect to their
network using VNC. (I never use Windows RDC if I can help it.) That
way I am actually working on the db locally, from a client within
their network, i.e. as if I were actually at their shop in front of
the terminal. If there's an abrupt loss of connection it's not a
problem, because everything's running locally at their shop. I just
reconnect and pick up where I left off.

>Backing up, it's a way of life.

So it is -- a most restorative pasttime too.

--
FW

"Whaddaya mean I don't believe in God? I talk to him every day.
Whaddaya mean I don't support your system? I go to court when I have
to." -D. Mustaine

FileMaker Pro 8.5 Advanced on Windows XP Pro SP2
FileMaker Server 8.0 on Windows 2003 Server R2
 >> Stay informed about: can't "Save a copy as..." of a shared db 

On Aug 2, 3:30 pm, FastWolf <wolfsof....DeleteThis@NOSPAMcomcast.net> wrote:

> I have one very important client, an ambitious Web-based startup
> company.  I've built 2 stand-alone solutions for them for 2 different
> tasks.  One of them is hosted on FM Server 8.  Even though I
> *finished* the assignment a year ago, it has to be considered a work
> in progress because every week they are asking me to make changes and
> add functionality.  I know it's madness to continue major development
> on a solution that's online and live, but that's the deal.

Not at all, this is one of filemaker's key advantages over many other
systems. The ability to patch it live is one of the factors that puts
filemaker on top for many applications. The time savings from not
having to perform data imports can be astronomical, and well worth the
risks.

Even medium sized databases can take days to re-import to an empty
clone.

It would be foolish not to leverage the ability to apply changes to
the live files.

> (Actually,
> my 2 buddies who are Oracle progammers do this all the time, but on
> vast, global corporate systems that are too large to back up.)

Good example. Doing on your work on 'development clones' and then
deploying and importing the live data is actually pretty UNcommon in
most major enterprise database environments where Backup/Restore
operations can take days.

What -is- common, is doing the development in a development set, and
then once its been tested, patching the live system with the same
changes. (This is easy to do in a SQL environment like Oracle, because
pretty much everything can be expressed as a SQL script.) But even in
filemaker, it can be more efficient to develop and document changes,
bug fixes, a complex script, or layout, etc, in a clone, and then
recreate it in the live system once its been tested. (using the import
script, copy and paste, etc, as much as possible.)

Document all your changes, to ensure they are all recreated. (This is
a good practice in general, but is paramount here.)

The recreation might take an hour or two or more; obviously it flies
much faster than the initial development, especially if you've
documented the changes well. And it can be orders of magnitude faster
than doing an import.

> >Incremental clones created from files in use could be subject to
> >corruption, as you might not be aware if and when the server crashes. I
> >would not trust them to be useful in continuing development. My local
> >development files are backed up frequently, and if my computer or the
> >app crashes during development, I discard the current set and retreat
> >to a previous set, recreating the lost work. In this way, I know the
> >files I load up onto the server have never crashed.  It's a bottom-line
> >attempt to prevent any possible corruption.  It's not 100% certain, but
> >is considerably better than using or developing files that have lived
> >on the server for any period of time.

My solution to this, as described above, when patching the live
system, is to do the work twice. Once against the 'never crashed
development set', and once against the 'live system'.

Then in a worst case scenario, you can clone your dev set, and import
the recovered data from the live set into it, and you should be good
to go.

-cheers,
Dave
 >> Stay informed about: can't "Save a copy as..." of a shared db