Jump to content

Retrospect 13 and Grooming


Recommended Posts

Hi Forum,

 

I just wanted to point out that Retrospect 13 for Macintosh has a new "performance optimized grooming" feature. This is a totally redesigned grooming function. If you have experienced grooming failures in the past, you should upgrade to version 13 and try using the new Performance Optimized Grooming.

 

We have also greatly increased the speed of catalog rebuilds in the new version, but you will need to do at least 1 backup or another rebuild before the speed increases for future rebuilds will be seen.

 

Retrospect.com/upgrade

Link to comment
Share on other sites

Here is a link to the System Requirements for Retrospect 13 for Mac. We worked hard to maintain the same system requirements as Retrospect 12 for Mac. For instance, in addition to supporting El Capitan (10.11), Retrospect continues to support Snow Leopard (10.6).

 

Let us know if there is a place on the website that still includes outdated system requirements.

  • Like 1
Link to comment
Share on other sites

Hi Mayoff or bdunagan,

 

I gave jethro advice—based on my reading of the Mac User's Manual and viewing of Tutorials—in this post about how to create a Cloud Media Set copy of his installation's regular Media Set.  He's obviously got budget limitations, and is worried about how much cloud space he would have to pay for if he uses a commercial provider.  He said he's willing to have the cloud copy contain only the last year of backups, so I suggested he set an appropriate "Groom to Retrospect defined policy" for the Cloud Media Set.  

 

I later realized that the Copy Media Set script I suggested in step C2 might not execute the grooming policy (I think I read that somewhere but can't find it); therefore I suggested that, if the disk member of his new Cloud Media Set is as large as his regular Media Set, he might have to run a subsequent Groom operation on it.  I realize now that, if my concern is correct, this would mean that jethro would need to dedicate a 6TB disk drive as the destination for his initial Copy Media Set run, even though he hopes to groom the Cloud Media Set to significantly below that size before he ships the disk drive to his cloud provider for "seeding".

 

First, am I correct in thinking that a Copy Media Set script ignores any grooming option?

 

Second, if I am correct in thinking that,  I fervently suggest that Retrospect Inc. implement an age subset of "Groom to Retrospect defined policy" for action during the copying part of Copy Media Set to a Cloud Media Set for Retrospect Mac 13.5!  Doing that wouldn't involve any complicated CPU-bound processing, just "this backup is older than what the user wants to include in the copy, so let's not copy it".  I'm sure that many Retrospect administrator users will thank you for thus making cloud backup affordable and fast.

Link to comment
Share on other sites

Grooming is a property of a media set and not a script. If your destination media set is full and grooming is turned on, grooming will take place against that destination media set if more space is needed to finish the operation. . it doesn't matter what type of script you are using. Grooming has no idea what type of script you are using, just that more space is needed on the destination.

Link to comment
Share on other sites

Grooming is a property of a media set and not a script. If your destination media set is full and grooming is turned on, grooming will take place against that destination media set if more space is needed to finish the operation. . it doesn't matter what type of script you are using. Grooming has no idea what type of script you are using, just that more space is needed on the destination.

 

 

My understanding of what you're saying is that jethro should set up his new Cloud Media Set with a local member, turn on either "Groom to Retrospect defined policy" with Months to keep = 12 or "Groom to keep this number of backups" = 52 * number-of-jethro-backups-per-week , and define the size of his local disk member at—let's say—1TB.  He should then run a Copy Media Set script with that local member as the Destination.  When the script has copied 1TB of his 5TB of backups, it will start grooming because it has run out of space.  When it has finished that grooming, it will start copying backups again.  When the script has filled up his 1TB again, it will initiate another groom, and this copying-grooming cycling will continue until the Copy Media Set script has finished with the entire 5TB of jethro's regular Source Media Set.   :lol:

 

It no doubt will not surprise you that I think this cycling is "mentally challenged".  It may not surprise you too much that I think that Retrospect 13 will crash before it completes the Copy Media Set script.  As a matter of fact, I'm willing to "put my money where my mouth is"—specifically the $69 price of an upgrade from Retrospect 12.5 to Retrospect 13.  I'll bet that if either jethro or Retrospect Inc. tries this on a Source  Media Set which is 5 times the size of the Destination Media Set, the Copy Media Set script will either (1) take more than 15 hours to complete for each TB in the Source or (2) crash.  If I lose the bet, I'll pay for the upgrade—which I wasn't planning to get because my Internet upload speed is too slow for Cloud backup.  If I  I win the bet, Retrospect Inc. will give me the upgrade for free.

 

Do we have a bet, Robin? :D    If so, please contact jethro and me via e-mail.

 

Either way, I think the general "mentally-challengedness" of this copying-grooming cycling, for potential Cloud backup users of Retrospect 13, explains why I suggest that Retrospect Inc. implement an age subset of "Groom to Retrospect defined policy" for action during the copying part of Copy Media Set to a Cloud Media Set for Retrospect Mac 13.5.  :) 

 

