Aller au contenu principal

Is it safe to delete any increment backups after initial as long as you have most recent?

Thread needs solution

I have a full true image backup created in March this year 331gigs. Then incremental backups done weekly, some very large like 46gigs, some small like 3 gigs. How do I know which ones to save, I have run out of hard drive space on my 2 TB drive and can't afford another. Please tell me which ones I can delete and which ones I have to keep. Most recent one was Oct 2nd for only 4 mgs then I ran out of space. I'm confused. Thanks. See attached of my files...

Fichier attaché Taille
trueimagelogs2014.jpg 134.57 Ko
0 Users found this helpful

NO! Each inc file has its own individual piece of the backup. The sequential numbering from S1 to S21 must be maintained. The only one which can be safely deleted is the newest one which is the S21, v1-2

What happened to the 8 files from S2-S9? Did you just recently delete these missing files or did you ask the program to consolidate them? Was the S2-S9 in existence or missing when the most recent S21, v1-2 was created?

Normally,
If sequential S# is missing, any newer S# after the missing is worthless.

Your next step must be to validate what you have and the file to be selected for validation is the S21_v1-2.
If that files fails validation, then the only file which is usable is the first full file of March 9 as the chain was broken when older files became missing--if S2-S9 were manually deleted.

Validation of what you have has to be your next step to verify whether any of the incremental Tib files have any value.

Yes I deleted them as I ran out of space. There is no way to fit them all. So which ones should I delete. Then I will run a full new one, validate then maybe delete the old one? Thoughts.

Well I ran that validation on that file and it failed, so now I am validating the full backup and it says Validating all versions of the backup. So should I have deleted all the versions and then validate it?

Whether you deleted all but the full will have no effect on the validation--if it was the full which you selected for validation. Only the full has any use.

Set up a new task similar to the GH12 example and that example uses automatic cleanlup with the program deleting the older chains.
Have more frequent fulls with fewer inc's to be safe with your backups.

GH11. Create Custom Full Backup Scheme.Keep 4 versions (chains). The 4 is an example only with user choice for whatever number of chains to be retained best fits the individual needs..

GH12. Create Custom Incremental Backup Scheme. 6 Inc, Keep 4 chains. The 6-4 is an example only with user choice for whatever number of chains to be retained best fits the individual needs.
Note/example: If rule selected is "Delete older than 7 days" is selected,(which is a rule I do not recommend) deletion will not begin until the first chain (7 files) is completed and entire chain is older than 7 days.

GH13. Create Custom Differential Backup Scheme. 2 Diff, Keep 2 chains. The 2-2 is an example only with user choice for whatever number of chains to be retained best fits the individual needs.

As Grover says, you cannot delete even a single incremental in a chain. If you do, all subsequent incremental backups that relied on the deleted backup will be useless.

A task for Incremental or Differential will always begin with a full backup. That is necessary, as that becomes the baseline.

For an Incremental task, after the first full backup, subsequent backups will be incremental, each one based on changes since the previous Incremental backup, all the way back to the second backup being incremental based on changes since the full backup. As such, you need all links in the chain, all incremental backups right back to and including the first full backup, in order to Restore.

For a Differential task, after the first full backup, subsequent backups will be differential, each one based on changes since the first full backup. To restore, you would need just any Differential and the Full backup on which it is based.

You should not allow an incremental chain to become too long. An incremental restore depends upon every incremental in the chain being valid, including the original full. It's better to limit each chain to just a few incrementals, followed by a fresh full backup to start a new chain.

You should validate backups periodically. That would alert you much if the full backup were missing or unreadable.

Hi and thanks, I lost this website and finally found it and my post. Thanks for the advice. Well I ended up deleting all my backup's except the first one, which is about 338gigs. I have a 2 TB external, for some reason I am guessing the hard drive itself is also backing up. So I have no space left to make a full backup. I need to clean this off, but not sure what to delete. It's a seagate 2 TB portable external. After cleaning off a few hundred gigs, I am down to mgs available again. Something is eating my space.. I hate this..

Janine,

A normal backup will somewhat compress your data so your full backup should be about 65-70 % of the USED SPACE for whatever is being included within the backup. If you are concerned at something wrong is being included within your backups, imulate editing your backup task and verify which items are selected for backup? Look at my signature link 2-A and the first few pictures shows the disk being selected for backup.
Within that 2-A link, note that picture 3 has the disk as being selected. If you hover your mouse pointer overtop you disk selection, note that the picture will also show which partitions are being included.

If you wish to post a picture of your storage folder showing the tib backup files, perhaps it will provide some clues as to the problem.
If you do this, sort the files in date/time order before capturing so the tib files will be in sorted order.

Also note, that the defrag function can cause extra large backup sizes for your incrementals such as the 46GB size.
A defrag should only occur prior to a full backup and must be disabled prior to any further backups. TrueImage backs up used disk sectors so running a defrag relocates data and that old data iin a new location is being included within your backups as new. Make sure defrag is not an issue here and some utility programs run them automatically trying to achieve better performance.