Server + mysql live backuppen (linux)

[Verwijderd]

Ik heb een server die draait op Linux. Die moet af en toe worden gebackuped.
nu moeten ook de databases (mysql) worden gebackuped en de server moet wel blijven draaien.
Ook moet de backup niet corrupt raken doordat er op het moment van backuppen in de database word geschreven.

Het neerhalen van de database deamon is GEEN optie want dan ligt de server een tijdje plat en dat is niet de bedoeling

Weet iemand hier een oplossing voor

ik heb al op google gekeken en alle oplossingen gebprobeerd niks helpt

ik werk met :

Linux distributie: Fedora core 2
MySQL versie: Degene die zit ingebouwd in Fedora (niks aan veranderd)
backup media: SCSI tape (24gb)

[ Voor 14% gewijzigd door Verwijderd op 17-11-2004 13:18 ]

[Verwijderd]

WAT heb je al geprobeerd dan?

Kan het niet met een simpele mysql dump? Daarmee werkt het hier in ieder geval wel..

[dawuss]

over backuppen zijn boeken vol geschreven, ook in de digitale zin van het woord. Een beetje zoeken maakt je dus al een heleboel wijzer.
Er zijn zo ontzettend veel manieren om backups te maken. De makkelijkste manier is gewoon een off-site tape archive, daarvoor hoef je server niet plat. Als je hierover niets kunt vinden op google, heb je echt niet goed genoeg gezocht, geloof me

Wat betreft de backup van je MySQL database: Daarvoor zal ik je wat tips geven.

• Kijk eens naar mysqldump, dat krijg je standaard bij je mysql installatie
• Kijk eens hoe phpMyAdmin backups maakt, dat kun jij zelf ook.

succes

[CyBeR]

Simpelste is gewoon al je databases dumpen met mysqldump, en dat backuppen.

[Verwijderd]

Misschien handig om te weten (wsl. wist je het al, maar toch...): vrijwel alle databases hebben hele goede mechanismes om inconsistentie te voorkomen. Zoals hierboven al gesuggereerd werd: een mysqldump moet werken, omdat MySQL dan wel zal afhandelen dat je geen "halve" data krijgt.
Overigens zullen er mensen zijn die nu denken: MySQL zuigt wat betreft ACID-support. Klopt. Maar dat doet er nu niet toe. Feit is gewoon dat MySQL er in dit geval voor zorgt dat je geen foute data backupt.

[Verwijderd]

Het moet gaan om een agent die bijvoorbeeld de bestanden van de database tijdelijk gaat excluden en dan aan het eind in een keer in de backup invoegen, dat moet gaan met een programma die alles regelt.

[ Voor 39% gewijzigd door Verwijderd op 17-11-2004 14:18 ]

[blaataaps]

Verwijderd schreef op woensdag 17 november 2004 @ 14:11:
Het moet gaan om een agent die bijvoorbeeld de bestanden van de database tijdelijk gaat excluden en dan aan het eind in een keer in de backup invoegen, dat moet gaan met een programma die alles regelt.

Dat zal allemaal best, maar reageer even op de suggesties van mensen in de thread: /waarom/ voldoet mysqldump niet, als je die uberhaupt geprobeerd hebt.

[dawuss]

Verwijderd schreef op woensdag 17 november 2004 @ 14:11:
Het moet gaan om een agent die bijvoorbeeld de bestanden van de database tijdelijk gaat excluden en dan aan het eind in een keer in de backup invoegen, dat moet gaan met een programma die alles regelt.

Waarom wil je uberhaupt zelf aan de bestanden van je database gaan morrelen als daar al hele mooie mechanismen voor bestaan, die wel zelf zorgen dat er geen inconsistenties komen?

[Verwijderd]

Het is de bedoeling dat de server live gebackupped kan worden. Net zoiets als onder windows met Veritas, waarbij een agent bij houd wat er in gebruik is, en deze skipped totdat de bestanden vrijkomen en ze dan alsnog meeneemt in de backup. De bedoeling is ook dat er met een bootflop een hele backup terug gezet kan worden, vandaar dat een dump niet de beste optie is.

Ik gebruik nu gewoon stbackup en strestore, maar deze skipped dus bestanden met een file-lock er op, ala mysql en apache's files die in gebruik zijn....

[CyBeR]

Verwijderd schreef op woensdag 17 november 2004 @ 14:42:
Het is de bedoeling dat de server live gebackupped kan worden. Net zoiets als onder windows met Veritas, waarbij een agent bij houd wat er in gebruik is, en deze skipped totdat de bestanden vrijkomen en ze dan alsnog meeneemt in de backup. De bedoeling is ook dat er met een bootflop een hele backup terug gezet kan worden, vandaar dat een dump niet de beste optie is.

