Topic: Affa rise - hard disk capacity needed

[StuC]

I have only recently tried Affa and am blown away by the efficiency and just plane "Does what is says on the tin".
I'm a little confused on the rise feature and haven't found disk size guidelines from normal searching, would appreciate some advice.

For example If I am backing up a production server with around 100G of data do I need a hard drive of twice that for safety or is it purely affa archive plus what's on the backup server + some headroom?

The documentation mentions " the rise process backs up the Affa server itself before doing the restore from the archive" so I assume if the the contents of the Affa server itself are around (for example) 6G the disk will require absolute minimum 106G+ (backup + affa archive) or does it need much more than that? I.E. does it copy the data to the "risen" location (extra 100G) then delete the archive?

I assume if I chose to rise an archive previous to the most recent I will then also need headroom for "unchunking" and for the archives to live side by side uncompressed.

The reason I don't just go with "Stick the biggest drive in you can get at the time" is that I mirror drives and like to keep size to roughly twice-data so on-the-shelf spares can be those readily available in worst case.

Thanks for any advice and sorry for the rambling questions

[janet]

StuC

... does it copy the data to the "risen" location (extra 100G) then delete the archive?

The wiki article says:
"The rise option uses hardlinks..."
As I read/understand it, the 106Gb size you mention is more like the requirement, as the backup job archive is not moved, just hard linked to.
That's part of the reason the rise process is so quick.

[StuC]

Ah yes I hadn't really thought about hardlinks, thanks.
I'll try it at the weekend, I only have about 30% more hard drive than backup so didn't want to make it fail.
Its only a testing-backup box so I could just tried but part of the test is how well it runs over time so didn't want to break it just yet.

====
Later
====
Made a second bigger disk affa backup machine, installed sysmon to watch disk use.
Did the rise, extra disk space used was only the local backup data.
On reading the documentation more thoroughly (I.E when not faced with a window of time to get it done) it is clear in there but I must have had the fog of "too many new variables" in the way.

One word of caution to anyone as sloppy as I have just been.
After rising the server, removing affa and old affa data I let it run for a day and half before adding a second identical WD2500KS drive. Basic ERROR.
The first drive had been a few things (sme, test installs etc.) and didn't show any problems. The second disk had previously been Formatted NTFS and used to take data off-site (little used - no problems seen)
Seems after synchronising drives first time they BOTH showed hard disk errors and raid got into a rebuild loop. A bit of digging and http://wiki.contribs.org/Monitor_Disk_Health told me all I needed to know. Have since used the Western Digital utility and both showed errors.

So the lessons for me; use new Disks not even "little used" and run the manufacturers disk checking utility to fully test any drives that "Seem OK" elsewhere before re-use even as test.
Use the full hardware set up for stability testing from the off.

As affa is so straight forward I had a few images of that file server to rebuild from elsewhere but I hadn't counted on two "good" drives with read errors at the same time locking the thing up.
Once the second disk has finished its full WD test I'll make sure it is not something strange about the combination...
HP ML115G5, AMD Opteron 1352, 2x 250G WD drives, 4G ram.

Sorry if that is off topic but didn't want to start a new confessional thread.