Jump to content

How to manage swapping drives?


pmcdonald

Recommended Posts

I run Retrospect 7.7 on a PC backing up to LTO5. Retrospect is scheduled to perform a nightly incremental backup on a NAS device (let's call it NAS 1). This entails reading the current contents of the NAS, matching it to the files in the backup set, and adding any new or updated files to the backup library. The system works well and means at most I lose a days work in the event of a catastrophic failure to our NAS.

 

I've recently purchased a new, larger capacity NAS (let's call it NAS 2) that I've copied all the material from NAS 1 onto. NAS 2 is now our working drive and NAS 1 is relegated to being a hot backup. You can never have too many forms of backup, right. The only problem I'm encountering is that the backup set sees the copied material on NAS 2 as ALL being different to what lives in the archive, so it wants to try and rebackup the entire drive. If it were only a few hundred GB I wouldn't fuss, but we're talking around 17 TB of data - weeks of backing up and close to a grand of extra media.

 

Is there any trick or setting to get Retrospect to backup just the material updated since the last backup? In the Matching option 'Don't add duplicates to Backup Set' is ticked and usually does the job - just not in this case. 'Match only files in same location' is unticked. The NAS to NAS copy did bring over the data and time stamps too, so as far as I can see the metadata of all the files is unchanged since the last backup, only the location is now a new NAS. Thanks for reading

  • Like 1
Link to comment
Share on other sites

Okay, so I'm still not sure what is causing Retrospect to see the copied files as new but I've gotten around the problem by adding a date variable to the scheduled backup. By telling it to ignore everything older than the most recent NAS 1 backup it simply backups only the new material on NAS 2 that has been revised SINCE the copy, if that makes sense. Works for me.

Link to comment
Share on other sites

If you look around the forum you see that this has come up from time to time before where Retrospect sees some or all of the files transferred to a new volume as having been changed. Assuming you are using SMB to communicate with the NAS and they use a Linux based firmware, it could be differences in the implementation of Samba on the NASes that is causing the Retrospect matching algorithm problems. When the Samba version was updated on the NAS I have this caused Retrospect to see all the files I was backing up from it changed but luckily it was only a few gigabytes worth of files! (Samba emulates files as being stored on a Windows file systems but with them physically stored on a Linux file system.)

 

As you state you are now using NAS 1 as a hot backup to NAS 2, is NAS 1 kept sufficiently updated to still be able to keep using it as the backup source until you can create new backup set based on NAS 2?

Link to comment
Share on other sites

If you look around the forum you see that this has come up from time to time before where Retrospect sees some or all of the files transferred to a new volume as having been changed. Assuming you are using SMB to communicate with the NAS and they use a Linux based firmware, it could be differences in the implementation of Samba on the NASes that is causing the Retrospect matching algorithm problems. When the Samba version was updated on the NAS I have this caused Retrospect to see all the files I was backing up from it changed but luckily it was only a few gigabytes worth of files! (Samba emulates files as being stored on a Windows file systems but with them physically stored on a Linux file system.)

 

As you state you are now using NAS 1 as a hot backup to NAS 2, is NAS 1 kept sufficiently updated to still be able to keep using it as the backup source until you can create new backup set based on NAS 2?

 

Ah, that makes sense. Thank you kindly for the reply and explanation Scillonian. NAS 1 was running DSM 3.x and NAS 2 was on DSM 4.3 so that could be the cause of that. My IT knowledge is limited at best - I fumble through what I need to fumble through and am blissfully ignorant of the rest - so I didn't even consider the possibility that updates would impact on file metadata.

 

As I type NAS 2 is dumping huge amounts of data back onto a freshly formatted and reconfigured NAS 1, and no doubt will continue to do so for the next several days, but the LTO backup seems to be happily up and running again using the method I detailed above. So we've got a solid backup in place until mid next week, when we'll have two solid backups in place.

 

To recap:

  • NAS 1 was primary storage
  • NAS 2 was used as a hot backup, running a scheduled clone backup every few hours
  • Retrospect running an LTO crawl nightly over NAS 1 adding new and updated files only
  • NAS roles were swapped so NAS 2 became the primary storage and NAS 1 was wiped, reconfigured in a more efficient array and then used as a hot backup running a clone of NAS 2
  • When shifted from NAS 1 to NAS 2 Retrospect saw the whole volume as new (all 17-odd TB of it)
  • I got around this by adding a date exclusion to the Retrospect script so it ignored data older than the date of the NAS swap above
  • All now runs well!
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...