Ik gebruik nu gewoon stbackup en strestore, maar deze skipped dus bestanden met een file-lock er op, ala mysql en apache's files die in gebruik zijn....

Ja. Dat kun je dus vergeten. De enige manier waarmee die file locks weg gaan is door MySQL uit te zetten. MySQL heeft die files altijd in gebruik zolang ze draait.

[Verwijderd]

Maar is er dan niet een manier om die files te kopieren o.i.d (terwijl ze dus in gebruik zijn) en die te backuppen op de tape naar de map waar mysql normaal z'n files op slaat (/var/lib/mysql dus)???

[dawuss]

Verwijderd schreef op woensdag 17 november 2004 @ 14:45:
Maar is er dan niet een manier om die files te kopieren o.i.d (terwijl ze dus in gebruik zijn) en die te backuppen op de tape naar de map waar mysql normaal z'n files op slaat (/var/lib/mysql dus)???

dawuss schreef op woensdag 17 november 2004 @ 14:36:
[...]

Waarom wil je uberhaupt zelf aan de bestanden van je database gaan morrelen als daar al hele mooie mechanismen voor bestaan, die wel zelf zorgen dat er geen inconsistenties komen?

[CyBeR]

Verwijderd schreef op woensdag 17 november 2004 @ 14:45:
Maar is er dan niet een manier om die files te kopieren o.i.d (terwijl ze dus in gebruik zijn) en die te backuppen op de tape naar de map waar mysql normaal z'n files op slaat (/var/lib/mysql dus)???

Nee. Tenminste, niet zonder risico op corruptie.

[Verwijderd]

Wat bedoel je precies met morrelen?

Als ik het goed begrijp verstaan jullie onder een mysql dump gewoon je db exportern naar een sql file, en die later weer importen, wat ik dus niet wil. Het is de bedoeling dus om live te kunnen backuppen, en deze zonder extra handelingen terug te kunnen zetten. Als het echt niet anders kan, mja dan moet het, maar liever niet natuurlijk.

Voor apache geld in princiepe hetzelfde, is er een manier voor om deze bestanden toch te kunnen backuppen terwijl de server in de lucht blijft?

edit:
Is er dan een manier om deze betanden gewoon te kunnen skippen, ipv gedeeltelijk te laten kopieren (als dat uberhaupt gebeurd). Dan is het mischien een optie om wat regelmatiger een backup te laten draaien en op de één of andere manier controleren of er ééns in de zoveel tijd een backup van die bestanden is geweest ('het backup bitje o.i.d').

[ Voor 26% gewijzigd door Verwijderd op 17-11-2004 14:57 ]

[BoAC]

Heb je hier al rond gekeken?

[Verwijderd]

2 dingen:

1) die filelock op de mysql data bestanden blijft. Of mysqldump(of vergelijkbaar) gebruiken of software zoeken wat wel met locked files kan omgaan.
2) gebruik een filesystem wat snapshots ondersteunt en zet de database hierop. Je kunt dan een backup maken van het snapshot ipv de live data.

[Verwijderd]

wat jij wilt is mysql hotcopy, google daarop en gij zult vinden...

offtopic:
(ligt het aan mij, of is dev.mysql.com plat? owww wacht iedereen is natuurlijk HL2 aan het downen internet is traag )

@ reboot,
dat met een snapshot filesysteem gaat niet helemaal zo simpel werken..
wie zegt namelijk dat je DB files in een consistente staat zijn op het moment dat je het filesystem snapshot maakt?
dus je zult de DB eerst moeten vertellen dat ie al z'n files op disk consistent moet maken,
en dan pas een snapshot maken op FS niveau

[ Voor 102% gewijzigd door Verwijderd op 17-11-2004 16:34 ]

[Verwijderd]

Wat jij wilt heet volgensmij xfsdump. Die kan vanalles doen met dingen die in gebruik zijn. Gebruik anders XFS op een LVM dan kan snapshots maken.

[sebas]

Backups van live databases op FS niveau zijn nogal lastig (tenzij je het op een readonly FS doet ).

Naar mijn weten is de meest nette (en enige?) oplossing inderdaad het dumpen van de databases en het opnieuw importeren als je wilt restoren. Op FS niveau gaat het lastig worden omdat je alleen zeker kan zijn dat de files in een consistente staat zijn als je de MySQL daemon afsluit - wat je dus niet wilt.

[usr-local-dick]

mysqdump kan ook locken hoor, probeer dat gewoon eens.
boeien dat je niet alle data meeneemt.
Als er continue in een db geschreven wordt en je maakt een backup dan is ie per definitie niet up-to-date.

[sebas]