P.S.: In first sentence of my first paragraph, added alternative for "Groom to keep this number of backups"—assuming jethro knows how many backups per week he has done to his regular Media Set and wants to keep the latest 52 weeks of backups in his Cloud Media Set.  Using this alternative might somewhat speed up the cycling grooms, but I suspect not by all that much—and it might even slow down the cycling grooms.

 

P.P.S. Replaced "brain dead" with "mentally challenged"; I originally wanted to use another term closely related to "brain dead", but I understand that term causes pain to those with relatives who are "mentally challenged".  Just to make it clear, I admire Retrospect Inc. for its current computationally-intense implementation of grooming; it's just that that implementation becomes highly inappropriate when applied to what jethro—the forerunner of many other Retrospect users—is trying to do to add cloud backup to his current onsite backup at a reasonable cost.  :) 

Link to comment
Share on other sites

My understanding of what you're saying is that jethro should set up his new Cloud Media Set with a local member, turn on either "Groom to Retrospect defined policy" with Months to keep = 12 or "Groom to keep this number of backups" = 52 * number-of-jethro-backups-per-week , and define the size of his local disk member at—let's say—1TB.

That is reading a lot into what I said. The number of months or past backups being kept is really up to the user and how much data they need to maintain. In any case, if the disk gets full, that will force a groom to run based on whatever grooming settings you have selected. If grooming i set to keep 52 backups, it probably can't groom much of anything. Best practices are at http://www.retrospect.com/en/support/kb/grooming-tips-and-troubleshooting

 

It may not surprise you too much that I think that Retrospect 13 will crash before it completes the Copy Media Set script.

Retrospect should never crash. If it is, please contact support@retrospect.com. This forum is not an official support channel. It is a community based support tool and Retrospect employees do not typically visit the forum every day.
Link to comment
Share on other sites

That is reading a lot into what I said. The number of months or past backups being kept is really up to the user and how much data they need to maintain. In any case, if the disk gets full, that will force a groom to run based on whatever grooming settings you have selected. If grooming i set to keep 52 backups, it probably can't groom much of anything. Best practices are at http://www.retrospect.com/en/support/kb/grooming-tips-and-troubleshooting

....

 

 

No, it is reading precisely the implications of what you said—assuming Retrospect 13 can successfully execute a Copy Media Set of jethro's regular Media Set into his proposed Cloud Media Set local member on a smaller shippable disk drive.

 

I'm sorry, Mayoff; I'm afraid my leaving a message on your voicemail yesterday caused your fingers to engage the keyboard before your brain was fully in gear.  ;)   What you should have written instead yesterday was "Your deductions about multiple copying-grooming cycles and their speed may be right, or they may be wrong.  I'll check with the Retrospect Inc. engineers, and get back to the forum with the answer later this week."

 

Your subsequent post might be:

 

EITHER

