php sciprt kørt som cronjob?

Prøv at køre det manuelt og se om det virker
Har du husket at genstarte cron, hvis det er i en global crontab fil (som fx /etc/crontab)?

jeg tror jeg ville bruge wget til at kalde php-scripts med (tager en url). men det forudsætter at backup.php kan ses fra din webserver.

det kan også være at du skal have den fulde sti til php før det virker.

prøv evt at lave

30 7 * * * php /home/.sites/75/site8/web/dbadmin/system/backup/backup.php >/tmp/script.out 2>/tmp/script.err

(i een linie). Du vil nu kunne se hvad fejlen er ved at kigge i filerne i /tmp

fsconsult: Til et backup system, der kan tage lang tid at køre færdigt, er det mere velegnet at bruge cli udgaven af php. Ellers skal man bl.a. til at rode med diverse timeouts, for ikke at tale om sikkerhed så folk udefra ikke kan køre det.

Men behøver det nødvendigvis at være et php script?

Et eller andet sted har du php cli version installeret.  Find den (type -p php eller which php) og
brug den:

30 7 * * * /fuld/sti/til/php -f /home/.sites/75/site8/web/dbadmin/system/backup/backup.php

Hvis jeg køre nedenstående manuelt så virker det, men ikke med > dev/null

php /home/.sites/75/site8/web/dbadmin/system/backup/backup.php

Jeg kan ikke bruge wget da php filen der skal køres ligger i et .htaccess beskyttet område

Det behøver ikke nødvendigvis at være et php scirpt, det var bare det første jeg faldt over.

xyborx> god pointe :-)    bruger normalt også shell scripts til backup (og mysqldump).

straszek> hvad laver dit backupscript?  hvad tager du backup af?

er der nogen der har et andet forlslag til et scirpt der kan køres fra cron så modtages forslag gerne

Det er backup af mysql, som så skal uploades til en anden server

hmm.. > /dev/null burde ikke påvirke hvordan det kører. Det gør bare at (næsten) alt hvad der normalt bliver skrevet på skærmen bliver ignoreret (sendt til /dev/null). Så slipper du for en mail fra cron hver gang scriptet kører med lidt ligegyldigt tekst.

straszek> hvad med et shell script der kalder mysqldump (og evt. tar) og så laver ftp af filen til en anden server?

Til backup af mysql kunne du bruge mysqldump. Et simpelt lille shell script på et par linier kan nok klare det :) Skal det bare tage en komplet backup af alt?

jeps backup af alt

straszek> hvad med et shell script der kalder mysqldump (og evt. tar) og så laver ftp af filen til en anden server?

Ja lige netop

/usr/bin/mysqldump dbnavn > dbnavn.sql
tar czf dbnavn.tar.gz dbnavn.sql

Jeg har mange databaser(23) hvordan laves der et samlet dump af dem alle , og hvad med ftp?

#!/bin/bash
# Komplet backup af databasen

# Til en fil (backup.sql)
mysqldump --all-databases --password=noget > backup.sql

# Eller til en anden server (kræver ssh med hostkeys for at undgå password)
mysqldump --all-databases --password=noget | ssh bruger@backup-server 'cat > backup.sql'

# Der er sikkert en smartere løsning end at skrive mysql passwordet lige der
# hvor folk kan bruge ps til at opsnappe det..

#!/bin/sh
#
# Backup of /home/site
#
# This script takes simple .zip backup of all MySQL databases.
#
EXPORTNAME=dbbackup.zip
USER_GROUP="myuser.mygroup"
CONFFILE=/etc/local/sitebackup.cnf

DBASES=$(echo "show databases;" | /usr/bin/mysql --defaults-extra-file=$CONFFILE | grep -v Database)
if [ -z "$DBASES" ]; then
  echo No databases available
  exit 0
fi
DIRNAME=dbbackup-$(date "+%Y%m%d")
mkdir -p $PATHNAME/$DIRNAME
cd $PATHNAME/$DIRNAME

#echo Data: $DBASES
for i in $DBASES; do
  /usr/bin/mysqldump --defaults-extra-file=$CONFFILE --opt $i > ${i}_db.sql
done
cd ..

