PDA

Bekijk Volledige Versie : Iemand toevallig een DA backup genereer scriptje?



systemdeveloper
06/04/17, 14:07
Ik zoek een scriptje dat een reguliere "directadmin admin level backup tar.gz" maakt op basis van een kopie op een backupserver en ik vroeg me af of iemand dat toevallig al eens gemaakt heeft en wellicht wilt delen tegen vergoeding.

Ik bedoel niet het aantrappen van de backup-api, maar geheel standalone. Een shellscriptje dat een normale da-backup dus simuleert.

Iemand?

John

ju5t
06/04/17, 16:30
Is dat niet erg afhankelijk van je backup? Hoe maak je bijvoorbeeld backups van je database? Ik heb niets liggen maar ik vind het zelf ook interessant. Als iemand iets heeft wat er op lijkt en open source wilt maken wil ik wel meedenken en eventueel mee ontwikkelen.

NibeP
06/04/17, 16:38
Ik vind het ook wel interessant. Ik zal eens wat gaan maken op GitHub.

systemdeveloper
06/04/17, 17:09
Nou, een groot deel is relatief eenvoudig te doen, maar da heeft, zoals ze het zelf noemen er een 'complex mess' van gemaakt.

Het idee erachter is dat rsyncs LEES opdrachten zijn op de dure ssd's en veel klanten vaak veel meer writes doen met het kopiëren van de site en er een tar.gz van maken zoals de da backup doet. Dat zijn allemaal zinloze writes die alleen maar bijdragen tot de wear en relatief nooit nodig zijn (hooguit bij een restore die, als het goed is, veel minder vaak voorkomt dan een backup).

Plus je bent van je load pieken af als 100 vm's op hun default waarde om 5 uur beginnen te backuppen. En... je hebt niet een hoop wasted space op je vm van die backups.

De mysql data, user home dir, email en content van de domeinen is in principe niet zo spannend. Dat is vrij eenvoudig met een paar tar commandos en mysqldump te doen. Het is meer die 'backup' directory die in de tar.gz zit met de ftp.conf, domain.conf, db conf etc gegevens.

Ik wil niet afhankelijk zijn van het moment dat iemand een backup met da maakt (of geen maakt) en ons backupsysteem besluit om de backup over te trekken naar een backupbak. In die tussentijd kunnen namelijk users zijn aangemaakt of zo. In de da backup zit die user dan nog niet, maar op de backupbak wel, aangezien die alles later overhaalt.

Een oplossing is om vlak vóór een pull backup een da backup aan te trappen met de minimale gegevens om een account met zijn settings te restoren. Maar helaas werkt dat bij directadmin alleen via een cron. En ons backup systeem doet gem. 50-60 vm's backuppen per uur. Als ik daar voor elk vm een paar minuten bij moet gaan tellen voor wat onzinnige backups, dan verveelvoudigd mijn doorlooptijd weer.

Ideaal zou zijn als DA hun backupfunctie gewoon standalone zou uitgeven natuurlijk, maar dat zal er niet in zitten :(

systemdeveloper
06/04/17, 17:35
Een zeer simpel voorzetje heb ik. Wat hier met name nog aan mist zijn de user settings dus omdat die nog moeten worden geconverteerd naar een formaat dat DA vreet bij zijn restore. Onderstaande is een beetje verzamelt uit mijn bash history en wat vars in gemikt, dus vergeef me de schoonheidsfoutjes :).


#!/bin/sh

SVR=$1
DAUSR=$2
BASE=/pad/waar/je/backups/staan/${SVR}/last

usage() {
echo -e "** Blah DA Backup**\nUsage: $0 <hostname> <da-username>"
exit 1;
}

if [ "x${SVR}" = "x" ];
then
usage
fi

if [ "x${DAUSR}" = "x" ];
then
usage
fi

# setup tmp directory
mkdir -p "${BASE}/home/admin/admin_backups/${DAUSR}/backup/"

# copy required files for da
cd "${BASE}/home/admin/admin_backups/${DAUSR}/backup/"
# owned by apache -> that should not happen so f*ck it
touch apache_owned_files.list
# copy backup template with minimal options
cp /blah/backup_options.list.default backup_options.list
#
for i in "bandwidth.tally crontab.conf ticket.conf user.conf user.history user.usage"; do
cp "${BASE}/usr/local/directadmin/data/users/${DAUSR}/${i}" .
done
mkdir email_data history
# DA's 'mess'. [todo]
for d in `cat "${BASE}/usr/local/directadmin/data/users/${DAUSR}/domains.list"`; do
mkdir "${d}"
cp "${BASE}/usr/local/directadmin/data/users/${DAUSR}/domains/${d}.conf" "${d}/domain.conf"
cp "${BASE}/usr/local/directadmin/data/users/${DAUSR}/domains/${d}.usage" "${d}/domain.usage"
# .. many, many more...
done