"Your deduction about multiple copying-grooming cycles for a Copy Media Set script was wrong, because—despite the implications of what I wrote—Retrospect cannot do multiple cycles for such a script.  Therefore jethro will have to purchase a 6TB drive [for $200 to $350 depending on quality—assuming he only wants USB3] for initially creating his local member, and then run a separate Groom to cut the size of that local member down to his desired 1TB before shipping it to his cloud provider."  :( 

 

OR

"Your deduction about multiple copying-grooming cycles for a Copy Media Set script was right.  However, because of the wonders of the new "performance optimized grooming" feature in Retrospect 13, the grooming phases will be much faster than stated in item 9 of http://www.retrospect.com/en/support/kb/grooming-tips-and-troubleshooting [which BTW is 3.5 years old].  Therefore Retrospect Inc. would be pleased to take your proposed bet, because we want you to pay a $69 upgrade fee."  :D 

Link to comment
Share on other sites

....

Retrospect should never crash. If it is, please contact support@retrospect.com. This forum is not an official support channel. It is a community based support tool and Retrospect employees do not typically visit the forum every day.

 

 

I'm sorry you dislike the term "crash".  If you can come up with a more precise short term for "abort the grooming operation, requiring the Media Set catalog to be rebuilt"—as outlined in item 8 of the Resource you linked to, I'll use it.  ;)

 

As far as "This forum is not an official support channel" is concerned, I had thought that Retrospect employees at least regularly looked at the "Retrospect bug reports" sub-forum of this forum.  However, as a result of what you stated yesterday, I have today condensed all the posts in my http://forums.retrospect.com/index.php?/topic/152169-client-530-error-workaround-from-retrospect-inc-tech-support/  thread into an e-mail and mailed it to support@retrospect.com.  I received an Retrospect Agent Reply, giving me a case number.  I updated that case with additional information, including the statement that I had merely intended to supply debugging data for -530 errors—which A. had told me several weeks ago were already being investigated.  I also stated that I don't want a separate case established for me, and do not intend to pay $70—but merely want to learn when the -530 error bug is fixed.  Did I do right, or was it not necessary to burden Retrospect Support with officially dealing with information in this forum that is already linked to in the "Retrospect bug reports" sub-forum?  :unsure:

Link to comment
Share on other sites

Mayoff, here's a knotty question for you about grooming from jethro's thread; you can ask your engineers:


Lennart Thelander, on 16 Mar 2016 - 4:19 PM, said:snapback.png

No, what you see in the Finder is basically different from what Retrospect sees.

Say that one .rdb file contains about ten 60 MB files. Retrospect should groom out one of them, because the original has been deleted a long time ago. During the groom, the .rdb becomes 60 MB smaller and gets a new modified date in the Finder. That does not affect Retrospect's ability to perform more grooming later.

Say that another .rdb file contains some files that were deleted a long time ago (or that were replaced with newer versions a long time ago). Since all contents of this .rdb file is now obsolete, there is no need for Retrospect to keep it after the groom. So it will be completely removed.

 

 

I'm sure what you [Lennart] say in your second paragraph is true for what is now called "storage-optimized grooming".  However, according to the appropriate section in "Chapter 1 • What's New" in the  Retrospect Mac User's Guide for Version 13, it doesn't appear to be true for the new "performance-optimized grooming".  "Performance-optimized grooming makes certain decisions about what data to remove, only removing outdated backup information that it can quickly delete. On a technical level, this faster grooming mode only deletes whole RDB files instead of rewriting them. For this reason, cloud backup sets/media sets only support performance-optimized grooming [my emphasis]. This requirement ensures customers can efficiently groom out old backup information without rewriting their cloud data set."

 

This would probably be OK for jethro's new cut-down Media Set ("backup set" is an old term that is still used in Retrospect for Windows) once it is "seeded" and has a true Cloud member.  Given what jethro says about his installation being a graphic design office, I doubt that whether it deletes or splits a .rdb file that is 12 months old would make much difference.

 

However I wonder whether the same would be OK for jethro's new cut-down Media Set while it still is a local member on his shippable hard drive.  I'm not sure  whether the prohibition on "storage-optimized grooming" applies to that local member as well.  Even more important, I'm not sure whether "performance-optimized grooming" changes the modification dates of .rdb files that are left after grooming.  If it does, it would likely mean that .rdb files that are left after a Groom on that local member specifying "Groom to Retrospect defined policy" with Months to keep = 12  could not be later groomed out—say 3 months later—in the true cloud member without deleting all of them or none of them.

 

