mac Moving backup directory = missing Remote Container files?

[Justin Close]

I went through a process of trying to move our backup directory; the current one is on the same volume as the live file.  But, this might really be a problem with my understanding of hard links and remote container data.   FMS12.03, Mac OS X Server 10.6.8.  FMP client 12.01 (running on the server); live hosted file tested from FMPA client 12.03 running on Mac OS X 10.6.8.

I made the new directory on the other volume, changed permissions, modified the path shown in the FM Server Admin console (hitting Validate to verify - it was good).  In order to try and keep things in the same place, I then COPIED all the current backups from vol1 to the new location in vol2.  No real problems there.  I then changed the schedules (rather, I created copies of the originals and edited the copies, giving them new names) to also point to the new path.  (Apparently the path defined in the console config is only a default?)  I also left both sets of schedules running (old path and new path backups) just to be sure I had the new ones going correctly before altering the old ones.

So, this morning, I checked on things.  I have a variety of new backups in the new location.  I made a COPY of one of the new backedup files (including the entire RC_Data directory) and pasted that to a temp directory on the desktop of the server.  (So far, all of this has been done via screenshare to the server.)  The file opens OK, and there is plenty of data there.  However, when I go to a layout that shows some of this remote container data, it gives me a placeholder image saying "file missing:  filename.ext"

I copied a different set of files/RCfolder from an earlier backup, same thing.  I copied a set of backup files from Vol1 volume (i.e. the original backup directory and schedules that I hadn't messed with) and got the same results:  no remote container data showing up.  I then copied the LIVE file and RC_Data, same result:  no RC data showing.  When I go to the hosted live file from my remote machine, I see RC_Data just fine for this same record (I have been checking the same record each time).  Whew! 

So…instead of trying to unwind the various things I have done, perhaps it is just best to tell how to best MOVE a backup directory, or rather, switch the directory that the server is using for backups.  Or maybe the move part was fine, and it is merely my method of testing and verifying the move that is wrong.  I was thinking that it was a problem with the way the RC_Data hardlinks were being handled (or my perception of them - I thought if I made a COPY of the backups, that I would get a full real copy of the originals).  

Any suggestions would be appreciated.

Thanks,
J

[Steven H. Blackwell]

I would strongly recommend that you review the series of articles about FileMaker Server 12 that Wim Decorte and I prepared.  I believe these will answer many of your questions.

 

You can find them here and again here in the BLOG section of FM Forums.

 

Steven

[Justin Close]

Steven,
   Thanks for posting those links again; I had read them previously, but went ahead and read through them again (or at least the Backup FAQ, and the Server Backup narrative doc).  However, they didn't really address or answer my questions.

I found one concrete answer (to #1 below) to my two primary questions:
1)  Why was the external container data apparently going missing when I opened the backup copies locally?
2)  Why was the backup path defined in the server config not really the path that is used by the schedule?

Answer to #1:
    The path that the file uses to find the RC data files is different, based on whether the file is hosted or opened locally.  If you open a hosted file, the default path is "[hosted location]/Some/Path", while when you open the a backup copy of that file locally, the path is "[database location]/Some/Path".  Apparently, the server will translate the "[hosted location]" version into /Databases/RC_Data_FMS/Some/Path", while when you open the file locally you get the result of "/BackupDir/Some/Path".  The server inserts the "/RC_Data_FMS/" portion of the path.  This folder is valid when being hosted, and when a backup is made, it creates the same folder structure (i.e. "/Databases/RC_Data_FMS/Some/Path").  But when the file is opened locally, that path is now invalid; if you move the folders to be "/Databases/Some/Path" when opening it locally, it will work OK.

#2:  The partial answer here is that the path defined in the schedule itself appears to be what is used.  When you create a NEW schedule, it does auto-populate the path with what you define in the Server config (under 'Database Server -> Folders'), but doesn't force you to use it.  When doing Progressive Backups, though, this is the only place the path is defined, so that IS what is used.


One further bit of information I gleaned in this exploration, which was hinted at in the documents you posted, is that if you copy a whole directory structure of hardlinks, each of those hardlinks becomes a full blown copy of the original file.  When I copied my backups folder from the old path on Vol1 to the new path on Vol2, I got an increase in overall size of about 50%.   
    That is using the Mac OS X Finder interface; I found some references to commands that can be used that will honor and maintain hardlinks when copying them.  I didn't try them, though.  Our overall size will decrease as the "Keep…" limit is reached and newer hard-linked copies become the norm.

Thanks,
J

 

[Justin Close]

Oh bloody hell. My apologies Steven. You and Wim DID cover my questions in your Narratives that you linked, but I just didn't see the file (it was the bottom of the list when sorted alphabetically, and I had seen the FMS12_Backups.pdf file at the top...kind of stopped looking I guess ) . The pertinent file: FMS12_RemoteContainers.pdf

That document covers the paths and locations for various storage of external container data under both the local vs. served versions of a file. If only I had happened to read the ENTIRE directory structure of your archive!

Sheepishlly,

-- J

[Steven H. Blackwell]

The important thing is that you did read the papers and hopefully are well on your way to maintaining a stable deployment. I am glad we could help you with this.  It is a complex topic, and that's one of the principal reasons we did the papers.

 

Steven