• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Scheduled backup + files store
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Scheduled backup + files store


  • Subject: Re: Scheduled backup + files store
  • From: Kieran Kelleher <email@hidden>
  • Date: Wed, 13 May 2009 17:02:51 -0400

Hi Flor,

Not sure if this idea help, but for backups, I backup 2 of our 3 replication slaves every night using a launchd backup shell script that runs at 3am every night. So we never interrupt the master database.

I don't use FrontBase, I use mysql, but this strategy might work for any database engine I would think.

Depending on your situation, you can use even a Mac Mini with 4GB RAM as a dedicated replication and backup slave.

Regards, Kieran


On May 13, 2009, at 4:25 PM, Stamenkovic Florijan wrote:


On May 13, 2009, at 15:58, Guido Neitzer wrote:

On May 13, 2009, at 12:42 PM, Stamenkovic Florijan wrote:

1. Refuse or delay the transfers of files to the server at a particular time of day when the backup is happening. This is sloppy, I don't want to do it.

This is what I do at the moment. Not the best solution though.

2. If I first perform the database backup, and afterwards backup the files (delay it a bit), the only risk I run is that I have a file too many in my file storage. This could be acceptable if I tweak my server-side file writing to overwrite without asking.

This is not true, if your users can also delete files. You might end up with a backup that refers to files that were deleted during the backup run.

They can't. We have a simple increment-only file storage system, where file names are FileRecord (db) IDs. So, I think that in our situation this should be an acceptable solution. What do you think?


Is there a better, standardized way of doing this?

Hmm. I could think of triggering an rsync to file system clone when you also trigger the db backup. If you do the rsync part really often (so that only minimal changes need to be transferred each time), you should have a pretty good snapshot of the file for the time when you start your db backup. Now, during the db backup you can stop the rsync process so changes happening during the db backup will not change your FS structure.

Yeah, that sounds OK. However, not sure I need to do that, if the above mentioned works...


F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden

_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
References: 
 >Scheduled backup + files store (From: Stamenkovic Florijan <email@hidden>)
 >Re: Scheduled backup + files store (From: Guido Neitzer <email@hidden>)
 >Re: Scheduled backup + files store (From: Stamenkovic Florijan <email@hidden>)

  • Prev by Date: Re: Scheduled backup + files store
  • Next by Date: Re: WebObjects 5.3 Leopard
  • Previous by thread: Re: Scheduled backup + files store
  • Next by thread: Wonder Validity or Custom Validation
  • Index(es):
    • Date
    • Thread