# generate tar.gz files
/bin/tar czfp "${BASE}/home/admin/admin_backups/${DAUSR}/backup/home.tar.gz" -C "${BASE}/home/${DAUSR}/" '.bash_logout' '.bash_profile' '.bashrc' '.cshrc' '.login' '.login_conf' '.mail_aliases' '.mailrc' '.php' '.profile''.razor' '.rhosts' '.shrc' '.spamassassin' 'Maildir'
/bin/tar czfp "${BASE}/home/admin/admin_backups/${DAUSR}/user.admin.${DAUSR}.tar.gz" -C "${BASE}/home/admin/admin_backups/${DAUSR}" backup -C "${BASE}/home/${DAUSR}/" domains imap

# cleanup...

systemdeveloper
10/04/17, 17:00
Ok dat bovenstaande had een beetje last van teveel quotes dus ik heb even een aangepaste versie online gezet waarbij het me gelukt is om op basis van een reguliere rsync van een da bak, offsite een tar.gz te prutsen die met succes door da gerestored werd.

https://www.64bitswebhosting.eu/demo/opensource/da/ (performance tip: skip de blabla en ga direct naar beneden)

Alleen met een zeer eenvoudige user getest nog, maar ik zit ook krap in de tijd. Het zou top zijn als anderen die er het voordeel wel in zien, het pakken en verbeteren en teruggooien. Het is nu een heel erg bot mes dat vrij weinig checked en op elk gebied verbetert kan worden :)

Spyder01
10/04/17, 17:30
Als ik ergens deze week wat tijd kan vinden zal ik eens kijken. Jaren geleden eens zoiets gemaakt.

wouter0100
11/04/17, 12:34
Ik volg dit ook even. Maak hier lokaal snapshots met ZFS en verplaats deze ook continue naar een backup server. Hierbij zou zo'n scriptje erg handig zijn, waaruit ik uit de backup dus een DA backup kan maken. Scheelt veel gepruts. (Y)

Ramon Fincken
14/04/17, 10:01
Wellicht ook interessant : https://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html

h_ts
14/04/17, 17:48
Ik ben ook benieuwd. Volg dit ook even. Raar dat hier nog geen oplossing voor is.

systemdeveloper
17/04/17, 00:00
Wellicht ook interessant : https://www.gnu.org/software/tar/manual/html_node/Incremental-Dumps.html

Als je al een vorige tar hebt en je wilt mogelijk een afwijkende tar gebruiken die niet overal beschikbaar is, dan is het zeker een leuke optie.
In mijn geval wil ik geen enkele tar maken, tenzij ik hem echt nodig heb.

Ons backupsysteem doet nu tegen de 800 rsync opdrachten per uur wat overeenkomt met een 100 vm's. Dat zegt niet veel, maar ons vorige deed hetzelfde en had daar 7-8 uur nodig voor de helft aan vms. Als ik nu xxxx tar.gz's kan skippen in zowel aanmaken als elke nacht overtrekken, dan scheelt dat wel natuurlijk.

Ramon Fincken
05/05/17, 08:50
Ik heb dat incremental tar nu voor een server ter test, eerste keer draaien: 2 uur, 2e dag: 11 minuten :) Is puur de public_html map, dus net ietsje anders dan DA t doet.

jawad
09/05/17, 21:01
Als ik ergens deze week wat tijd kan vinden zal ik eens kijken. Jaren geleden eens zoiets gemaakt.

En? Ik hoop dat je er inmiddels wat tijd aan hebt kunnen besteden. Ik heb hier ook naar gezocht maar kom enkel pogingen tegen van jaren geleden.
Hier heb je misschien ook nog wat aan. -> DirectAdmin rsync script (https://www.webhostingtalk.nl/unix-linux-bsd/165787-directadmin-rsync-script.html)

Spyder01
09/05/17, 21:11
En? Ik hoop dat je er inmiddels wat tijd aan hebt kunnen besteden. Ik heb hier ook naar gezocht maar kom enkel pogingen tegen van jaren geleden.
Hier heb je misschien ook nog wat aan. -> DirectAdmin rsync script (https://www.webhostingtalk.nl/unix-linux-bsd/165787-directadmin-rsync-script.html)

Ik heb er nog geen tijd voor gehad, erg druk met dingen die voorgaan :-)

systemdeveloper
09/05/17, 22:12
Hmm, moet het inderdaad ook weer eens oppakken. Nou ja, mijn lokale versie werkt wel, maar moet ik echt nog eens uittesten met meerdere emails/domeinen/ ftpaccounts etc per user, maar ik zit momenteel midden in een verbouwing, dus.. dat gaat het hem nog niet worden.

jawad
09/05/17, 22:48
Geen probleem Spyder01 en systemdeveloper. Doe jullie ding en laat hier maar horen als jullie er aan toegekomen zijn.