This is an important-enough question that I have cross-posted the entire post in this thread.

 

On the other hand, it appears that you [Mayoff] might then also post—assuming multiple copying-grooming cycles really happen for a Copy Media Set script:

 

"Your deduction about multiple copying-grooming cycles for a Copy Media Set script was right.  However, because of the wonders of the new "performance optimized grooming" feature in Retrospect 13, the grooming phases will be much faster than stated in item 9 of http://www.retrospec...troubleshooting [which BTW is 3.5 years old].  Therefore Retrospect Inc. would be pleased to take your proposed bet, because we want you to pay a $69 upgrade fee."  :)

 

BTW, Mayoff, the section of "Chapter 1 • What's New" I quoted in the first paragraph refers to "RDB files".  For most of us with any kind of IT experience since about 1985, RDB means Relational Data Base.  It wasn't until I read Lennart's post quoted above, and then looked inside one of my Media Sets, that I realized that the extension for individual Retrospect backup files is .rdb—and that "whole RDB files" in the section I quoted isn't talking about a Relational Data Base.  I understand that the original developers of Retrospect picked that extension in ignorance of what RDB would later mean.  However, would it be too much trouble for Retrospect Inc.—while it is adding the three sentences I have suggested in the third paragraph of this post to the "Cloud Backup" section of that same chapter—to also clarify what RDB means?

Link to comment
Share on other sites

It's been over a week since I proposed my bet on grooming for jethro's requirements to Retrospect Inc..  Since they haven't posted or e-mailed me about it since, I assume they either haven't tested the 5TB-to-1TB auto-groom during Copy Media Set—or found it doesn't work.  Therefore I'm going to have to go into my benevolently-preachy-old-man mode for this post;  please excuse me.   ;)

 

I did just enough research for later posts in jethro's thread to discover that storage for jethro's 1TB at Retrospect-certified cloud storage providers isn't cheap.  For Amazon S3 or Google Cloud Storage the cost would be about $30/month (for DreamHost DreamObjects—assuming jethro's company is American or Canadian—it would only be $20/month at the Retrospect reduced rate, but DreamHost doesn't do "seeding" or "large scale recovery"—so they wouldn't be suitable), not counting get/put charges that I can't estimate.  Therefore, IMHO, what jethro wants to do in cutting down his local backups for "seeding" is probably quite typical of what other Retrospect users would want to do when using cloud storage as an off-site safety net.    B)

 

Now let me make a marketing assumption: Retrospect Inc.'s engineers weren't permitted to spend the best part of 6 months implementing Cloud Backup just because everybody thought it would be sexy.   :D  I further assume the Retrospect product is under some competitive pressure from a product I will here refer to as CP.  IMHO Retrospect Cloud Backup can compete on a cost basis with CP at any installation with at least 6 machines, because Retrospect implements what I call a "two-level client" concept in which only the "second-level client"—known to us as the "Retrospect backup server"—actually interacts with real cloud storage.  To top it off, CP quietly eliminated its "seeding" option about 4 months ago—making centralized file backup for an installation such as jethro's rather tricky.  However CP has no cloud storage charge, only a monthly per-machine charge, so to compete with CP Retrospect must really make grooming work.

 

Even though the concept of repeated copy-groom cycles during a Copy Media Set run I proposed here is indeed "mentally challenged" (copying files and then deleting most of them!   :lol: ), it might be a barely-acceptable stopgap approach if the new "performance optimized grooming" feature in Retrospect 13 is really as speedy as the Ver. 13 Mac User's Guide says it is.  In the long run, however, it is clear that Retrospect Inc. must implement an age subset of "Groom to Retrospect defined policy" for action during the copying part of Copy Media Set to a Cloud Media Set for Retrospect Mac 13.5.

 

