Backuppen van rechten

Pagina: 1
Acties:

  • eghie
  • Registratie: Februari 2002
  • Niet online

eghie

Spoken words!

Topicstarter
Is het mogelijk om rechten te backuppen.

Wij gebruiken nu rdiff-backup om bestanden te backuppen van onze servers. Dit gebeurd elke nacht. Maar nu willen ook een preventie tegen het bijvoorbeeld perongelijk chmodden, chownen,chattren.

We willen een systeem kunnen recoveren waarbij dit is gebeurd:
chmod -R 4000 /
chown -R nobody:nobody /


Maar we willen het liefst ook nog, dat je bijvoorbeeld alleen /home kan terugzetten qua rechten.

[ Voor 6% gewijzigd door eghie op 27-03-2009 17:54 ]


  • BarthezZ
  • Registratie: Juli 2004
  • Niet online

BarthezZ

anti voetbal en slechte djs!

Ik kan mij niks herinneren van tooltjes die hierop gericht zijn, maar opzich valt het vrij simpel te scripten om alle rechten te checken, in een text filetje te gooien en (evt met een regexp om bepaalde dingen wel of niet te doen) ze terug te zetten adhv dat text filetje.

  • eghie
  • Registratie: Februari 2002
  • Niet online

eghie

Spoken words!

Topicstarter
BarthezZ schreef op vrijdag 27 maart 2009 @ 18:00:
Ik kan mij niks herinneren van tooltjes die hierop gericht zijn, maar opzich valt het vrij simpel te scripten om alle rechten te checken, in een text filetje te gooien en (evt met een regexp om bepaalde dingen wel of niet te doen) ze terug te zetten adhv dat text filetje.
Ik moet zeggen dat ik het wel vreemd vind, gezien de terreur die je over je heen krijgt als je een deel van een backup procedure niet goed hebt. Dit is namelijk wel vrij cruciaal voor het functioneren voor je systeem als het gebeurd. Dus had verwacht dat er al wel wat voor was.

Het scripten lijkt me inderdaad ook nog wel te doen ja. Iets van een tekst bestand met de volgende structuur:
code:
1
/mijnmap;0777;owner;group;i


Die laatste kolom zou dan geparste lsattr resultaten zijn, zodat ik die eventueel ook nog kan terug zetten.

Om die te parsen, heb ik zojuist alvast het volgende stukje geschreven:
code:
1
lsattr -a /usr/sbin/sendmail 2>/dev/null | awk '{ attr=$1; gsub(/-*/, "", attr); if (length(attr) > 0) print attr; }'


Ik denk dat ik eens ga klussen met Python.

  • CyBeR
  • Registratie: September 2001
  • Niet online

CyBeR

💩

eghie schreef op vrijdag 27 maart 2009 @ 19:05:
[...]

Om die te parsen, heb ik zojuist alvast het volgende stukje geschreven:
code:
1
lsattr -a /usr/sbin/sendmail 2>/dev/null | awk '{ attr=$1; gsub(/-*/, "", attr); if (length(attr) > 0) print attr; }'
Wauw, da's wel heel erg omslachtig. Je gaat nu dus per file op je filesystem een tweetal processen afvuren met pipes erbij en ook nog 's regexp parsing. Heb je enig idee hoe lang dat gaat duren?

Ik zou, als ik jou was en ik wist wat ik deed, even kijken naar de fstat() en fgetflags() system calls.

All my posts are provided as-is. They come with NO WARRANTY at all.


  • eghie
  • Registratie: Februari 2002
  • Niet online

eghie

Spoken words!

Topicstarter
CyBeR schreef op vrijdag 27 maart 2009 @ 19:55:
[...]


Wauw, da's wel heel erg omslachtig. Je gaat nu dus per file op je filesystem een tweetal processen afvuren met pipes erbij en ook nog 's regexp parsing. Heb je enig idee hoe lang dat gaat duren?

