Bekijk Volledige Versie : DirectAdmin en Backuppen
ErikKosters
24/01/07, 12:49
Beste WHT-ers,
Nee dit topic gaat niet over het standaard backuppen, dat werkt namelijk prima. Ik voer de backups uit vanuit de Reseller gebruiker. Maar mijn vraag is het volgende; ik heb een reseller welke voor grote projecten zeker moet weten dat de bestanden bewaard blijven (ook van 1/2 tot 4 weken terug). Hoe kan ik dit het beste aanpakken aangezien bij de standaard backup DirectAdmin de bestanden overschrijft.
Het zal best op te lossen zijn via een BASH script of dergelijke, maar hier ben ik nou ook weer niet zo top in. Wellicht heeft iemand hier reeds zoiets gescript en wil dit script met mij delen.
Het moet dus backups van max 1 maand oud bewaren. Alvast bedankt voor eventuele hulp!
De backups worde per datum weggeschreven hier. Als je dus daarniks mee doet heb je na een jaar een dik archief met backups... Dus af en toe handmatig opschonen is mijn tip. Anders kun je op basis van data gaan kijken welke backups er weg kunnen.
Nadeel van DA backups is dat je full backups hebt. Incrementals via bijv een rsync script is dan veel slimmer...
ErikKosters
24/01/07, 13:53
Hoe schrijf jij ze weg per datum dan, hier wordt het gewoon als onderstaande bestandsnaam opgeslagen en dus overschreven bij het backuppen. Ik doe de backup via Reseller -> User backups.
-rw-r--r-- 1 iets iets 545475824 Jan 24 05:05 user.tar.gz
* Maak in DA een normale reseller backup in een lokale map
* Maak voor het aantal dagen dat je backups wilt scripts aan
* Verplaats in ieder script de backup naar /backup_path/dagnummer/
* Stel cronjobs in voor ieder backup script (script 1 op dag 1, script 2 op dag 2, etc.)
Wij doen iets soortgelijks, maar dan kopieren we de backups via scp naar de backup server. Op die manier kost het de reseller geen traffic (via DA FTP destijds wel, mogelijk is dat nu aangepast) en bepalen wij waar en hoe lang de backups worden bewaard. Tevens beschikt de reseller niet over de login gegevens van de backup server.
wat trouwens krom is is dat je van de admin (full-system) backup wel rotatie krijgt maar bij de normale backups dus niet (vanuit reseller menu) .. Maar dat ever terzijde. Je zult het makkelijkste een cron script kunnen laten draaien idd, een rename ofzo :)
Hoe schrijf jij ze weg per datum dan, hier wordt het gewoon als onderstaande bestandsnaam opgeslagen en dus overschreven bij het backuppen. Ik doe de backup via Reseller -> User backups.
-rw-r--r-- 1 iets iets 545475824 Jan 24 05:05 user.tar.gz
backup via Reseller -> User backups -> extra cronjobs toevoegen,
b.v. voor iedere dag.
Moet je er een maand terug hebben, zet je er 30 in, en laat je backuppen naar apperte mappen...
ErikKosters
24/01/07, 15:40
Bedankt, heb het opgelost middels een cronjob en aparte mappen op de backupserver gezet (dag, week, maand). Werkt als een trein zo te zien!
Bedankt, heb het opgelost middels een cronjob en aparte mappen op de backupserver gezet (dag, week, maand). Werkt als een trein zo te zien!
wat heb jij nu in de cronjob staan
ben er ook wel in geintresseerd
maar weet niet wat ik in de cronjob moet zetten
Dat is natuurlijk niet helemaal de manier. Wat je wilt is bijvoorbeeld elke maand en week een full backup - en voor de tussenliggende dagen incremental backups.
Ik heb hier al een hele tijd naar willen kijken maar nog niet echt de tijd voor gehad.
Korte uitleg hoe je dit met SCP kunt doen...
*stel de reseller backups onder DA in. Bijvoorbeeld om 01:00 uur.
* zorg ervoor dat je vanaf de productieserver zonder password middels ssh kunt inloggen op de backup server (zie onderaan deze pagina (http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch17_:_Secure_Remote_Logins_and_File _Copying) voor tutorial)
* maak op de backup server mappen aan (zorg ervoor dat de "backup user" daar schrijfrechten heeft!)
/backup1/username/
/backup2/username/
* zet in backup1.sh het volgende:
scp /home/username/user_backups/*.tar.gz backupuser@server2:backup1/username/
rm -rf /home/username/user_backups/
*stel de cronjobs in
crontab -e
0 6 * * 0 /root/backup1.sh
0 6 * * 1 /root/backup2.sh
0 6 * * 2 /root/backup3.sh
0 6 * * 3 /root/backup4.sh
0 6 * * 4 /root/backup5.sh
0 6 * * 5 /root/backup6.sh
0 6 * * 6 /root/backup7.sh
Uiteraard zijn incremental backups handig als je ruimte tekort komt. Echter gezien de huidige kosten van harddisks en de relatief geringe hoeveelheid data die wij backuppen hebben we hier niet voor gekozen