So "let's get the show on the road!"  Retrospect Inc. should ASAP ship jethro a beta-version Retrospect Mac 13.1 in which repeated copy-groom cycles during a Copy Media Set run really work.  It should accompany that with a loaner 6TB disk drive, and let jethro run a test.  If Retrospect Inc. sets it up as a 501c3 subsidiary (for non-Americans, that's a non-profit charitable organization to which donations are tax-deductible), I'll even donate $25 to the Retrospect Loaner Disk Foundation.   :)  And I predict we're going to need that Foundation, because lots of Retrospect customers are going to need loaner disk drives for "seeding" their Cloud Media Sets.

Link to comment
Share on other sites

I've found Retrospect 13's local 'storage optimized' grooming process to be a massive improvement over 12.5. It's faster, and it works! So far I'm very pleased with the R13 upgrade.

 

Question 1) I'm trying to figure out exactly how cloud based media gets groomed though - with Performance Optimized grooming, the description says it deletes whole RDB files. Does this mean -

 

a) In order to reduce the size of the media set (bucket) during the groom, a new RDB file is uploaded containing all but the groomed information, then the old RDB file is deleted, resulting in a smaller bucket at the end, as opposed to local storage where the RDB file gets trimmed of the groomed data? Or -

 

B) does an RDB file just sit there untouched as more and more internal pieces of it are marked as 'useless' until everything in the RDB file is useless and it gets deleted?

 

Just trying to wrap my head around how much storage we will be using over time. Should it be the same as what's on our local drive?

 

Question 2) I desire storing everything locally for fast large restores. If we use a D2D2C model with local backup first, then transfer to cloud backup later, do we need to groom both media sets separately, or will grooming the local set push that grooming reduction along to the cloud media set? Or should we maintain two separate backup scripts to backup locally and to the cloud set? How does this scenario work?

 

Thanks,

-Derek

 

(edited to disable emoticons. B) turns into a smiley)

Link to comment
Share on other sites

I've found Retrospect 13's local 'storage optimized' grooming process to be a massive improvement over 12.5. It's faster, and it works! So far I'm very pleased with the R13 upgrade.

 

Question 1) I'm trying to figure out exactly how cloud based media gets groomed though - with Performance Optimized grooming, the description says it deletes whole RDB files. Does this mean -

 

a) In order to reduce the size of the media set (bucket) during the groom, a new RDB file is uploaded containing all but the groomed information, then the old RDB file is deleted, resulting in a smaller bucket at the end, as opposed to local storage where the RDB file gets trimmed of the groomed data? Or -

 

B) does an RDB file just sit there untouched as more and more internal pieces of it are marked as 'useless' until everything in the RDB file is useless and it gets deleted?

 

Just trying to wrap my head around how much storage we will be using over time. Should it be the same as what's on our local drive?

 

Question 2) I desire storing everything locally for fast large restores. If we use a D2D2C model with local backup first, then transfer to cloud backup later, do we need to groom both media sets separately, or will grooming the local set push that grooming reduction along to the cloud media set? Or should we maintain two separate backup scripts to backup locally and to the cloud set? How does this scenario work?

 

Thanks,

-Derek

 

Hi, Derek; it's good to have the voice of your experience in this thread.  :)

 

I think you should read the thread started by jethro, starting with a careful reading of the first long paragraph of this post—which is the result of my having figured out the inadequately-documented brilliant  :wub:  key concept in Retrospect 13's handling of both "seeding" and "restore to door" for Cloud Media Sets.  You should then skip down two posts to read my step-by-step procedure for doing "seeding", which I have continually revised in the light of new information from Mayoff and careful thought.

 

What you should take away from those posts is that the local Member of a Cloud Media Set is just an intermediary for "seeding", which is created on a shippable hard drive purely for the purpose of being uploaded to a true cloud Member, and whose Retrospect catalog entry is AFAIK hijacked by that true cloud member as soon as its provider account parameters have been typed in.  When you get your "seeding" drive back from the cloud provider, Retrospect has AFAIK no knowledge of it unless you create another Disk Media Set whose Member is the contents of that drive—and I'm not sure why you would want to do that.

 

