Amanda backup van Maildir - onnodig 'full'

[vanaalten]

Onlangs ben ik begonnen aan het opzetten van off-site backups van m'n prive-servertje:

• Backup naar Amazon S3 cloud
• Linux machine (Debian Wheezy), enkele persoonlijke directories (mail, pdf bestanden en zo)
• Backup-software: Amanda
• Doel: af en toe een full-backup, verder incrementals (storage&transfers besparen)
• Encrypted

In principe heb ik dit wel zo'n beetje werkend. Moet nog even testen of ik kan restoren, maar dat zit waarschijnlijk wel goed. Het gaat enkel nog mis voor m'n e-mail: die doet hij al drie dagen op rij 'full' terwijl het volgens mij incremental zou moeten, zoveel mail krijg ik niet.

Mijn amanda.conf:

code:

org "Backup of Maildir/My Documents"
logdir "/var/log/amanda"
infofile "/var/backups/state/curinfo"
indexdir "/var/backups/state/index"
mailto "mijn_mail"

# amazonaws S3
device_property "S3_ACCESS_KEY" "blablabla"
device_property "S3_SECRET_KEY" "geheim/bla"
device_property "S3_BUCKET_LOCATION" "EU"
device_property "S3_SSL" "YES"

tpchanger "chg-multi:s3:blablabla-backups/backup_my_documents/slot-{01,02,03,04,05,06,07,08,09,10,11,12,13,14}"
changerfile  "s3-statefile"
tapetype S3
tapecycle 14
dumpcycle 7

define tapetype S3 {
    comment "S3 Bucket"
    length 10240 gigabytes
}

define dumptype server-encrypt-fast {
      program "GNUTAR"
      comment "dump with fast client compression and server symmetric encryption"
      compress client fast
      encrypt  server
      server_encrypt "/usr/sbin/amcrypt"
      server_decrypt_option "-d"
}

... en de bijbehorende disklist:

code:

localhost Maildir     /home/vanaalten/Maildir server-encrypt-fast
localhost MyDocuments "/home/vanaalten/My Documents" {
  server-encrypt-fast
  exclude        "./Boeken & tijdschriften"
  exclude append "./Handleidingen"
  exclude append "./foto's"
}

Goed, de backup is dus tweedelig: Maildir en MyDocuments. Die laatste wordt zoals verwacht telkens 'incremental' gedaan, die eerste (Maildir) telkens full.
Dus maar eens wat in de logfiles gekeken, in dit geval een stuk van de amdump log:

code:

SETTING UP FOR ESTIMATES...
planner: time 0.000: setting up estimates for localhost:Maildir
(...)
setup_estimate: localhost:Maildir: command 0, options: none    last_level 0 next_level0 6 level_days 0    getting estimates 0 (-3) 1 (-3) -1 (-3)
planner: time 0.006: setting up estimates for localhost:MyDocuments
setup_estimate: localhost:MyDocuments: command 0, options: none    last_level 1 next_level0 6 level_days 1    getting estimates 0 (-3) 1 (-3) -1 (-3)
planner: time 0.017: setting up estimates took 0.016 secs

GETTING ESTIMATES...
(...)
planner: time 1.103: got partial result for host localhost disk MyDocuments: 0 -> -3K, 1 -> -3K, -1 -> -3K
planner: time 1.103: got partial result for host localhost disk Maildir: 0 -> -3K, 1 -> -3K, -1 -> -3K
planner: time 1.630: got partial result for host localhost disk MyDocuments: 0 -> -3K, 1 -> -3K, -1 -> -3K
planner: time 1.630: got partial result for host localhost disk Maildir: 0 -> 810770K, 1 -> -3K, -1 -> -3K
planner: time 1.706: got partial result for host localhost disk MyDocuments: 0 -> -3K, 1 -> -3K, -1 -> -3K
planner: time 1.706: got partial result for host localhost disk Maildir: 0 -> 810770K, 1 -> 3170K, -1 -> -3K
planner: time 2.572: got partial result for host localhost disk MyDocuments: 0 -> 1905360K, 1 -> -3K, -1 -> -3K
planner: time 2.572: got partial result for host localhost disk Maildir: 0 -> 810770K, 1 -> 3170K, -1 -> -3K
planner: time 2.777: got partial result for host localhost disk MyDocuments: 0 -> 1905360K, 1 -> 870K, -1 -> -3K
planner: time 2.777: got partial result for host localhost disk Maildir: 0 -> 810770K, 1 -> 3170K, -1 -> -3K
planner: time 2.778: got result for host localhost disk MyDocuments: 0 -> 1905360K, 1 -> 870K, -1 -> -3K
planner: time 2.778: got result for host localhost disk Maildir: 0 -> 810770K, 1 -> 3170K, -1 -> -3K
planner: time 2.778: getting estimates took 2.761 secs
FAILED QUEUE: empty
DONE QUEUE:
  0: localhost  MyDocuments
  1: localhost  Maildir