Ik zou, als ik jou was en ik wist wat ik deed, even kijken naar de fstat() en fgetflags() system calls.
Mjah dat bedacht ik me later ook. Wat te enthousiast gepost. Ik was eigenlijk van plan om de python lib te gebruiken. Ik was zojuist een fgetflags() system call aan het zoeken in de python libs, of een vergelijkbare functie. Die kon ik echter nog niet vinden. Dus je reactie komt als geroepen. ;) Mijn os.stat() geeft namelijk geen .st_flags terug. Dus moest een andere methode zoeken.

  • eghie
  • Registratie: Februari 2002
  • Niet online

eghie

Spoken words!

Topicstarter
Het lijkt erop dat fgetflags() niet gaat werken. Python heeft geen bindings met e2p. Ik zou die fgetflags() functie wel een vorm van na kunnen bouwen. fgetflags() gebruikt intern ioctl(0, EXT2_IOC_GETFLAGS, &flags). Hier heb ik op het moment nog wat minder zin in., maar lijkt me wel te doen.

Ik zit zelf zojuist te denken op chattr/lsattr maar even te laten zitten in dat script, voornamelijk omdat het filesystem specifiek is. XFS heeft het bijvoorbeeld niet. En misschien, als het script wat verder is, om dan wel rekening te gaan houden met die extra dingen. Nu bestaan er ook nog extended attributes. Die worden volgens mij ook in de FS metadata opgeslagen en niet in het bestand zelf. Dat zijn ook nog, eventuele dingen waar rekening mee gehouden kan worden. Voor nu houden we het dus nog maar even bij chmod, uid, gid.

Voorbeeld script:
Python:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
#!/usr/bin/env python

import os
import getopt,sys
import string
import stat
import subprocess
import subprocess

mainpath = os.path.abspath("/")