It is clear to me, even from the inadequate description in "Chapter 1 • What's New" of the new User's Guide, that "performance optimized grooming" is designed  to minimize get/put operations on true Cloud members.  So the answer to your Question 1) is B] (which I must write that way because—thanks to a "peculiarity" in the Retrospect Forums software—if I write it as 'b' or 'B' followed by ')' it gets turned into this B) smiley—as happened in your post).  Furthermore I'm not sure that "more and more internal pieces of it are marked as 'useless'", unless that marking is done in the catalog for the Cloud member (which is still maintained on a local non-cloud drive), because marking part of an .rdb file as useless would involve expensive-and-slow gets and puts in the cloud.  My guess is that the only rewriting of an .rdb file in the cloud is done when "everything in the RDB file is useless and it gets deleted".  That IMHO is what "Chapter 1 • What's New" in the Retrospect 13 User's Guide means when it says "On a technical level, this faster grooming mode only deletes whole RDB files instead of rewriting them."  Which is why you have to do the kind of calculations jethro does further down the thread.

 

The answer to your Question 2) is contained in my step-by-step procedure for doing "seeding" in jethro's thread.  It is, as I said two paragraphs above this, that the local Member of a Cloud Media Set is just an intermediary for "seeding"—which effectively disappears from Retrospect's knowledge after that "seeding" is done.  If you groom the local Member of a Cloud media set before "seeding" it—and BTW I'm not sure whether that can be "Storage-optimized grooming" or whether it can only be "Performance-optimized grooming", that grooming  is reflected in what is "seeded" to the true Cloud member.  Afterwards you must backup to and groom the true Cloud member separately, and any grooming you may do afterwards to your original Media Set that you copied into the local member of the Cloud Media set will have no effect on the true Cloud member. 

 

P.S.: Expanded my answer to Question 1), added an answer to Question 2).  Sorry for the intervening break in time.

Link to comment
Share on other sites

Hi David,

 

Thank you for the thorough reply. I read jethro's thread and your replies there. The reason I posted here in the grooming thread was because I'm not worried about seeding. I know the initial upload may take some time. I'm more curious about how Retrospect grooms, trying to figure out what our storage buckets will end up like over time. Based on the attempts to be conservative with gets and puts, and the very very low cost associated with them, I'm not too worried about that either. I just want to have a better understanding of how the grooming works. Is it going to rewrite the rdb file with a smaller one, (one delete, one put as I see it), or just keep track of the groomed info locally until it can delete that rdb entirely?

 

II'm also trying to figure out if we can have a local copy of the data and keep it in sync with the cloud copy of data. I'm thinking that the backup strategy goes something like this.

- Backup script A backs up clients to media set Local Disk A.

- Transfer Script A transfers Local Disk A to cloud based media set 'Cloud B'.

     - Repeat several times.

- Grooming script grooms Local Disk A and Cloud B.

- Backup script A and Transfer Script A resume their normal operations and both media sets are the same size (assuming the same grooming parameters)?

 

 

I'm also trying to figure out a similar scenario but using slightly different parameters, where locally we have 6 months or 12 months grooming policy, but the cloud media has 'Groom to 3' or something like it. I think this is what you are describing earlier where you said

age subset of "Groom to Retrospect defined policy" for action during the copying part of Copy Media Set to a Cloud Media Set

 

 

Also, if you go to 'more reply options' which opens the full reply editor, there is a checkbox on the right for "enable emoticons". Uncheck that and B) works normally! Being a tech forum, I think these should be turned off by default! Also there is no way to set your standard 'Post Options' defaults anywhere I can find in the user settings here.

Link to comment
Share on other sites

Hi David,

 

Thank you for the thorough reply. I read jethro's thread and your replies there. The reason I posted here in the grooming thread was because I'm not worried about seeding. I know the initial upload may take some time. I'm more curious about how Retrospect grooms, trying to figure out what our storage buckets will end up like over time. Based on the attempts to be conservative with gets and puts, and the very very low cost associated with them, I'm not too worried about that either. I just want to have a better understanding of how the grooming works. Is it going to rewrite the rdb file with a smaller one, (one delete, one put as I see it), or just keep track of the groomed info locally until it can delete that rdb entirely?

 

....

 

 