/usr/bin/zip -q -r ${DIRNAME}.zip $DIRNAME/*
chown $USER_GROUP ${DIRNAME}.zip
rm -Rf $DIRNAME

sitebackup.cnf:

[mysqld]
user=mybackup
password=4484be9d77c4ef09d73053c6594a767d

[mysqladmin]
user=backupuser
password=userpassword

[mysqldump]
user=backupuser
password=userpassword

[mysql]
user=backupuser
password=userpassword

# This will be passed to all mysql clients
[client]
password=userpassword
port=3306

DAMN!

Man kan også zippe på en anden måde:
mysqldump .... | zip > backup.sql.zip
eller
mysqldump .... | zip | user@backup-server 'cat > backup.sql.zip'


Det kan så restores med noget i retning af
unzip -p - | mysql ....
eller
ssh user@backup-server 'cat backup.sql.zip' | funzip | mysql ....

Pipes er sjove ;)

xyborx> ja man kan pipe mellem mysqldump og zip (kunne også have brugt tar).

mit script laver dog først et dump pr. database, og zipper så alle dumps zammen til en zip fil  ;-)

Jeg har forsøgt med nedenstående, og det virker tildels. backupfilen bliver lavet på source maskinen, men når den bliver uploaded på target maskinen er den tom. Scriptet spørger også efter passwordet til target maskinen  som jeg må indtaste manuelt, og det er jo ikke optimalt når det skal køre som cron job

mysqldump --all-databases --password=noget > backupd.sql | ssh backup@192.168.3.3 'cat > backupd.sql'

Passwordet kan du undgå vha hostkeys. Prøver lige om jeg kan huske det.. :)

Du opretter et sæt private og public keys vha:
ssh-keygen -t rsa
Når den spørger efter et password, trykker du bare enter (intet password)

Herefter skal den uploades til serveren. Til det plejer jeg at bruge (tilpasset til din user@host):
cat ~/.ssh/id_rsa.pub|ssh backup@192.168.3.3 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'
Det skulle så gerne være sidste gang du behøver password når du logger ind på den maskine via ssh :)

Iøvrigt har jeg også hørt rygter om at passwords til ssh kan sniffes, og hostkeys derfor er sikrere. Det password man kan indtaste til en hostkey bruges til at (de-)kryptere hostkey'en, og sendes derved ikke over netværket. ~/.ssh/id_rsa.pub (public) kan lægges på alle de maskiner hvor du gerne vil benytte det sæt hostkeys. ~/.ssh/id_rsa er derimod den private del, som du skal passe på at andre ikke får fingre i.

Hov, spottede lige fejlen i den linie du kører. En "> backup.sql" for meget:
mysqldump --all-databases --password=noget| ssh backup@192.168.3.3 'cat > backupd.sql'

nu har vi efterhånden langt overskredet det grænse hvor jeg fatter ret meget af hvad der foregår.

Jeg har kørt ssh-keygen -t rsa (fra source maskinen)
det gav dette output

Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
7a:93:b9:c4:08:4d:e5:b7:ae:9c:b6:a2:ab:88:f0:80 root@www.xxx.dk

Så kørte jeg:
cat ~/.ssh/id_rsa.pub|ssh backup@192.168.3.3 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

Hvorefter jeg bliver spurgt efter backup's password til 192.168.3.2, det indtastede jeg så.

så forsøgt jeg at køre:
mysqldump --all-databases --password=noget > backupd.sql | ssh backup@192.168.3.3 'cat > backupd.sql'

og jeg bliver stadig bedt om password til 192.168.3.3, ligsom den uploadede fil stadig er tom.

ok jeg havde ikke set:
<Hov, spottede lige fejlen i den linie du kører. En "> backup.sql" for meget:
mysqldump --all-databases --password=noget| ssh backup@192.168.3.3 'cat > backupd.sql'

Nu er filen ikke længere tom, men stadig bliver jeg spurgt efter password

prøv at ændre

cat ~/.ssh/id_rsa.pub|ssh backup@192.168.3.3 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

til

cat ~/.ssh/id_rsa.pub|ssh backup@192.168.3.3 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys2'

såvidt jeg husker laver "ssh-keygen -t rsa" nemlig en ssh2 nøgle.

Jeg bliver stadig spurgt om password til backupserveren

er det muligt at flette passwordet ind i mysqldump --all-databases --password=noget| ssh backup@192.168.3.3 'cat > backupd.sql'

?

Oh, det er måske permissions på nøglen der er for åbne (my most common mistake #2)

chmod go-rwx -R ~/.ssh
ssh backup@192.168.3.3 'chmod go-rwx -R ~/.ssh'

COOL nu virker det

Smider du ikke et svar xyborx.....

Og se så lige http://www.eksperten.dk/spm/525789  hvis i har tid

ok :)

Iøvrigt står der noget i manualen til ssh om at man skal bruge -n for at ssh kan køre i baggrunden. Dvs, hvis du får problemer med at der ikke bliver taget backup fra cron jobbet, så kan du prøve at ændre det til
mysqldump --all-databases --password=noget| ssh -n backup@192.168.3.3 'cat > backupd.sql

Det er noget med hvad ssh accepterer som standard input. Dvs når man kører det i en normal terminal, fungerer det fint, men ligeså snart man kører det i baggrunden fungerer det ikke. Jeg ved så ikke hvordan det er når man bruger ssh til at overføre data på den måde, så brug kun -n hvis det ikke virker ellers.

iøvrigt benytter man (jeg) normalt scp til at kopiere filer med (det kører over SSH)

Jeg har store problemer med at få det til at virker. Det virker fint nok, når jeg køre det manuelt, men som cron job sker der ingen ting - jeg ved ikke rigtigt hvor jeg skal fejlsøge?!

Jeg har lavet en fil mysqlback.sh der ser sådan ud(og jeg har prøvet både med og uden -n:
#!/bin/sh
mysqldump --all-databases --password=noget | ssh backup@192.168.3.3 'cat > mysqlbackup.sql'

så har jeg lavet en domysqlback.job fil med følgende indehold:
18 13 * * * /etc/mysqlback.sh

og til sidst har jeg skrevet crontab domysqlback.job

Hvor skal jeg lede efter fejlen?