|
FreeBSD General Other questions regarding FreeBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
|||
Disaster recovery best practices
I am looking for a disaster recovery method whereby the full system is backed up ready to be restored to a new system. In the Windows world there are a variety of tools that can take an image of the entire system, making the restore a one step procedure and short time to a fully recovered system.
Does such a method exist for FreeBSD (likely not)? If not, dump and restore appears to be the mostly suitable candidate. But the online resources I've found are generally incomplete or vague. Questions like how to script the snapshot portion of the backup along with temporary database server shutdown to get clean DB backups and minimize DB downtime are still missing. Does such a Disaster Recovery document exist? Does someone have a method they use and would care to share? Should I be looking at a different method altogether? |
|
|||
the shareware BootIt $35 or so (installable to a windows, and
maybe to its own partition, as well as to cd-r) is a multiboot tool (supplanting GAG, maybe Grub, maybe the BSD bootloader) which can backup FS as images (even multiple-ly in BATCH mode) opensource equivalents exist. ........... no recc. per se on that as a Server solution as I have no experience in it. But the freebsd-questions maillist archives have had many discussions relevant to your question. |
|
||||
I'm not a professional user of FreeBSD (as my job doesn't entail computers :-() but I would guess that the closest documents to it would be the handbook, dump manual, and sh manual. Depending on dumps output and the situation at hand it might be possible to take down the DB until the snapshots finished and then bring it back online through a script.
Depending on your situation you could probably use some form of database replication, i.e. one database servicing clients and another 'slave' database that is periodontally brought into sync with the master. And set things up so that while one database goes offline during a dump, the other is rotated into servicing requests. And then sync the slave with the master before bringing it back online At least, if maximizing database uptime was *my* primary concern that is the kind of thing I would look at trying to do. Cheers.
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
|||
The best disaster recovery scheme I can recommend to you is to back up your data religiously, in addition to this I highly recommend that every body whom has nay highly sensitive data on their hard drive envest in a network attached storage device.
__________________
Google Linux is a Green Horns Best Friend (GHBF). Windows = a 32 bit extensions to a 16 bit patch to an 8 bit operating system originally coded for a four bit processor written by 2-bit monopolistic software company founded by a .3-bit Harvard Drop out, who can't stand one respectable bit of competition. If I believe something to be immoral a will not keep quite and let my voice of annoyance be heard loud and clear. |
|
|||
Hi all,
Lets say the disaster recovery process is not implemented and a blackout hits. And after the blackout a 2.3Tb RAID5 array on a RocketRAID 2030 no longer mounts. mount /dev/da2p1 says that the filesystem is dirty and to try fsck... fsck cannot determine filesystem type... fsck_ffs looks like it worked, but when I try to mount it again it says operation not permitted... What would you do? I am dying here! |
|
|||
sorry I meant a RocketRAID 2320.
|
|
|||
I tried mounting it read only and it worked like a charm
|
|
||||
... I just wonder, rsync(1) is great for backup, but restore is only one way 'stream' without checking for file contents changes etc. so using 'raw' tar(1) pipe should make the restore a lot faster (especially if there are a lot small files):
backup_server # tar -cf - /servers/host | ssh -c blowfish root@host "tar -C ~/mnt -xpf -" ... and with really good compression for slow networks: backup_server # tar -cf - /servers/host | gzip -9 -c | ssh -c blowfish root@host "tar -C ~/mnt -xzpf -" ... even better then gzip(1) with xz(1): backup_server # tar -cf - /servers/host | xz -9 -c | ssh -c blowfish root@host "xz -d -c | tar -C ~/mnt -xpf -"
__________________
religions, worst damnation of mankind "If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus Torvalds Linux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”. vermaden's: links resources deviantart spreadbsd |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Backup strategies and disaster planning | sherekhan | OpenBSD General | 20 | 24th February 2021 11:21 AM |
data recovery. | LateNiteTV | FreeBSD General | 8 | 29th August 2008 08:11 PM |