<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
	<channel>
		<title><![CDATA[Latest posts for the topic "Understanding Stacks"]]></title>
		<link>https://forums.qrecall.com/posts/list/3.page</link>
		<description><![CDATA[Latest messages posted in the topic "Understanding Stacks"]]></description>
		<generator>JForum - http://www.jforum.net</generator>
			<item>
				<title>Understanding Stacks</title>
				<description><![CDATA[ I am trying to understand the concept behind the stacks. <br> <br>Too me it looks that it offers mainly an other level of redundancy. <br> <br>I have two scenarios where this might be of use, but I am not sure: <br> <br>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? <br> <br>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? <br> <br>Would be nice, if you could shed some light on my thoughts. <br> <br>And one more question: <br>Is it planned to support stacks via FTP? <br> <br>Thanks, <br>Johannes]]></description>
				<guid isPermaLink="true">https://forums.qrecall.com/posts/preList/4572/9188.page</guid>
				<link>https://forums.qrecall.com/posts/preList/4572/9188.page</link>
				<pubDate><![CDATA[Wed, 4 May 2022 13:10:58]]> GMT</pubDate>
				<author><![CDATA[ Johannes]]></author>
			</item>
			<item>
				<title>Understanding Stacks</title>
				<description><![CDATA[ [quote=Johannes]I am trying to understand the concept behind the stacks.[/quote]<br>An archive and a stack are logically equivalent, but physically different.<br><br>In both, each layer represents the file data that changed since the previous layer.<br><br>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.<br><br>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.<br><br>[quote]Too me it looks that it offers mainly an other level of redundancy.[/quote]<br>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.<br><br>[quote]I have two scenarios where this might be of use, but I am not sure:<br><br>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?[/quote]<br>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.<br><br>[quote]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?[/quote]<br>A stack doesn't directly replace this scenario, but does support off-site swapping with three disks:<br><br>1: A primary drive with an archive that gets updated regularly.<br>2: A removable drive (A) containing a stack that duplicates the primary archive.<br>3: Another removable drive (B) containing a second stack that duplicates the primary archive.<br><br>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.<br><br>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.<br><br>[quote]And one more question:<br>Is it planned to support stacks via FTP?[/quote]<br>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.)<br><br>I hope that helps.]]></description>
				<guid isPermaLink="true">https://forums.qrecall.com/posts/preList/4572/9205.page</guid>
				<link>https://forums.qrecall.com/posts/preList/4572/9205.page</link>
				<pubDate><![CDATA[Wed, 4 May 2022 19:05:44]]> GMT</pubDate>
				<author><![CDATA[ James Bucanek]]></author>
			</item>
	</channel>
</rss>