I am trying to understand the concept behind the stacks.

Too me it looks that it offers mainly an other level of redundancy.

I have two scenarios where this might be of use, but I am not sure:

1) Instead of a file system backup of an archive to an other disk, I can now use a stack. Here the advantage seems clear: Instead of copying the whole file every time, stacks can update incrementally. Very handy if the backup location is online and bandwidth limited. Right?

2) Instead of two independent archives on two disks I can now have an archive on one disk and the stack on an other. What's the advantage of stacks here?

Would be nice, if you could shed some light on my thoughts.

And one more question:
Is it planned to support stacks via FTP?

Thanks,
Johannes

Johannes wrote:I am trying to understand the concept behind the stacks.

An archive and a stack are logically equivalent, but physically different.

In both, each layer represents the file data that changed since the previous layer.

In an archive, all of the data is stored together in one big pool. In a stack, the minimum data required to describe each layer is stored in individual "chunks" (be that files or data objects) which are physically isolated from one another.

This means the archive is efficient at tasks that require all of the information (capture, merge, etc.) while stacks are very efficient at copying and replacing individual layers with changes.

Too me it looks that it offers mainly an other level of redundancy.

That's exactly what it is. A stack is an efficient clone of an archive, organized in such a way that layers can be individually added and updated.

I have two scenarios where this might be of use, but I am not sure:

1) Instead of a file system backup of an archive to an other disk, I can now use a stack. Here the advantage seems clear: Instead of copying the whole file every time, stacks can update incrementally. Very handy if the backup location is online and bandwidth limited. Right?

Correct, and this is the primary use case of a stack. To have a (probably remote) copy of your archive that can be quickly and efficiently updated with new data as the archive grows and changes.

2) Instead of two independent archives on two disks I can now have an archive on one disk and the stack on an other. What's the advantage of stacks here?

A stack doesn't directly replace this scenario, but does support off-site swapping with three disks:

1: A primary drive with an archive that gets updated regularly.
2: A removable drive (A) containing a stack that duplicates the primary archive.
3: Another removable drive (B) containing a second stack that duplicates the primary archive.

Then your back strategy looks like this. Constantly keep the archive up-to-date with captured files. Occasionally update the stack (A) on the first removable drive from the archive. On a regular (typically weekly) schedule, take the first removable drive (A) off-site, pick up the second removable drive (B) and bring it back. Immediately update the second removable stack (B) with all accumulated changes in the archive. Repeat.

The worst likely disaster (i.e. fire) is you lose both the archive and the local removable stack drive. You'd then recover from the off-site stack. A more likely scenario is any one of the drives fail. If the archive drive files, simply restore it from the most recently updated stack. If a stack drive fails, simply replace it and create a new stack.

And one more question:
Is it planned to support stacks via FTP?

That is possible, and within the design, but so far (at least until today), no one has asked for it. We're currently concentrating on filesystem, AWS, AWS-compapible, DropBox, GoogleDrive, and iCloud based stacks. But adding FTP wouldn't be difficult. (We've also considered R/W optical media.)

I hope that helps.