def checkRights(path):
    for f in os.listdir(path):
        if path.endswith("/"):
            fpath = path + f
        else:
            fpath = path + "/" + f

        if os.path.islink(fpath):
            continue
        if os.path.isdir(fpath):
            #continue
            checkRights(fpath + "/")

        if os.path.isfile(fpath):
            fstatinfo = os.stat(fpath)

            proc = subprocess.Popen(["lsattr", fpath], shell=False, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
            attrs = proc.communicate()[0].strip().split(' ')[0].replace('-', '')

            print "%s;%o;%i;%i;%s" % (fpath, fstatinfo.st_mode & 0777, fstatinfo.st_uid, fstatinfo.st_gid, attrs)

checkRights(mainpath)


Maar hoe gaan jullie met die situaties om. Als in, wat zouden jullie doen als je perongeluk, in een vlaag van verstandsverbijstering chmod -R 000 / zouden doen, of een vergelijkbaar iets?

  • BarthezZ
  • Registratie: Juli 2004
  • Niet online

BarthezZ

anti voetbal en slechte djs!

Niet onnodig ingelogd met root zijn en zodra ik klaar ben met wat ik als root moet doen meteen weer uitloggen. Én, dat is een fout die je 1x in je leven maakt en daarna nooit meer :p

  • eghie
  • Registratie: Februari 2002
  • Niet online

eghie

Spoken words!

Topicstarter
BarthezZ schreef op zaterdag 28 maart 2009 @ 15:45:
Niet onnodig ingelogd met root zijn en zodra ik klaar ben met wat ik als root moet doen meteen weer uitloggen. Én, dat is een fout die je 1x in je leven maakt en daarna nooit meer :p
Mjah, maar rm -rf /etc net zo. Maar toch wil je dat niet dat dat zelfs 1 keer gebeurd op een productie server. Daarnaast moet je wel eens root toegang uit handen geven aan collega's of misschien wel externe partijen. Alhoewel dat laatste gelukkig niet veel voorkomt. Dus probeer ik preventief een maatregel te zoeken.

Backups worden wel gedaan, maar dat is op moment van restoren al wel wat verouderde data. Ik gebruik liever de meest recente data en dat zijn toch de huidige bestanden. Dan als ik daar de rechten op kan restoren, dan heb je de recentste data dus nog.

  • MartinMeijerink
  • Registratie: Juli 2008
  • Laatst online: 27-01 15:36

MartinMeijerink

Computerrorist

eghie schreef op zaterdag 28 maart 2009 @ 15:34:
Als in, wat zouden jullie doen als je perongeluk, in een vlaag van verstandsverbijstering chmod -R 000 / zouden doen, of een vergelijkbaar iets?
Dan pak ik de laatste periodieke volledige backup van het hele systeem, welke op een externe schijf staat, en maak ik ff een klein bash-scriptje waarbij ik met de optie --reference van chmod het allemaal weer ff terugzet...

Afgezien daarvan doe ik die -R altijd als laatste argument, stel dat ik wil intikken:
code:
1
rm -rf /home/martin/iets/
en ik druk per ongeluk na de eerste slash op Enter...

An unbreakable toy is useful to break other toys


  • eghie
  • Registratie: Februari 2002
  • Niet online

eghie

Spoken words!

Topicstarter
MartinMeijerink schreef op zondag 29 maart 2009 @ 20:36:
[...]

Dan pak ik de laatste periodieke volledige backup van het hele systeem, welke op een externe schijf staat, en maak ik ff een klein bash-scriptje waarbij ik met de optie --reference van chmod het allemaal weer ff terugzet...
Ik ben niet zo bekend met de --reference optie van chmod. Wist niet eens dat die bestond eigenlijk. Ik zal daar ook maar eens naar gaan kijken.

Het mooie van een textfile is opzich ook dat je er doorheen kunt diffen. Kun je ook zien wat er dan veranderd is.
Afgezien daarvan doe ik die -R altijd als laatste argument, stel dat ik wil intikken:
code:
1
rm -rf /home/martin/iets/
en ik druk per ongeluk na de eerste slash op Enter...
Hier heb ik zelf nog niet aan gedacht, maar opzich een vrij goede optie ja.

Ik zou natuurlijk ook chmod en chown en rm kunnen aliassen en daar sowieso iets van --preserve-root als default mee kunnen geven. Dan kan / al niet meer zomaar uitgeschakeld worden met die commando's. Of ik kan er een script tussen zetten, die iets doet met, weet u het zeker. Dat moet hij dan wel doen als hij een terminal detecteerd en niet doen als een automatisch script dat commando aanroept.

[ Voor 8% gewijzigd door eghie op 30-03-2009 09:19 ]


Verwijderd

eghie schreef op vrijdag 27 maart 2009 @ 17:53:
Is het mogelijk om rechten te backuppen.

Wij gebruiken nu rdiff-backup om bestanden te backuppen van onze servers. Dit gebeurd elke nacht. Maar nu willen ook een preventie tegen het bijvoorbeeld perongelijk chmodden, chownen,chattren.

We willen een systeem kunnen recoveren waarbij dit is gebeurd:
chmod -R 4000 /
chown -R nobody:nobody /


Maar we willen het liefst ook nog, dat je bijvoorbeeld alleen /home kan terugzetten qua rechten.
Als je dat wilt zou ik Bacula gebruiken ipv rdiff-backup

  • eghie
  • Registratie: Februari 2002
  • Niet online

eghie

Spoken words!

Topicstarter
Verwijderd schreef op maandag 30 maart 2009 @ 13:40:
[...]


Als je dat wilt zou ik Bacula gebruiken ipv rdiff-backup
Hoezo? Wat bied Bacula meer dan rdiff-backup? Het is niet zo dat rdiff-backup geen rechten meeneemt ofzo.

Ik vind zelf rdiff-backup fijner beheren dan Bacula op een CLI-only systeem. Ik moet zeggen dat die grafische tools van Bacula wel erg tof zijn. En qua software design is Bacula ook wel tof. Maar omdat ik rdiff-backup makkelijker vind beheren, gebruik ik liever rdiff-backup.

[ Voor 32% gewijzigd door eghie op 30-03-2009 18:49 ]


Verwijderd

Bacula is een enterprise backup systeem waarbij je tot in het kleinste detail je backups kunt finetunen. Daardoor lijkt Bacula me meer geschikt bij de eisen die jij stelt of nog gaat stellen ;) Overigens ik vind rdiff-backup ook perfect hoor maar ten op zichte van Bacula is het toch beperkter in zijn mogelijkheden bijv. een complete system restore is met rdiff-backup toch lastiger dan met Bacula. Als ik bij ons in de organisatie kijk gebruiken voor onze 150 linux/unix servers de volgende pakketten:

