Onderwerp: Directadmin backup 14 dagen bewaren.

Oorspronkelijk geplaatst door cfmweb

Toch nog even een subtiel kickje..

Maar hoe kan je nou Directadmin zo instellen dat ie een restore doet van alle users op een bepaald tijdstip.

Users van server A naar server B backuppen met een cronjob is geen probleem, maar op server B de users restoren met een cronjob, hoe doe je dat.

Zoals onze grote vriend John van directadmin zou zeggen:
Doe een restore en kijk in de datatask.queue welk commando hij oproept en zet dat in een cron.

Zou ook even kunnen kijken in het script dat ik ergens heb draaien maar ik ben momenteel in luiwammes mode

En @Angiligo:

Misschien het hele topic lezen? lijkt me duidelijk waarom toch?

Oorspronkelijk geplaatst door cyberbootje

Doe een restore en kijk in de datatask.queue welk commando hij oproept en zet dat in een cron.

Tsss waarom verzin ik dat zelf nou niet

Oorspronkelijk geplaatst door cyberbootje

Zoals onze grote vriend John van directadmin zou zeggen:
Doe een restore en kijk in de datatask.queue welk commando hij oproept en zet dat in een cron.

Zou ook even kunnen kijken in het script dat ik ergens heb draaien maar ik ben momenteel in luiwammes mode

En @Angiligo:

Misschien het hele topic lezen? lijkt me duidelijk waarom toch?

Verkeerd begrepen.
Dacht dat die persoon elke dag een restore wou gaan uitvoeren op de server waar zijn klanten op staan. Dan zou een terugdraai, roll back niet zo leuk zijn.


Angiligo

Graag vul ik dit topic aan met een praktijk situatie.

We hebben het nog steeds over de situatie waarbij men, al dan niet geautomatiseerd, een backup oplossing maakt door een backup te maken van een account op server A en te restoren naar server B.

Dat betekent dat wanneer klanten cronjobs hebben draaien die geautomatiseerd taken uitvoeren, deze taken zowel op de A server als op de B server worden uitgevoerd.

Afgelopen week ben ik zelf tot de ontdekking gekomen dat dat niet handig is. Ons administratiepakket (wefact) stond ook gerestored op een backup server en stond vrolijk te connecten op de database. Aangezien de facturatie geautomatiseerd plaatsvind, onstond de situatie dat klanten meerdere facturen ontvingen met dubbele lijnen.

Zomaar een tip om nog even rekening mee te houden dus. Ik kan me voorstellen dat dit soort "foutjes" in meerdere situaties niet wenselijk is.

Oorspronkelijk geplaatst door cfmweb

Afgelopen week ben ik zelf tot de ontdekking gekomen dat dat niet handig is. Ons administratiepakket (wefact) stond ook gerestored op een backup server en stond vrolijk te connecten op de database. Aangezien de facturatie geautomatiseerd plaatsvind, onstond de situatie dat klanten meerdere facturen ontvingen met dubbele lijnen.

Dit was het eerste waar ik aan dacht toen ik deze topic las. Cronjobs draaien inderdaad gewoon doodleuk dubbel.

Daarbij zou je denk ik (vanuitgaande dat je overdag een crash krijgt) van je wefact account de meest recente data willen hebben van voor de crash, ook al gaat dat 4 uur duren. Dan maar 4 uren geen klanten helpen en bestellingen ontvangen. Als je een back-up terugzet van die nacht er voor en je moet later die dag alles weer mergen ben je veel verder van huis.

Ik heb hier en daar ook nog wel eens een belangrijk account die ik op een aparte back-up server wil hebben. Zoals de administratie, eigen websites en belangrijke of bekende klanten. Hiervoor heb ik een eigen bash functie geschreven die ik elke nacht aanroep, met een soort queue van 10 lijnen:

Code:

getbackup localfolder ftphost ftpuser ftppass ftpfolder backupfile retention

Je kan per back-up dus een retentie aangeven. Ook kan je bij backupfile * ingeven, zodat hij alles uit de ftpfolder pakt.

Geen technisch hoogstandje, maar wel uitermate functioneel!

Ik heb zelf een script geschreven wat het volgende doet:
Kijken of de backup in de map op de ftp is weg geschreven.
vervolgens controleren of het week nummer bestaat, en dan een map aanmaakt met de datum.
Dit script roep ik aan via een crontab.