Scalix snapshot on an amanda client

[btisdall]

I'm using (for the first time) Amanda to backup an LVM snapshot of /var/opt/scalix and noticing a worrying discrepency between the size of the filesystem as reported by the usual *nix commands and the size as reported by Amanda.

root@bogus# du -s -BM /mnt/sxsnaptmp/

10467M /mnt/sxsnaptmp/

But Amanda reports ORIG-Kb as 5608240

These are the dump defs:

define dumptype global {
index yes
}

define dumptype scalix {
global
comment "mounted snapshot vol"
compress server fast
priority medium
}

And from disklist:

bogus.local /mnt/sxsnaptmp scalix

Could this be a simple permissions problem? I would've thought that amcheck would've
flagged up any errors in this regard and amdump wouldn't just silently
ignore. As far as any other dumps are concerned, the size corresponds.

One ray of hope is the Amanda amdump logs which do contain:

planner: time 101.996: got partial result for host bogus.local disk /mnt/sxsnaptmp: 0 -> 9870236K, 1 -> 309002K, -1 -> -2K

Which at least seems in the ballpark!

Is there anything about the Scalix message store that would cause this apparent discrepancy? Someone has suggested hard-linking of data where multiple copies of an item exist but even if that were the case du should only count these entries once unless the -l is passed.

Thanks,

[btisdall]

Since I notice that dump isn't on the supported list of backup methods I'll try the amanda run tonight using tar in its place..

[ScalixSupport]

Since I notice that dump isn't on the supported list of backup methods I'll try the amanda run tonight using tar in its place..

Probably stating the obvious, but with compression in your options you should be seeing some differences in disk usage. That said, there is nothing wrong with tar cvf /var/opt/scalix - | gzip >scalix.tar.gz

Cheers,

Sascha.

[btisdall]

Probably stating the obvious, but with compression in your options you should be seeing some differences in disk usage. That said, there is nothing wrong with tar cvf /var/opt/scalix - | gzip >scalix.tar.gz .

As I understand it ORIG-Kb refers to the size of the fs uncompressed. Anyway, with dump the numbers are looking much saner and a test restore to a tempdir yesterday got within a few MB of the real thing (some hours after the snapshot was taken).

I'm feeling a little more relaxed now!

Ben Tisdall

[btisdall]

Anyway, with dump the numbers are looking much saner

And by 'dump' I mean of course tar...

[obrodkin]

How do you integrate Amanda client with scalix_backup script (one that uses lv snapshot to tar entire store /var/opt/scalix/...)?

Thanks

[btisdall]

Amanda takes a little time to learn because of the breadth of its configuration options, but it's well worth the effort. Once you understand the basics then you just need an entry in /etc/amanda/<name>/disklist, which takes the form:

Code: Select all

hostname diskdev dumptype

e.g. to backup the snapshotted Scalix partition one might have:

Code: Select all

myhost.domain.com /mnt/snapshot/scalix-snapshot default

The dumptype is defined in /etc/amanda/<name>/amanda.conf:

Code: Select all

define dumptype default {
    index yes
    program "GNUTAR"
    compress server fast
    priority medium
}

I've been using amanda for eighteen months & I'm very happy with it as a backup/restore solution. It comes with a good set of tools like amrecover which allows one to restore single files easily using an ftp-like interface (provided you backup with indexes). OTOH in a disaster recovery scenario all you need is dd & tar to get your data off the tape.

I might think about getting some info up on the wiki.

[obrodkin]

I am familiar with amanda general setup. In addition to Scalix, I have another 4-5 servers to backup.

The question is how you coorrdinatte lv snapshot (which is I am creating only for backup window and deleting afterward) and amanda client backup schedule?

Thanks

[btisdall]

Ok, well I hope someone found that post useful anyway...

So are you saying that your Scalix box isn't the amanda server?

[obrodkin]

Ben,

That's correct, I have a server "amanda" that backup couple other servers including "scalix". So amanda's clients start kicking in somewhere after midnight, but scalix snapshot has to be ready. As I said, lvm snapshot created and deleted immediately after the backup is done.

BTW, why would you have scalix and amanda on the same box? Does it defeat the purpose of the backup?

Thanks

Oleg

[btisdall]

Hi Oleg,

assuming you're running amdump out of cron then you could run the run the snapshot creation script on the Scalix client in the same fashion say five mins before this & then the removal script at a time when you're certain the backup will be finished. It's not a great solution because obviously you can't be certain when amanda will finish dumping Scalix & so will have to leave the snapshot there for a generous amount of time. You do take a bit of performance hit whilst the snapshot's there, plus you need to make sure it doesn't fill up or the origin will go read-only.

Perhaps you could use a wrapper script round amdump that SSH's into Scalix & runs the create/remove snap scripts. You could use a passphrase-less key, host based auth or an expect script to do it programmatically.

You could also use a wrapper script around amdump that rsyncs the snapshot from Scalix beforehand & dump this instead (of course you'll still need to synchronise the snapshot creation/removal on the Scalix client using cron).

HTH.

Ben.