If you're not worried about seeding, then you must work in an establishment with very fast Internet connections.  Not all of us are so lucky, which is why jethro started his thread.

 

I don't have any inside information about Retrospect grooming.  In fact, in my small home installation that Recycles one of its three daily-backup Media Sets each week, I don't use grooming at all.  However I assume that Retrospect Inc. engineers weren't permitted to expend effort implementing "performance-optimized grooming" in conjunction with Cloud Backup just because everybody thought it would be sexy.  For competitive reasons the engineers are not likely to tell us exactly why they implemented it.  However it's likely that they determined that gets and puts and deletes on a real Cloud member of a Cloud Media Set would cost processing time and—for any user not in a position to install Basho Riak S2 on his/her own server—money as well.  Therefore I think we'd better treat "this faster grooming mode only deletes whole RDB files instead of rewriting them" as meaning that it is not going to rewrite an .rdb file as a smaller one.

 

....

 

II'm also trying to figure out if we can have a local copy of the data and keep it in sync with the cloud copy of data. I'm thinking that the backup strategy goes something like this.

- Backup script A backs up clients to media set Local Disk A.

- Transfer Script A transfers Local Disk A to cloud based media set 'Cloud B'.

     - Repeat several times.

- Grooming script grooms Local Disk A and Cloud B.

- Backup script A and Transfer Script A resume their normal operations and both media sets are the same size (assuming the same grooming parameters)?

....

 

That's consistent with what I wrote in this step-by-step post in jethro's thread.

....

 

I'm also trying to figure out a similar scenario but using slightly different parameters, where locally we have 6 months or 12 months grooming policy, but the cloud media has 'Groom to 3' or something like it. I think this is what you are describing earlier where you said ....

 

 

Also, if you go to 'more reply options' which opens the full reply editor, there is a checkbox on the right for "enable emoticons". Uncheck that and  B) works normally! Being a tech forum, I think these should be turned off by default! Also there is no way to set your standard 'Post Options' defaults anywhere I can find in the user settings here.

 

 

Yes, when I said "age subset of 'Groom to Retrospect defined policy' for action during the copying part of Copy Media Set to a Cloud Media Set", I was dealing with the situation that jethro's regular on-site Media Set has a no-grooming policy but he wants his Cloud Media Set copy to have a 12 months grooming policy.  My point was that, if he could institute the 12 months grooming policy without invoking copying-grooming cycles as part of his Copy Media Set to the initial local Member of his Cloud Media Set—rather than have to institute the policy by doing a separate Groom before "seeding"—he could both use a smaller disk for the local Member and save a lot of "mentally challenged" computer time.  The same would be true in spades for you, if you elect to do a Copy Media Set over the Internet straight to the true Cloud member of your Cloud Media Set.

 

Being a tech forum dealing with backup, and especially with Retrospect, I think we need all the nuance we can get from emoticons.  For example, look at my first two paragraphs in this post.  Notice that the first sentence in my first paragraph, and the third sentence in my second paragraph, seem rather sarcastic.  Ordinarily I would have put "winkie" emoticons after them to show that I didn't really intend to be sarcastic.  However, to make a point with you, I left the emoticons out in this post.

Link to comment
Share on other sites

  • 2 years later...

Much of the discussion in this thread from my 10 March 2016 post on turns out to be unnecessary.  That is because a new Cloud Media Set creator's  separate shippable disk drive for "seeding" will not need to be the same size as his/her regular Media set, and he/she won't have to do Grooming of the "seeding" Media Set after creating it.  It looks as if a Copy Media Set script, which would create the "seeding" Media Set on the shippable disk drive, can have a Rule to do any desired cutting-down in the same script.

It goes without saying that this has not been a sterling example of thinking by either me or the head of Retrospect Tech Support.  My fault for not having read enough of the UG to realize that a Copy Media Set script can have custom Rules, which I don't personally use.  His fault for not having read enough of this and linked-to threads to realize that what other posters needed to do could be accomplished by another method than Grooming.

BTW as of Retrospect Mac/Windows 15.1 a Groom script—which was never relevant to this thread—now (thanks to GDPR) can also have custom Rules.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...