Bekijk Volledige Versie : Directadmin en backup
ik heb mijn directadmin nu zo ingesteld dat er van elke dag een backup op een externe locatie komt te staan als test gedaan. echter op willekeurige dagen voert hij de backup gewoon domweg niet uit, en geeft dan ook geen errors.
enig idee waar dit aan kan liggen ?
ik gebruik versie 1.345 van directadmin.
Als het niet wordt uitgevoerd, en je hebt geen error's dan is er simpelweg geen opdracht....
Dus:
- wat heb je als opdracht gegeven?
- wat staat er in de log?
Yourwebhoster
25/01/10, 22:39
Kijk zoals Geert-Jan al zegt in de log, en controleer of je alles goed ingesteld hebt.
marsipulami
25/01/10, 22:39
wellicht heb je de cronjob niet helemaal goed ingevuld, zou je deze eens kunnen plaatsen?
weet je wat het gekke is,
per dag heb ik hem ingesteld, dus een cron voor maandag, een cron voor dinsdag enz. 7 crons dus.
de zondag werd nooit uitgevoerd, dus dat moest een 7 zijn ipv een 0.
de ene keer doet ie vrijdag wel, de andere keer doet ie dat niet. soms slaat hij dinsdag over.
de crons opzich werken dus ook wel, en staan ook keurig in DA. en ze zijn allemaal wel een keer uitgevoerd.
welk log moet ik bekijken of het goed is uitgevoerd ?
marsipulami
25/01/10, 22:56
kan gewoon in directadmin geloof ik bij logs. En even de het hoofdemailaccount controleren van de user die de crons uitvoerd. misschien dat daar wat informatie staat.
Zit er geen bepaald ritme in dat het niet werkt?
staan in de cronjobs de sterretjes wel goed? soms een simpele spatie te veel of een sterretje te weinig kan al grote gevolgen hebben
bij het bekijken van de backups staan de sterretjes , en dan ook alleen * bij maand en dag van de maand.
de minuten heb ik op 0 staan , de uren tussen 1 en 24
de dag van de week is afhankelijk van de backup en staat ook op 1 t/m 7
ik snap er gewoon niks van.
de admin email account is gewoon leeg, ook geen foutmeldingen.
ik houd het eens bij op welke dagen hij het vooral doet.
waarom maak je eigenlijk 7 crons aan i.p.v. 1 ?
Zet bij de dag van de week een *
En kijk eens in het cronlog
om iedere dag in een aparte map te zetten zijn 7 cronjobs helaas een makkelijkere oplossing dan 1 job en daarna de backup verplaatsen. Directadmin is daar nog geen ster in imho.
Kan je de volledige regel uit je crontab eens posten? En inderdaad een stuk log op een moment dat hij had moeten draaien. +- 10 min ofzo :)
om iedere dag in een aparte map te zetten zijn 7 cronjobs helaas een makkelijkere oplossing dan 1 job en daarna de backup verplaatsen. Directadmin is daar nog geen ster in imho.
Zelf scriptje voor schrijven :) Hebben we hier ook om alles 14 dagen te bewaren ;)
Zelf scriptje voor schrijven :) Hebben we hier ook om alles 14 dagen te bewaren ;)
Bedrijfsgeheim of even posten :)
Yourwebhoster
26/01/10, 12:09
Bedrijfsgeheim of even posten :)
Of je zoekt, er was namelijk al een topic hierover met een voorbeeld (niet getest):
Dit is even snel uit het hoofd, je zal em even na moeten lopen etc..
DATE=`date +"%y-%m-%d"`
mkdir /home/admin/user_backup-map/$DATE
mv /home/admin/user_backup-map/*.gz /home/admin/user_backup-map/$DATE
Met wat toevoegingen kan je hier nog wat moois van maken.
Bedrijfsgeheim of even posten :)
Hehe, bij deze dan :)
#!/bin/bash
DATA="/home/admin/user_backups"
DESTINATION="/home/backups"
if [ -f "/root/backup.pid" ]
then
echo "Backup already running ..." >> /root/backup.log
else
touch /root/backup.pid
/sbin/pidof -s backup.sh > /root/backup.pid
echo "Starting backup @ $(date +%d-%m-%Y) $(date +%H:%M:%S) !!!" >> /root/backup.log
cd ${DESTINATION}
mkdir $(date +%d-%m-%Y) >> /root/backup.log
mv ${DATA}/* ${DESTINATION}/$(date +%d-%m-%Y) >> /root/backup.log
echo "Backup finished!" >> /root/backup.log
exit 1
fi
rm -rf /home/backups/$(date -d 'month ago' +%d-%m-%Y)
echo "Backup month ago deleted!" >> /root/backup.log
rm -rf /root/backup.pid
En dan laten syncen op de /home/backups naar een andere server toe.
Ik doe het echter weer anders. Ik download de backup met een Wget voordat de backup (@ lokale server) in een andere map wordt opgeslagen.
Daarvoor zie hieronder het script.
#!/bin/bash
echo "Starting backup @ $(date +%d-%m-%Y) $(date +%H:%M:%S) !!!" >> /ro$
cd /home/backups
mkdir $(date +%d-%m-%Y) >> /root/backup.log
cd $(date +%d-%m-%Y)
wget -r ftp://admin:Pass@domain.com/user_backups >> /root/backup.log
echo "Backup finished!" >> /root/backup.log
rm -rf /home/backups/$(date -d 'month ago' +%d-%m-%Y)
echo "Backup month ago deleted!" >> /root/backup.log
exit 1
Het is niet allemaal moeilijk en zeker niet super netjes maar het doet zijn werk!
Veel plezier ermee en breid je het uit post het dan ook even ;)
ik heb 7 crons omdat dat gewoon makkelijk werkt. je kan voor elke dag een cron aanmaken en dat zou voldoende moeten zijn.
cron volgens DA
Minuut: 0
Uur: 1
Dag van de maand: *
Maand: *
Dag van de week: 2
Alle gebruikers
ftp://{ipadres}/dinsdag/
deze heeft vorige week wel gewerkt en nu niet.
erg raar :mad:
deze heeft vorige week wel gewerkt en nu niet.
erg raar :mad:
Nogmaals, wat staat er in de (directadmin) logs?
zou je die iets specifieker kunnen stellen.
ik heb zo'n beetje alle logs bekeken maar vindt niks wat mij verbaast?
waar vind ik dit log ?
zou je die iets specifieker kunnen stellen.
ik heb zo'n beetje alle logs bekeken maar vindt niks wat mij verbaast?
waar vind ik dit log ?
welke heb je gehad dan?
Hoe groot zijn de backups die je er wil over pushen, want directadmin instellingen met ftp hebben nogal wat moeite met grote tarballs over te zetten via ftp. Misschien dat dit het probleem is waarom het de ene keer wel wil en dan weer niet. Probeer je crontab ook eens manueel uit voeren in verbose mode, dan zie je ook meteen welke fouten hij geeft.
bestanden van 200KB tot 2,5GB groot. de logbestanden die je in da zelf kunt bekijken met de logviewer.
de datatask kun je daar alleen niet in bekijken voor zover ik kan zien.
da errorlog
da system log
da security log
cron log
da errortaskq log
en staat niks in over backup
2,5 gb moet geen probleem zijn, dat doe ik ook een aantal keer iedere backup.
kan je eens een stuk cronlog posten van 5 minuten voor dat de job hoort te draaien tot een stuk daarna? uiteraard mag je ip adressen of wachtwoorden even leeglaten of annonimiseren.
de cron van zondag 24 ( werkt niet )
Jan 24 01:00:01 srv10 crond[32603]: (diradmin) CMD (echo -e "action=backup&id=7&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da)
de cron van maandag ( werkt wel )
Jan 25 01:00:01 srv10 crond[24020]: (diradmin) CMD (echo -e "action=backup&id=2&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da)
de cron van dinsdag ( werkt niet )
Jan 26 01:00:01 srv10 crond[16298]: (diradmin) CMD (echo -e "action=backup&id=1&owner=admin" >> /usr/local/directadmin/data/task.queue.da; /bin/chmod 600 /usr/local/directadmin/data/task.queue.da)
dit is wat je wilt weten neem ik aan.
commando's zien er goed uit. alleen hoort er iets in de logging te staan waarom de jobs failen. Evt wil ik wel even meekijken.
Wat is jouw OS?
meerdere? (http://www.webhostingtalk.nl/directadmin/157550-backup-cron-wordt-niet-uitgevoerd.html#post1120067)
heb je soms een ntp time synchronisatie op hetzelfde moment ?
centos
en hoe check ik die ntp time
ok, heb je je cronjobs heel op het uur staan ?
* 1 * * * ?
Verander deze is naar bijvoorbeeld
15 1 * * *
ik heb de minuten inmiddels op een andere tijd gezet voor zowel zondag als dinsdag omdat die beide niet (goed) werkten.
ik laat het nog weten hoe het dan gaat en dan ga ik alle tijden aanpassen als dat werkt.
zondag heeft de backup nu wel gewerkt.
Ik denk dat Mikey wel eens gelijk kan hebben dat je elk uur synchroniseert met een tijdserver. Wanneer de tijd dan enkele seconden naar voor worden gezet slaat hij je backup over.
dat zal heel best kunnen.
ik denk dat ik alle tijden even iets na het uur zet om dit probleem te voorkomen.
mocht vannacht de backup ook weer lopen dan zijn we zeker.
ook vannacht is de backup goed gegaan.
waarschijnlijk het tijdsverschil
oorzaak blijft dus nog gissen maar de tijden zijn aangepast en het werkt.
thanks
check eens in je /var/log/cron en zoek eens op "ntp"
Ooh en de bloemen mogen naar mijn moeder \o/
Had vanavond niks te doen en ag, heb het backupscript eens opnieuw gemaakt zodat je het voor meerdere servers kan gebruiken.
Zou zeggen, doe er je voordeel mee ;)
backup.sh
#!/bin/bash
#
# Backup schedule
#
#./backupper.sh "LOCAL_DIR" "FTP_USER" "FTP_PASSWORD" "FTP_IP" "REMOTE_DIR" "RETENTION DIR"
./backupper.sh "/home/xxx/" "test" "test" "test.nl" "user_backups" "1"
exit 1
backupper.sh
#!/bin/bash
#
# Pull script
#
LOCAL_DIR="$1"
FTP_USER="$2"
FTP_PASSWORD="$3"
FTP_IP="$4"
FTP_MAP="$5"
RETENTION_DAYS="$6"
# Running backupscript... Logging
echo "[${FTP_IP}] Starting backup @ $(date +%d-%m-%Y) $(date +%H:%M:%S)" >> /root/backup.log
# Log LOCAL_DIR and mkdir date
echo "[${FTP_IP}] cd dir ${LOCAL_DIR} and creating dir $(date +%d-%m-%Y)" >> /root/backup.log
cd ${LOCAL_DIR}
mkdir $(date +%d-%m-%Y) >> /root/backup.log
# Entering map $Date
cd $(date +%d-%m-%Y)
# Pull backups to this map
wget -r ftp://${FTP_USER}:${FTP_PASSWORD}@${FTP_IP}/${FTP_MAP} >> /root/backup.log
# Logging when finished
echo "[${FTP_IP}] Backup Pull finished @ $(date +%d-%m-%Y) $(date +%H:%M:%S)" >> /root/backup.log
# Removing old backups
rm -rf ${LOCAL_DIR}/$(date -d "${RETENTION_DAYS} days ago" +%d-%m-%Y)
# Logging again ...
echo "[${FTP_IP}] Backup remove @ $(date +%d-%m-%Y) $(date +%H:%M:%S) from ${RETENTION_DAYS} days ago" >> /root/backup.log
# Backup finished
echo "[${FTP_IP}] Backup finished @ $(date +%d-%m-%Y) $(date +%H:%M:%S)" >> /root/backup.log
exit 1
Start het script meerdere keren op met een cron bijvoorbeeld of laat alle backups achter elkaar lopen door ze in de backup.sh te gooien.
Meerdere keren tegelijkertijd mag niet meer voor problemen zorgen in de backup.log omdat er steeds het IP wordt genoemd.
Succes ermee!
Yourwebhoster
01/07/10, 20:43
Leuk script, ik zie alleen dat je nu telkens in de /root alles zet en dit blijkbaar als root draait. Ik zou dit lekker als normale gebruiker dit draaien en de log in /var/log gooien, is wat overzichtelijker.
Leuk script, ik zie alleen dat je nu telkens in de /root alles zet en dit blijkbaar als root draait. Ik zou dit lekker als normale gebruiker dit draaien en de log in /var/log gooien, is wat overzichtelijker.
Draait als $user hoor ;)
Elke gebruiker heeft zijn backup.sh en backupper.sh heeft iedereen permissies op.