Bacula
Tivoli backup

En als laatste voor servers van 1 bepaalde klant Netvault. Zelf gebruik ik prive zaken als rsync of rsnapshot.

Verwijderd

Ik zit vol verbazing dit topic te lezen. Het is zo simpel, maar de "oplossingen" die ik voorbij zie komen zijn letterlijk om te janken. Rechten back-uppen is erg simpel, je maakt namelijk van je files een "tarbal", zie hieronder het commando:

tar -cvf <filename.tar> <bestanden/folder die in de tar file moeten komen> dus:
tar -cvf pictures.tar /home/user/pictures

Het nadeel is nu wel dat je een ogecomprimeerd bestand hebt, deze kan je achteraf wel in een zip, rar, enz, archive zetten, maar mooier is dat je er meteen een tar.gz file van maakt. Dat doe je zo:

tar -cvfz pictures.tar.gz /home/user/pictures

Internet staat vol met voorbeeld. Ook met "tar --help" kom je een heel eind.

Verwijderd

Verwijderd schreef op vrijdag 10 april 2009 @ 00:00:
Ik zit vol verbazing dit topic te lezen. Het is zo simpel, maar de "oplossingen" die ik voorbij zie komen zijn letterlijk om te janken. Rechten back-uppen is erg simpel, je maakt namelijk van je files een "tarbal", zie hieronder het commando:

tar -cvf <filename.tar> <bestanden/folder die in de tar file moeten komen> dus:
tar -cvf pictures.tar /home/user/pictures
Het idee is nu net dat alleen de permissies worden gesaved en niet alle files.

Ik heb het zelf niet getest maar ik denk dat pbackup wel aan jouw eisen moet voldoen eghie

  • eghie
  • Registratie: Februari 2002
  • Niet online

eghie

Spoken words!

Topicstarter
Verwijderd schreef op vrijdag 10 april 2009 @ 00:00:
Ik zit vol verbazing dit topic te lezen. Het is zo simpel, maar de "oplossingen" die ik voorbij zie komen zijn letterlijk om te janken. Rechten back-uppen is erg simpel, je maakt namelijk van je files een "tarbal", zie hieronder het commando:

tar -cvf <filename.tar> <bestanden/folder die in de tar file moeten komen> dus:
tar -cvf pictures.tar /home/user/pictures

Het nadeel is nu wel dat je een ogecomprimeerd bestand hebt, deze kan je achteraf wel in een zip, rar, enz, archive zetten, maar mooier is dat je er meteen een tar.gz file van maakt. Dat doe je zo:

tar -cvfz pictures.tar.gz /home/user/pictures

Internet staat vol met voorbeeld. Ook met "tar --help" kom je een heel eind.
Ow, reken maar dat ik daar wel over gedacht heb. Mijn kennis over tar is ook niet van gister. Ik weet donders goed dat de rechten daarmee ook gebackupped worden. Net zoals met rdiff-backup en rsync, cp -aR, rsnapshot, bacula, etc. Dat is ook niet het probleem.

Laat ik zeggen dat rdiff-backup, de tool die wij dus gebruiken om te backuppen, ook de rechten mee neemt. Dus we backuppen ze eigenlijk al wel.

Ik zoek een apart script/programma wat naar een bestand ofzo de rechten van het bestandsysteem backupped. En met dit bestand het ook weer terug kan zetten, hetzij gedeeltelijk, hetzij full system. Hier kun je namelijk verschillende dingen mee.

