Bekijk Volledige Versie : Tabel database verwijdert- hoe terughalen ?
Heb met mijn vingers aan de verkeerde knoppen gezeten en per ongeluk een hele tabel verwijdert ipv 1 record.
Mijn hoster bied weliswaar backups aan maar er is misschien een andere manier om deze tabel terug te halen? Aangezien het een redelijk gevuld reseller pakket is en ik alleen deze site/database terug wil.
Betreft directadmin.
marsipulami
04/02/10, 12:13
ik neem aan dat de hoster backups heeft per account. Gezien het feit dat hij backups aanbied?
een andere manier zou ik niet weten
Denk het wel want ik krijg diverse opties te horen, maar ben ook wel benieuwd of er niet een soort van recovery ingebouwd zit, of denk ik verkeerd?
Voor zover ik weet niet. Ik zou gewoon (buiten dat je zelf af en toe een backupje draait voor de veiligheid, zeker als je dingen verwijderd ;)), even met de hoster overleggen.
De hoster kan ook enkel 1 account terugzetten hoor ... of misschien zelfs enkel de database (maar dat heb ik nog nooit hoeven doen, een enkel bestand wel)
Ja dat van die backup is helemaal waar. Is dit makkelijk te automatiseren? Sites heb ik wel maar geen databases.
Ik schoon regelmatig de records op, kan dat ook geautomatiseerd worden? foutje zit in een heel klein hoekje besef ik.
Gewoon even contact opnemen met je provider. Als je geluk hebt kan hij je een restore aanbieden op tabel niveau. Maar dan moet hij geen gebruik maken van de backups uit DirectAdmin zelf (wat 90% waarschijnlijk wel doet).
SQL backups kun je zelf automatiseren, maar doe dat in overleg met je provider wanneer het forse backups (kunnen) zijn. Zodoende belast je de server niet wanneer het niet nodig is misschien.
Heb inmiddels een database backup ontvangen van de hoster dus probleem is opgelost, nu de oorzaak nog even zien te voorkomen ;-)
marsipulami
04/02/10, 12:53
Maar dan moet hij geen gebruik maken van de backups uit DirectAdmin zelf (wat 90% waarschijnlijk wel doet).
met een beetje inspanning kan je dan nog wel een restore op tabel niveau. Kost alleen even inspanning om die backup door te spitten.
Maar goed probleem is opgelost mooi zo
Is dit makkelijk te automatiseren?
Maak een bestand "mysqltablesbackup" met het volgende script:
# backup all mysql tables to single files
#
# usage: mysqltablesbackup username password database [quiet]
LOCATION=/usr/local/bin/
if test $# -eq 0; then
echo "usage: $0 username password database [quiet]"
exit 1
fi
USERNAME=$1
PASSWORD=$2
DATABASE=$3
QUIET=$4
if test -z $USERNAME; then echo "no username"; exit 1; fi
if test -z $PASSWORD; then echo "no password"; exit 1; fi
if test -z $DATABASE; then echo "no database"; exit 1; fi
TABLES=`echo "show tables" | $LOCATION/mysql $DATABASE --user=$USERNAME --password=$PASSWORD --skip-column-names`
for TABLE in $TABLES; do
if test -z $QUIET; then echo -n "$TABLE"; fi
FILENAME="$DATABASE"_"$TABLE".sql
$LOCATION/mysqldump $DATABASE --user=$USERNAME --password=$PASSWORD --compact --table "$TABLE" > $FILENAME
LINES=`cat $FILENAME | wc -l`
if test -z $QUIET; then echo " $LINES lines"; fi
done
Roep dit aan via een automatische cron job:
* 5 * * * cd /home/USERNAME/backup; sh /home/USERNAME/mysqltablesbackup username password database
Je moet natuurlijk wel de goede plaatsen en gegevens invullen. De cron job kun je via het control panel invoeren.
Met mysqldump zelf kun je natuurlijk ook een grote dump van alle databases en tabellen maken, maar dit kun je gebruiken voor losse tabellen. Iedere nacht wordt iedere tabel in een eigen bestand gedumpt, maak je een foutje dan kun je die dag met phpMyAdmin makkelijk een oude tabel terugzetten.
Geweldig, hier ga ik mee aan de slag.
:lovewht:
Om het helemaal fancy te maken kun je de volgende uitbreiding gebruiken om een historie voor iedere dag van de week bij te houden:
DOW=`date +%u`
FILENAME="$DATABASE"_"$TABLE"_$DOW.sql
En met "gzip --no-name" maak je rsync-vriendelijke gecomprimeerde backup files:
$LOCATION/mysqldump $DATABASE --user=$USERNAME --password=$PASSWORD --compact --table "$TABLE" | gzip --no-name > $FILENAME.gz
johan.smits
05/02/10, 15:58
maak voor beheer een gebruiker aan die enkel select,update,insert,delete rechten heeft.
Dus geen rechten om tabellen aan te passen etc, kun je nooit de structuur om zeep helpen.
Echter DELETE FROM `tabel` WHERE 1 kan alsnog een probleem vormen.
Database backups zijn essentieel zo blijkt maar weer.
Database backups zijn essentieel zo blijkt maar weer.
En een hoster die z'n zaakjes op orde heeft ook.
Tussen mijn eerste mail en de mail dat de backup klaar stond in mijn account zaten 23 minuten. Daar kunnen nog veel bedrijven van leren denk ik.
En dat mag dan ook gezegd worden. Ze bestaan gelukkig nog :lovewht:
Zou ook aan je hoster vragen of de binlog aan mag.
Dan worden alle mutaties apart opgeslagen, en kan je indien je per ongeluk iets dropt ook de data die sinds de laatste backup toegevoegd is terug krijgen.
Zou ook aan je hoster vragen of de binlog aan mag.
Het zegt mij allemaal niet veel maar als ik de mail goed begrepen heb was dit wel een optie. Maar er missen geen mutaties sinds de laatste backup dus feitelijk geen schade. En dan is het in mijn ogen niet noodzakelijk om daar nog meer tijd dan nodig in te steken.
Ik ga nu eerst eens met het script hierboven aan de slag.