And still, nobody answered the man's actual question: can a Linux mysqld read mac datafiles ?
I'd say "make a copy and try it". As long as you always keep a copy of the original files, you're not risking anything. You might run into things varying from incompatible MySQL versions to different endianness on your files - I don't know. Try and you'll see. Worst case scenario, get an identical mac with an identical mysql and copy the files to that. On Fri, Sep 10, 2010 at 10:57 AM, Joerg Bruehe <joerg.bru...@oracle.com>wrote: > Hi George, everybody! > > > George Larson wrote: > > We do nightly backups at work just by taring the mysql directory. In > > my environment, that is /var/lib/mysql. > > > > Like this: > > > > service mysql stop > > cd /var/lib/mysql > > rm -rf * > ^^^^^^^^ > For your own benefit, I hope you don't do that on the machine on which > the (primary) DB server is installed. > > > tar zxvf file.tar > > rm -rf ib_logfile* > > chown -R mysql.mysql > > service mysql start > > The above procedure may work on a backup machine, to which you transfer > a "file.tar" which contains a database snapshot. So it is a recovery/ > restore procedure, not the save/backup part. > > Assuming the data are below /var/lib/mysql on the broken machine, and > that disk is mounted as /mnt, this would be like: > > cd /mnt/var/lib/mysql > tar czvf /tmp/file.tar . > > Take care not to damage that disk, or to use it for any other purpose, > until you have verified that your new database server could successfully > read and use all those data (do thorough checks!), and taken a full new > backup from it. > > In general, I do not recommend to use file backups for a database, but > rather to use the database means (backup, dump, ...). However, after > your database machine broke, this isn't so easily possible. > > > > > Something similar might work for you. Somebody with more MySQL > > expertise than me can probably help you customize the process to your > > environment. > > > To the original poster: > I know it sounds very hard and seems to ignore your trouble, but still: > A typical reply in DB support is > "If you have no backup, your data obviously are not important." > > Everything can fail, both hard- and software: if your data are valuable, > you need a backup which is separated from the machine your data are on. > "Separated" might be an external disk that gets switched off, a tape > that is removed from its drive, another machine, just anything that > won't suffer even if your database server breaks terribly. > (To prevent questions: Mirrored disks or RAID systems are no backup, as > they are not separated.) > > If backup is to external disk, my personal policy is to have at least > two of these, used in alternation: If total disaster strikes while one > is mounted and being written to, and that disaster affects all mounted > disks (data and current backup), I still have the previous backup. > Given current disk prices, one sleepless night will cost you more than > the second disk. > > How often you do this backup is a decision you have to make yourself, > based on your update frequency and the possibility/cost to repeat the > changes that occurred since the last backup. > > > Regards, > Jörg > > -- > Joerg Bruehe, MySQL Build Team, joerg.bru...@oracle.com > ORACLE Deutschland B.V. & Co. KG, Komturstrasse 18a, D-12099 Berlin > Geschaeftsfuehrer: Juergen Kunz, Marcel v.d. Molen, Alexander v.d. Ven > Amtsgericht Muenchen: HRA 95603 > > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: http://lists.mysql.com/mysql?unsub=vegiv...@tuxera.be > > -- Bier met grenadyn Is als mosterd by den wyn Sy die't drinkt, is eene kwezel Hy die't drinkt, is ras een ezel
