Page 1 of 1

How delete data from an older schedule

Posted: Tue May 17, 2016 5:39 pm
by BertVdA
Hi,

We used to have a Professional custom plan where Backupassist would back-up on a daily, weekly, monthly, quarterly and yearly basis. Since this was total overkill for what we really needed and taking up too much disk space, we changed the back-up schedule to Daily+N weekly, which creates a back-up every day and week (last 4 weeks).

This works fine except that the folders of the old schedule (Year, Quarter 4, Quarter 3, Quarter 2, etc) are still there, still taking up lots of disk space. So my question is how I can delete these folders in a safe way.

Thanks!

Bert

Re: How delete data from an older schedule

Posted: Fri May 20, 2016 4:04 pm
by TimN
Hi Bert,

It's Tim from BackupAssist.

You could delete the older backup files manually, however, if using Single Instance Store (SIS) this can take a while to delete files through Windows explorer due to the existing SIS hard links.

The quickest way around this would be to format the destination disk and run the new backup with the new schedule.

I hope this helps, Bert.

Tim

Re: How delete data from an older schedule

Posted: Fri May 20, 2016 4:48 pm
by BertVdA
Hi Tim,

But can I break hard links, and thus make certain files corrupt/invalid, by deleting old back-ups manually?

E.g. the very first back-up folder is called 'Year'. Is it possible that back-ups created today still refer (by hard links) to unchanged files in the 'Year' folder? And that when I'd remove this 'Year' folder, the links would be broken? Or is that not how SIS works at all?

Thank you,

Bert

Re: How delete data from an older schedule

Posted: Mon May 23, 2016 4:37 pm
by TimN
Hi Bert,

Deleting the older files manually would break the hard links between the files.

If the file has not changed since the 'Year' folder was created, then the hard-link would still be present.

For more information on how Single Instance Store (SIS) works, please refer to the following article:

https://www.backupassist.com/blog/suppo ... ard-links/

Regards,

Tim