Hi Guys,
Using Veeam 11 to backup to multiple jobs to a TrueNAS fiber channel storage unit. At 7:00 AM I have a Tape job to a GFS media pool all the previous days job files(VIB or VBK) to LTO-x. This media pool and disk and I am worried it is VERY fragmented.
I want to get my tape written at the speed of the LTO-x
Is there a way to copy the latest backup jobs to a location(ssd disk) and then have that 1 copy of 1 day written to tape?
Source - Destination
A) VMware - diskA(retention 30 days)
B) copy diskA - diskB(retention 1 day)
C) copy diskB - Tape(retention 1 year)
Can have all of the jobs for A run and then copy one at a time all the servers for B? Once B is finished can I have one job at a time copy to the tape so fragmentation is not an issue?
Thanks,
Joe
-
- Enthusiast
- Posts: 56
- Liked: 2 times
- Joined: Nov 10, 2020 8:07 pm
- Full Name: Joe G
- Contact:
-
- Product Manager
- Posts: 14840
- Liked: 3086 times
- Joined: Sep 01, 2014 11:46 am
- Full Name: Hannes Kasparick
- Location: Austria
- Contact:
Re: 3-2-1 fast last copy to LTO-x
Hello,
the backup copy job has a minimum of two restore points. If you delete the restore points of the backup copy job (Veeam PowerShell commands), then it would be forced to create a new full backup every time.
Yes, the backup copy job can copy all backups at once. A GFS tape job would start, once there are new restore points on that day (or "run after" could be used in the schedule for classic "backup to tape" jobs).
Overall I'm not sure, whether the whole concept makes sense. Today you copy incremental and full backups. With only one day / restore point, it would always be a full backup (to avoid fragmentation).
By the way, what makes you sure, that fragmentation is the issue? Are you using REFS / XFS and did you try "active full" backup jobs as alternative (which would avoid the fragmentation of XFS / REFS)?
Best regards,
Hannes
the backup copy job has a minimum of two restore points. If you delete the restore points of the backup copy job (Veeam PowerShell commands), then it would be forced to create a new full backup every time.
Yes, the backup copy job can copy all backups at once. A GFS tape job would start, once there are new restore points on that day (or "run after" could be used in the schedule for classic "backup to tape" jobs).
Overall I'm not sure, whether the whole concept makes sense. Today you copy incremental and full backups. With only one day / restore point, it would always be a full backup (to avoid fragmentation).
By the way, what makes you sure, that fragmentation is the issue? Are you using REFS / XFS and did you try "active full" backup jobs as alternative (which would avoid the fragmentation of XFS / REFS)?
Best regards,
Hannes
-
- Enthusiast
- Posts: 56
- Liked: 2 times
- Joined: Nov 10, 2020 8:07 pm
- Full Name: Joe G
- Contact:
Re: 3-2-1 fast last copy to LTO-x
Hi Hannes,
I want a spool location to stage the data before it gets written to tape. I want to stage 5 jobs and at 10AM push those spooled jobs that are completed to the tape. LTO-8 and LTO-9 are going to require similar "spool" locations to stream to the tape.
Thanks,
Joe
I want a spool location to stage the data before it gets written to tape. I want to stage 5 jobs and at 10AM push those spooled jobs that are completed to the tape. LTO-8 and LTO-9 are going to require similar "spool" locations to stream to the tape.
Thanks,
Joe
-
- Product Manager
- Posts: 14840
- Liked: 3086 times
- Joined: Sep 01, 2014 11:46 am
- Full Name: Hannes Kasparick
- Location: Austria
- Contact:
Re: 3-2-1 fast last copy to LTO-x
Hello,
that kind of staging is not in the product directly. As long as only full backups need to go to tape, you could create a new repository and delete all content from that repository regularly via Veeam PowerShell. That forces the next copy job to create a new full backup. The the full backup could be copied to tape.
That's more a "hack" and I would solve the root cause of the performance issue. If the repository is too slow to satisfy speed needs of the tape drive, then it's probably also too slow for emergency case restores to satisfy RTO times.
Best regards,
Hannes
that kind of staging is not in the product directly. As long as only full backups need to go to tape, you could create a new repository and delete all content from that repository regularly via Veeam PowerShell. That forces the next copy job to create a new full backup. The the full backup could be copied to tape.
That's more a "hack" and I would solve the root cause of the performance issue. If the repository is too slow to satisfy speed needs of the tape drive, then it's probably also too slow for emergency case restores to satisfy RTO times.
Best regards,
Hannes
Who is online
Users browsing this forum: No registered users and 7 guests