My opinion is that "snapshots" should be less persistent than full clone copies. Longer term retention should move to full clone then you don't have the snapshot overhead you've raised on your other thread. I can't imagine that there are so many administrators out there wanting to maintain week old snapshots. Those older ones would most likely have been mounted somewhere and spooled to tape. I could be way off base but I'd not feel so confident in a week old cow as I would with a week old clone. We here have been tossing around the idea of treating snapshot (or full clone) as backup media. Media that would contain a barcode and which could be migrated to physical tape. Currently this is the realm of VTL. VTL is a copy of your data written out in a sequential manner, if you could somehow create disk media via snapshot that the disk caches (Falconstor, Sepaton) use then you could get the long sequential read/write overhead out of the backup application and the host. Our issue with snapshot, as I mentioned on the other thread, is that there are no close ties to the upper level applications, this includes backup software like NetBackup and Legato. NetBackup has the "virtual backup" piece but I've not really seen it implemented. Ideally an interface for a database application to take a snapshot of its data and call it barcode xxxx03 could then be imported into your backup application as a virtual tape xxxx03. That "tape" could be cloned via NetBackup or disk cache software to real tape with barcode xxxx03 for off site storage (through an encryption device of course). I know there are data alignment issues that exist here with data sizes and physical tape sizes but we believe it's an avenue worth exploring. There are several opportunities to better admin quality of life here. One is that backup administrators would be able to continually manage their media in what they know, tapes with barcodes they can touch and feel. The other is DBA's could maintain a list of snapshots through something other than "glue code". It would integrate into the processes that exist around data protection. Christopher Wilson Storage Architect Verizon Business IT Solutions - IP Application Hosting 240 264 4136 vnet: 364 4136 -----Original Message----- From: dm-devel-bounces@xxxxxxxxxx [mailto:dm-devel-bounces@xxxxxxxxxx] On Behalf Of Vijai Babu Madhavan Sent: Friday, January 12, 2007 12:19 AM To: evms-devel@xxxxxxxxxxxxxxxxxxxxx; dm-devel@xxxxxxxxxx; linux-lvm@xxxxxxxxxx Subject: [RFC] Out of order snapshot deletion Hi, I thought I would bring this topic in a separate thread so that it can be discussed independently. As users start taking a bunch of snapshots and keep them as backups, we see the following use pattern when the snapshots get recycled. Different snapshots have different life cycle. When some one decides to keep 'x' snapshots, at the recycle phase, the least recent does not necessarily get deleted. As users want to keep the daily snapshots for a much longer period than the bi-hourly snapshots. In the same way, weekly snapshots live longer than daily snapshots. I think this is pretty much similar to the way the current backup tapes are managed. I want to know if this is the kind of use case that users are having or the developers are thinking. The reason why I am posting this is that this out of snapshot deletion scenario, poses some interesting challenges in the design on the solution of multiple snapshots that share blocks with each other, as it is a lot easier to design a solution where the least recent gets deleted always. Vijai -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel ______________________________________________________________________ This e-mail has been scanned by Verizon Managed Email Content Service, using Skeptic(tm) technology powered by MessageLabs. For more information on Verizon Managed Email Content Service, visit http://www.verizonbusiness.com. ______________________________________________________________________ ______________________________________________________________________ This e-mail has been scanned by Verizon Managed Email Content Service, using Skeptic? technology powered by MessageLabs. For more information on Verizon Managed Email Content Service, visit http://www.verizonbusiness.com. ______________________________________________________________________ -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