• Met zo'n programma duurt het niet zo lang om te backuppen als volledige bestanden. Dit betekent dat je dit vaker op een dag kunt uitvoeren.
• Je kunt er overheen diffen, denk aan iets als tripwire achtige programma/script. Tripwire is wat geavanceerder, dus die raad ik sowieso aan boven deze methode.
• De hoeveelheid ruimte is niet zo groot die het gebruikt. Dit betekent weer dat jet dit vaker op een dag kunt uitvoeren.
• Alleen rechten terugzetten op live data, is makkelijker en sneller en veiliger terugzetten, dan uit een backup van bestanden. Dit omdat een backup van bestanden vaak elke 24 uur wordt gedaan. Als je de backup terugzet van een drukke mailserver, ben je gegevens van die dag kwijt. Als je je bestanden kunt houden maar alleen de rechten kunt terug zetten, ben je die bestanden dus niet kwijt.

Vandaar dat ik dat los wil van een bestandsbackup. De resultaten van het script worden vervolgens wel weer in het bestandsbackup traject overgenomen, zodat dat eventueel ook nog terug te halen is. Uiteraard is het eigenlijk alleen maar nog van de data na de laatste backup.
Verwijderd schreef op vrijdag 10 april 2009 @ 08:18:
[...]


Het idee is nu net dat alleen de permissies worden gesaved en niet alle files.

Ik heb het zelf niet getest maar ik denk dat pbackup wel aan jouw eisen moet voldoen eghie
Thnx mate, zoiets zoek ik dus. Hier ga ik eens naar kijken.

Edit: nah, het programma is nog niet volledig genoeg. Dat programma doet alleen chmod rechten backuppen. Die houd verder geen rekening met owners enzo. En als het bestandsysteem specifieke flags heeft, dan houdt hij daar ook geen rekening mee. Uiteraard is het programma wel te verbouwen. Die C code ziet er nou ook niet zo heel ingewikkeld eruit. Maar dan blijf ik liever bij mijn huidige code. Maar bedankt iig voor de suggestie.

De code die ik nu had, na een tijdje proberen enzo:
Python:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#!/usr/bin/env python

import os
import getopt,sys
import string
import stat
import subprocess

mainpath = os.path.abspath("/")

excludes = ["/dev", "/proc", "/lost+found", "/tmp"]
errors = []

def walkpath(path, callback):
    for f in os.listdir(path):
        fpath = os.path.join(path, f)

        try:
            st = os.stat(fpath)
            stmode = st[stat.ST_MODE]

            if f in excludes or fpath in excludes:
                continue
            if stat.S_ISCHR(stmode) or stat.S_ISBLK(stmode) or stat.S_ISSOCK(stmode):
                continue
            if os.path.islink(fpath):
                continue
            if stat.S_ISDIR(stmode):
                walkpath(fpath, callback)
                #continue

            callback(fpath, st)
        except Exception, e:
            errors.append("Exception %s on %s" % (e, fpath))
            continue