Lastiger wordt het trouwens nog als je applicatie datasets met meerdere queries naar de database wil submitten. Wellicht heeft de applicatie nog geen complete dataset, maar alleen delen naar de database geschreven, in dat geval doe je er goed aan om transactions te gebruiken (zijn volgens mij in MySQL4.x mogelijk). Dit is een aandachtspunt die los staat van de kwestie of je op FS niveau wilt backuppen of door middel van mysqldump.

[CyBeR]

usr-local-dick schreef op woensdag 17 november 2004 @ 18:07:
mysqdump kan ook locken hoor, probeer dat gewoon eens.
boeien dat je niet alle data meeneemt.
Als er continue in een db geschreven wordt en je maakt een backup dan is ie per definitie niet up-to-date.

Klopt, maar 'niet up-to-date' is niet hetzelfde als 'inconsistent'.

[Verwijderd]

Ik denk dat het toch maar een dump moet worden, als er ondertussen data word gescreven moet dat maar in de volgende backup worden gezet.

nu maar zoeken naar een scriptje om makkelijk te kunnen dumpen en weer makkelijk te kunnen importeren. dat kan natuurlijk in cron worden gezet en dan een minuut later de backup. dan gaat alles alsnog vanzelf

edit:

Een scriptje wat alles achter elkaar uitvoert
als je me nodig hebt, ik ben aan het googelen

/edit

[ Voor 16% gewijzigd door Verwijderd op 18-11-2004 14:52 ]

[usr-local-dick]

Er zijn natuurlijk tig manier om mbv mysqldump een backup te maken, hier mijn versie.
Deze dump niet alle databases naar 1 file, maar iedere db naar een aparte.
Das wel zo handig als je maar 1 db moet restoren.
Hier draait ook een database van onze zoek machine. Die is vrij groot (enkele miljoenen records) maar de data is niet belangrijk, aangezien dit snachts opnieuw geindexed wordt. Daarom wordt van die db alleen de structuur gebackupped.

code:

#!/bin/bash
#
# Dick Visser <[e-mail]>
#
# mysqldump can dump all databases, but then you end up with
# one possibly huge dump; restoring a single database is not possible.
# This script dumps all MySQL database seperately, so restoration of
# a single database is much easier.
# It also add statements to add and drop the database.
# Also, you can choose to not dump certains databases, because they
# contain non-important or volatile data (f.i. search-engine data).
BackupDir=/var/lib/mysqlbackup/mysql
passwd="geheim"
date=`date +%Y-%m-%d-%a-%H:%M:%S`

#########################################################################
##  Switch to backup directory and confirm
#########################################################################
cd $BackupDir
rm -f *sql
[ $? -ne 0 ] && echo "Backup directory ($BackupDir) not found. Dump canceled." && exit

########################################################################
## Dump all databases
#########################################################################
for db in $(mysql -p$passwd -e 'show databases;' | egrep -v \(^Database$\|mnogosearch\));
do
        echo -ne "--\n-- Custom dumps\n-- Dick Visser <[e-mail]>\n-- Generated at $date\n--\n" > $db.sql
        echo -ne "CREATE DATABASE /*!32312 IF NOT EXISTS*/ $db;\nUSE $db;\n" >> $db.sql
        mysqldump -p$passwd --add-drop-table --add-locks -aeq $db >> $db.sql
        RETVAL=$?
        [ $RETVAL -ne 0 ] && echo " [FAILED]" && Failed=1
done
# Mnogosearch database only schema - NO DATA
mysqldump -p$passwd --add-drop-table --add-locks -aeqd mnogosearch >> mnogosearch.sql

Om te restore kun je simpelweg mysql < dbname.sql doen.
Als je de hele zooi wilt restoren (bv machine gecrashed, of je wilt een kloon maken), dan moet je beginnen met mysql < mysql.sql want daar staan users en permissies in etc. Vervolgens restore je alles achter elkaar (behalve mysql.sql uiteraard ):

code:

#!/bin/sh
# restore alles
for db in $(ls | grep -v mysql.sql); do mysql -pgeheim < $db; done

edit:
nu ik er weer naar keek bleek er toch nog wat onzin in te staan, en bovendien miste de backup de FOREIGN_KEYS statements - zonder die dingen kunnen backups met foreign keys niet goed gerestored worden....

[ Voor 35% gewijzigd door usr-local-dick op 30-11-2004 15:38 ]

[Verwijderd]

eey bedankt he, ik ga hem even testen en ik meld wel of het werkt (of moet ik nu zeggen, ik meld wel dat hij werkt )

bedankt voor je hulp

USR-LOCAL-DICK

[ Voor 19% gewijzigd door Verwijderd op 01-12-2004 11:47 ]