Jump to content

moving rdb files to another disk


Recommended Posts

I am having some problems rebuilding a media set from members located on two SMB NAS shares. So I want to move them to a couple of USB disks and so off the network.

 

Unfortunately although the total size of my 2 USB disks is more than adequate (2x 4TB), one of the NAS shares that contains most of the data has 4.2TB of retrospect data. i.e. 200 GB more than will fit on either of the USB drives. I wondered whether, given that the rdb files that make up the data are in 630 MB chunks, can I redistribute them across the 2 USB disks and still have a chance of rebuilding a media set out of them?

  • Like 3
Link to comment
Share on other sites

Further to my question about redistributing rdb files to new folders... In the directory structure created by Retrospect there is a single file in the Retrospect folder that contains the media set folders called "Backup Media". It is 0 kb and I guess just flags something to Retrospect. Any ideas what this is and whether I need to recreate it in my new folders on my USB disks?

Link to comment
Share on other sites

  • 1 year later...

A related question: If I have a backup set spread across two drives can I move, say, the last 5 RDB files from the first drive in the backup set to the 2nd drive in the backup set and then do a rebuild?  (Note:  I've have learning that this technique won't work if you take RDB files from the middle of the first drive in the backup set and move them to the 2nd drive in the backup set.  Rebuild doesn't like that.)

Link to comment
Share on other sites

In my experience, Retrospect doesn't tolerate moving .rdb files to a different volume. I'll be interested to know if you have success.

 

 

A related question: If I have a backup set spread across two drives can I move, say, the last 5 RDB files from the first drive in the backup set to the 2nd drive in the backup set and then do a rebuild? 

 

You are on your own here. :)

 

I don't understand the purpose of moving a few (or many) files to another disk.

Link to comment
Share on other sites

The reason for wanting to do this is its a handy way (compared to rearranging things via Retrospect) to free up space on a disk that has become too full for defrag to run, for instance.  The correct, longer term solution is of course to allocate space to Retrospect in such a way that there's *always* available space on the volume.  I had failed to do so in the case of the one disk volume.

 

My testing confirms your suspicion that this won't work.  The rebuild announces that the first volume of the two volume backup set is either corrupt or is from another set, and kicks it out of the set.  

 

Ah, well.  it's something I've wondered about for years. Next time I'll just transfer the backup set to a new backup set in which space has been properly allocated.  Thanks for your response, Lennart.  You've been a valuable member of the newsgroup.

Link to comment
Share on other sites

The performance hit is on the defrag software, not Retrospect.  Microsoft defrag want 15% free space to do its thing,  Auslogics wants 10% free space.  Otherwise they suggest not running them until that amount of space is available.  Ultradefrag, at some point, will have the same problem, as indicated under General Usage in their FAQ.

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...
 Share

×
×
  • Create New...