def backuprights(path, statinfo):
    try:
        if stat.S_ISREG(statinfo[stat.ST_MODE]):
            proc = subprocess.Popen(["lsattr", path], shell=False, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
            attrs = proc.communicate()[0].strip().split(' ')[0].replace('-', '')

            print "%s;%o;%i;%i;%s" % (path, stat.S_IMODE(statinfo.st_mode), statinfo.st_uid, statinfo.st_gid, attrs)
    
        if stat.S_ISDIR(statinfo[stat.ST_MODE]):
            print "%s;%o;%i;%i;" % (path, stat.S_IMODE(statinfo.st_mode), statinfo.st_uid, statinfo.st_gid)
    except Exception, e:
        errors.append("Exception %s on %s" % (e, fpath))
    

if __name__ == '__main__':
    try:
        mainpath = sys.argv[1]
    except Exception, e:
        mainpath = mainpath = os.path.abspath("/")

    walkpath(mainpath, backuprights)

    print "\nErrors:\n------------------------------------"
    for error in errors:
        print error

[ Voor 4% gewijzigd door eghie op 10-04-2009 18:54 ]


Verwijderd

Het is een wilde gok maar: LVM Snapshots?

Zodra je je backup maakt maak je gewoon eerst een lvm snapshot en die gebruik je tevens om je backup te maken en laat je daarna openstaan. Bij het begin van de volgende backup-cycle eerst even je snapshot sluiten en weer opnieuw aanmaken. Maak natuurlijk een read-only snapshot aan.

Ik ken zelf geen programma om de rechten zelf terug te kopieeren maar een simpele cp -av zou al werken. Ik vraag me vooral af waarom je dit zou willen. Het probleem is vooral om de legale chmod's van de illigale te onderscheiden. Naar mijn idee zijn de rechten en de inhoud onlosmakkelijk met elkaar verbonden dus waarom je de rechten wel zou willen terug zetten maar de inhoud niet ontgaat me. Als een bestand verkeerde rechten heeft is de inhoud ook niet meer te vertrouwen. Een restore van beide is dus altijd wenselijk.

Mijn kennis van tar is niet zo heel best meer maar volgensmij was tar toch best snel in het selectief restoren van bestanden dus tenzij je geen online full backup hebt is een LVM snapshot eigenlijk het beste al weet ik niet wat de snelheid zou zijn van een cp -av van de snapshot naar waar de snapshot van is gemaakt en of dat je daarbij het COW principie triggert dus je snapshot moet mischien net zo groot zijn.

Mischien is rsync nog wel de beste optie bedenk ik me nu. Rsync zou slim genoeg moeten zijn om te zien dat de bestanden in de snapshot en de data identiek zijn op de rechten na. LVM Snapshots + rsync is een winnaar denk ik maar ik moet toegeven dat ik zelf ook nog dit alles eens moet uitproberen.

  • alson
  • Registratie: November 2006
  • Laatst online: 24-11-2025
Zelf zou ik in zo'n geval ook een volledige restore doen, wie weet is er nog meer stuk gemaakt. Verder zit je met bestanden die zijn aangemaakt na de laatste backup, die kun je niet terugzetten. Desnoods kun je na de restore nieuwere versies van bestanden als databases alsnog van het oude systeem kopiëren. Als het zo vaak gebeurt dat het stroomlijnen van dit proces belangrijk is zou ik toch eens nadenken of je de mensen met root rechten niet wat meer training moet geven of minder rechten moet geven.

Op *BSD systemen heb je mtree(8), dat kan met de -U optie permissies updaten naar aanleiding van een eerder aangemaakt spec bestand. Je kan dit bestand natuurlijk ook aanmaken op basis van een volledige backup. Ik weet zo niet of hij een foutmelding geeft bij nieuwe bestanden die niet in het spec bestand voorkomen, maar hij kan ze met de -r optie wel verwijderen, dus waarschijnlijk wel.

Debian heeft mtree in freebsd-buildutils opgenomen, dus die zul je makkelijk op elke andere distro kunnen compilen. Een echt linux-equivalent zou ik zo niet weten, programma's zoals aide en tripwire zijn vergelijkbaar, maar die zijn puur op intrusion-detection gericht, en niet op het aanpassen ervan (als er een intrusion is wil je sowieso een complete restore doen). Ik geloof niet dat mtree extended attributes/ACL's doet, en filesystem flags zal hij op linux ook vast niet doen. Gelukkig worden deze op de meeste systemen niet zo heel veel gebruikt.

  • igmar
  • Registratie: April 2000
  • Laatst online: 05-01 19:56

igmar

ISO20022

Ik zou een combinatie van getfacl / setfacl gebruiken.

  • eghie
  • Registratie: Februari 2002
  • Niet online

eghie

Spoken words!

Topicstarter
Verwijderd schreef op dinsdag 14 april 2009 @ 04:19:
Het is een wilde gok maar: LVM Snapshots?

Zodra je je backup maakt maak je gewoon eerst een lvm snapshot en die gebruik je tevens om je backup te maken en laat je daarna openstaan. Bij het begin van de volgende backup-cycle eerst even je snapshot sluiten en weer opnieuw aanmaken. Maak natuurlijk een read-only snapshot aan.
LVM Snapshots is inderdaad een goede optie. Sowieso om backups te maken is dat zeker aan te raden. Maar om een snapshot open te laten staan tot de volgende backup zit mij een beetje tegen, zie:
LVM2 snapshot drains performance
LVM2 snapshot performance problems

Dus vanwege die performance problemen wil ik liever niet die snapshot open laten staan.

Ook heb ik niet alle bestandsystemen op een LVM draaien. De root van de servers en boot draaien daar niet op. Daarom kan ik ook beter een progje hebben wat de rechten apart van de backups opslaat in een bestandje.
Ik ken zelf geen programma om de rechten zelf terug te kopieeren maar een simpele cp -av zou al werken. Ik vraag me vooral af waarom je dit zou willen. Het probleem is vooral om de legale chmod's van de illigale te onderscheiden. Naar mijn idee zijn de rechten en de inhoud onlosmakkelijk met elkaar verbonden dus waarom je de rechten wel zou willen terug zetten maar de inhoud niet ontgaat me. Als een bestand verkeerde rechten heeft is de inhoud ook niet meer te vertrouwen. Een restore van beide is dus altijd wenselijk.
Als jij in een stomme bui een verkeerde chmod doet, of je hebt een script wat gigantisch gaar is wat verkeerde chmod doet. Of je laat iemand op je server, om wat voor reden dan ook en die maakt een fout, dan wil je toch een goede manier om dat te restoren. Ook al ben je Linus Torvalds, dan nog kun je perongeluk fouten maken met je commando's. Beter preventief tegengaan dan gaan wachten op je fouten en dan pas leren.

Ik vertrouw de inhoud van een bestand nog wel bij een verkeerde chmod/chown. Ik zet liever apart de rechten terug, dan de server een paar uur achteruit in tijd zetten (de data that is). Daarnaast duurt een full system backup langer met restoren dan full system rechten terug zetten.
Mijn kennis van tar is niet zo heel best meer maar volgensmij was tar toch best snel in het selectief restoren van bestanden dus tenzij je geen online full backup hebt is een LVM snapshot eigenlijk het beste al weet ik niet wat de snelheid zou zijn van een cp -av van de snapshot naar waar de snapshot van is gemaakt en of dat je daarbij het COW principie triggert dus je snapshot moet mischien net zo groot zijn.

Mischien is rsync nog wel de beste optie bedenk ik me nu. Rsync zou slim genoeg moeten zijn om te zien dat de bestanden in de snapshot en de data identiek zijn op de rechten na. LVM Snapshots + rsync is een winnaar denk ik maar ik moet toegeven dat ik zelf ook nog dit alles eens moet uitproberen.
Ik moet dat met Rsync ook eens proberen. Inderdaad Rsync zou slim genoeg ervoor moeten zijn. Eens kijken wat die kan restoren.
alson schreef op dinsdag 14 april 2009 @ 05:27:
Zelf zou ik in zo'n geval ook een volledige restore doen, wie weet is er nog meer stuk gemaakt. Verder zit je met bestanden die zijn aangemaakt na de laatste backup, die kun je niet terugzetten. Desnoods kun je na de restore nieuwere versies van bestanden als databases alsnog van het oude systeem kopiëren. Als het zo vaak gebeurt dat het stroomlijnen van dit proces belangrijk is zou ik toch eens nadenken of je de mensen met root rechten niet wat meer training moet geven of minder rechten moet geven.

Op *BSD systemen heb je mtree(8), dat kan met de -U optie permissies updaten naar aanleiding van een eerder aangemaakt spec bestand. Je kan dit bestand natuurlijk ook aanmaken op basis van een volledige backup. Ik weet zo niet of hij een foutmelding geeft bij nieuwe bestanden die niet in het spec bestand voorkomen, maar hij kan ze met de -r optie wel verwijderen, dus waarschijnlijk wel.

Debian heeft mtree in freebsd-buildutils opgenomen, dus die zul je makkelijk op elke andere distro kunnen compilen. Een echt linux-equivalent zou ik zo niet weten, programma's zoals aide en tripwire zijn vergelijkbaar, maar die zijn puur op intrusion-detection gericht, en niet op het aanpassen ervan (als er een intrusion is wil je sowieso een complete restore doen). Ik geloof niet dat mtree extended attributes/ACL's doet, en filesystem flags zal hij op linux ook vast niet doen. Gelukkig worden deze op de meeste systemen niet zo heel veel gebruikt.
Ik zou inderdaad eens naar mtree kunnen kijken ja. Zo te zien kan die wel wat ik wil. Al hoewel in hoeverre hij het kan moet ik nog zien. Ik ga die iig eens aan een goede test onderwerpen.
igmar schreef op dinsdag 14 april 2009 @ 15:19:
Ik zou een combinatie van getfacl / setfacl gebruiken.
Dat is zeker wel een goede optie, omdat die ook ACLs meeneemt. Nu moet die nog wel parseable zijn, maar daar vinden we wel wat op.

Verwijderd

Snapshots zijn inderdaad niet aan te raden voor filesystems met veel en grote writes.

Dit is omdat voor elk block dat wordt aangepast in het filesystem nadat de snapshot is aangemaakt eerst een kopie van het oorspronkelijke block naar de snapshot moet worden gekopieerd alvorens de write kan doorgaan. Het resultaat is veel overhead en fragmentatie. Echter hoeveel gigabyte's schrijf jij naar je /etc per uur?

Volgensmij hoeft alleen de /boot niet op lvm te staan met grub of lilo. Met grub 2 kan zelfs het hele systeem op lvm staan zonder problemen maar grub 2 is nog niet helemaal volwassen voor productie gebruik dacht ik.

Rsync + snapshots is wel het snelste en meest ruimte efficient voor read-mostly filesystems. Snapshots zijn zowiezo aan te raden tijdens het maken van de backup omdat je dan zeker weet dat het filesystem in een consistente staat blijft voor de duur van de backup.

mtree kende ik zo niet maarja ik werk vooral met Debian en niet *BSD maar als mtree alleen de rechten kopieert dan is mtree + snapshots mischien nog wel beter dan rsync omdat rsync ook de inhoud van elk bestand weer synchroniseert. Je schroeft inderdaad je server een paar uur terug in de tijd met rsync.

Toch denk ik dat de reden dat er weinig/geen echte tools voor dit probleem zijn precies is omdat de reden waarom de rechten niet meer geldig zouden zijn niet bekend is. Alleen de rechten terug zetten kan dus vele onverwachte bijwerkingen hebben en zeg nou zelf is het echt het risico waard om je systeem in inconsistente staat terug te zetten?

Ik zou zelf het risico nooit nemen en mijn server als geheel terug schroefen naar het punt waar zowel de rechten als data consistent zijn. Ik zou eerst gewoon een 2e snapshot aanmaken voor een backup zodat mocht er vitale informatie zijn toegevoegd sindsdien dan kan die altijd nog later worden herstelt en dan met rsync een full restore doen vanuit het 1e snapshot. Dankzij het Copy-on-Write principe van snapshots kan afhankelijk van de hoeveel informatie die is aangepast het hele systeem in een kwestie van minuten weer consistent worden gemaakt.

Nadat de 2e snapshot is aangemaakt kun je rsync alvast laten restoren en dan daarna een incremental backup laten forken vanaf je laatste backup zodat een full backup niet nodig is en belangrijke e-mails bijvoorbeeld alsnog altijd herstelt kunnen worden. Met zo'n backup strategie kun je als de snapshots nog intact zijn zeer snel je server herstellen naar een eerder punt zonder dat je je backups van de plank hoeft te halen of tientallen gigabytes aan data hoeft te kopieeren. Het kost je hooguit een paar gigabyte aan ruimte op je volumegroup.

Ik denk dat de performance penalty van snapshots wel meevalt zolang je niet tientallen gigabytes aan data loopt te schrijven. Het gaat vooral om die verhouding: hoe meer er procentueel is geschreven naar waar de snapshot van is gemaakt, hoe meer overhead en fragmentatie. Hou je snapshots gewoon klein op bijvoorbeeld 5% van het volume en dan valt het denk ik wel mee. Tijdens het herstellen van de backup ga je het wel merken natuurlijk.

Uiteraard is dit slechts theorie en ik zal nog eens flink gaan stoeien met lvm maar dit is hoe ik dit zou doen.
Pagina: 1