ANALYZING ESTIMATES...
pondering localhost:MyDocuments... next_level0 6 last_level 1 (not due for a full dump, picking an incr level)
   pick: size 870 level 1 days 1 (thresh 10240K, 2 days)
  curr level 1 nsize 870 csize 61 total size 160 total_lev0 0 balanced-lev0size 258064
pondering localhost:Maildir... next_level0 6 last_level 0 (not due for a full dump, picking an incr level)
   picklev: last night 0, so tonight level 1
  curr level 1 nsize 3170 csize 1585 total size 1778 total_lev0 0 balanced-lev0size 330563
INITIAL SCHEDULE (size 1778):
  localhost Maildir pri 1 lev 1 nsize 3170 csize 1585
  localhost MyDocuments pri 1 lev 1 nsize 870 csize 61

DELAYING DUMPS IF NEEDED, total_size 1778, tape length 10737418240 mark 1
  delay: Total size now 1778.
PROMOTING DUMPS IF NEEDED, total_lev0 0, balanced_size 330563...
   try localhost:Maildir 3 0 6 = 10
no try localhost:MyDocuments 3 0 6 = 10
   promote: moving localhost:Maildir up, total_lev0 507498, total_size 507691

Vraag 1: hoe moet ik dit lezen? Op het eind zie je dat de Maildir naar level 0 gepromote wordt, maar om welke reden? Hij heeft blijkbaar besloten dat een incremental dusdanig groot is dat een full beter is, maar zie ik die getallen hier ergens terug?

Vraag 2: kan ik op een makkelijke manier achterhalen welke bestanden allemaal in een incremental meegenomen zouden worden (indien daar voor gekozen was)? Ik heb al zitten experimenteren met "find Maildir -mmin -1440" om een lijstje van gewijzigde files te krijgen, maar dat is nog heel beschaafd weinig.

Ik heb wel gegoogled, maar kan maar weinig info terugvinden over hoe de incremental file list bepaald wordt - anders dan 'iets met tar en de index file', maar zelf nadoen is mij nog niet gelukt.

En ander commentaar op m'n aanpak is uiteraard ook welkom.

[vanaalten]

Toch een losse post i.p.v. de TS editten, om vraag/oplossing gescheiden te houden:

Om m'n eigen vragen te beantwoorden:
de 'amdump' log in /var/log/amanda is niet de meest informatieve log, er worden er nog flink wat meer aangemaakt. Wat erg informatief was was de logfile /var/log/amanda/client/backup_my_documents/runtar*debug. Daar vind je precies in hoe 'tar' gebruikt wordt; ook interessant zijn de 'sendsize' logs in diezelfde directory, daar vind je de resulterende getallen terug. In mijn geval, voor de twee directories:

code:

Tue Aug 20 03:00:02 2013: thd-0xc76200: sendsize: estimate size for Maildir level 0: 810770 KB
Tue Aug 20 03:00:02 2013: thd-0xc76200: sendsize: estimate size for Maildir level 1: 3170 KB
Tue Aug 20 03:00:03 2013: thd-0xc76200: sendsize: estimate size for MyDocuments level 0: 1905360 KB
Tue Aug 20 03:00:03 2013: thd-0xc76200: sendsize: estimate size for MyDocuments level 1: 870 KB

...ofwel, in beide gevallen lijkt een incremental mij wel de juiste keuze: d'r is maar heel weinig data veranderd, ook voor Maildir.

Dus wat verder gezocht: google op 'amanda promote dump' gaf mij deze pagina. Lijkt er dus op dat Amanda probeert om de hoeveelheid data transfer per backup-cycle ongeveer gelijk te houden. Daarvoor wordt een 'disk' ge'promote' van incremental naar full - ik gok dat dat precies is wat ik zie.

Noem mij maar een control freak, maar ik hou dat toch liever zelf in de hand - zeker als data storage en transfer mij geld kunnen kosten.
De oplossing lijkt te zijn door de optie "maxpromoteday 0" in de dumptype te specificeren, daarmee zou je het promoten van incremental naar full moeten verbieden. Even getest en een backup was nu volledig incremental.

Even afwachten, maar het lijkt daarmee opgelost te zijn.

[d1ng]

Je kan evt. ook even spelen met de bumpsize en bumppercent opties in amanda.conf

[vanaalten]

Eh... volgens mij juist niet. Nou ja, niet in dit specifieke geval in elk geval.
Bumpen is, als ik het goed heb begrepen, wanneer een full backup naar incrementeel wordt gezet. Met die opties geef je dus aan waar die grens ligt: indien een incremental 'bumpsize' bespaart t.o.v. full, dan kan 'ie een full gaan 'bumpen' naar een incremental backup.

Ik had het omgekeerde: iets dat begon als incremental werd omgezet naar een full backup. Met die 'maxpromoteday' optie hoop ik dat nu opgelost te hebben.