green123 wrote: » yeah well it was a bit ridiculous anyway so its about time they sorted it lets hope they dont have it at a different time
KTRIC wrote: » It has to occour either way, it doesn't make any difference to the backups when they are done. The mods picked a time when there would be less traffic.
green123 wrote: » surely its possible to do backups without bringing the whole site down every single day ?
Karoma wrote: » Moved from AH with an expiring redirect... 3.6!
green123 wrote: » everyday again ? surely it should be possible not to have to do this everyday ?
seamus wrote: » Expiring redirect? So when the redirect expires it zaps back to AH? Cool!
These are only the two most obvious I can see. I'm sure King Dan knows some more funky trickery to perform superfast live backups.
Gordon wrote: » Cool, expiring redirects! I think that means that the little redirect shortcut notice on the original forum disappears after some time.
Gordon wrote: » It looks like green123 knows much more about backups than you seamus. Maybe green123 can fill the admins in on how exactly to do the backup, or why exactly a backup isn't needed as his knowledge on this matter seems obscenely informed.
green123 wrote: » no need to be such a smart **** i was just saying that surely there must be other ways to do backups without bringing the whole site down everyday and as seamus has pointed out, there are other ways
daveirl wrote: » This post has been deleted.
regi wrote: » We do like the idea of daily backups. Actually, I do plan to build a standby database server that we continually replicate to, but I also like a 100% dump of the DB too.
seamus wrote: » Absolutely. They could not do it, ever. But then the next time something goes bang, we lose a few hundred thousand posts The database gets backed up every day so that we have a copy of all of the posts that were made that day. If you don't do it every day, you risk losing more information. There are a few things that can actuall be done which would offer alternatives; 1. Set up the old server as a mirror. What this does is have the second server watching and copying everything the live server does. A bit like a kid copying his mate's test in school. The great thing about this is that the mirror is always only a few minutes behind the live system. The bad thing about this is that it's not a "backup" solution. It requires regular monitoring and administration to ensure that it's working properly. It's really only for scenarios where you require high-availability and a hot-swappable database server. Anyone using this method on any database, still maintains regular backups apart from the replication cluster. The other great thing about this is, provided you know the mirror is working, then you can do your dumps from the mirror server, leaving the live server free to go on working. 2. Use differential backups instead of full backups. This kind of scenario usually means that a full backup (all data is backed up) is performed once a week, say on a Sunday. Then every evening after that, only the changed data is backed up. This means that with the exception of the Sunday night backup, each night's backup should be pretty quick. I'm not sure if MySQL provides this though. The main problem with this is the time it takes to do a restore. If the database dies on Friday afternoon (for example), you need to restore the Sunday night backup, then the monday night one, then the tuesday one, and so on. You'd have to do about seven individual restores to get you back to a working situation. If you do a full backup nightly, then you only need to do two (database & TLog) to get you back to a working state. With admin time at a premium, this would be a pain. These are only the two most obvious I can see. I'm sure King Dan knows some more funky trickery to perform superfast live backups.