Currently the jobs have been running longer than usual. I am suspecting a few variables (the synthetic full portion runs long & the jobs write to a cloud storage AWS) that might be the cause. I have two questions.
1) If I change the backup repository on the current job to a local drive (new location), would the job run a full backup on the next run or would it know its the "incremental" job based on the current old settings?
2) Also, If I plan to rearrange all my backup to the local computer drive and have a script to copy its content to cloud storage, would I need a full backup file, all the incrementals, and the chain metadata file for a restore?
1) Yes, if you change the target from AWS to local it will start a new chain so a new full & incrementals. You can move the data from AWS to local and map it to continue working on the chain but it is probably faster to start fresh.
2) You could use backup copy job to send data offsite; for more information see our userguide.
Personal blog: https://foonet.be
GitHub: https://github.com/nielsengelen
In addition to Niels:
you CAN restore from full backups (.vbk) alone as well - but in this case only this restore point represented by the .vbk file.
To import a complete chain you need all the files for it - therefore .vbm and all of the .vib/.vbr and .vbk files to restore to a restorepoint within the chain.
Thanks guys. Fresh job with new location is probably the better route. I was thinking to have 42 days backup to the local drive and have a robocopy script copy the last 7 days to cloud storage (AWS) to reduce cost.
So here is the logic.
Have a script to copy 8 files (1 chain metadata, 6 incrementals, 1 full) to AWS and remove any old files. Would this work? My goal is cover fire or hardware theft in the data center and still have something from the cloud.
Have you thought about utilizing the AWS cloud via VTL?
Using the storage gateway you could use AWS as a virtual tape drive and therefore have the complete management being done by VBR (supposing that you're running Enterprise edition or higher to have VM Backup to tape feature available).
Another idea could be to have a Win VM with necessary storage amount running in AWS with a Veeam proxy role deployed and to direct Backup Copy Jobs there (simple forever forward incremental backups plus - if needed - n-times GFS weekly/monthly/quarterly/yearly fulls).
Both solutions can be easily automated while with robocopy (which isn't bad at all but ...) you will probably need additional scripting to evaluate the chain (vbk plus vib's) to upload plus VBR knowing nothing of clouded restore points at all.
Finally you could also leverage Cloud Connect with a Veeam Cloud Service Provider of your choice - but you probably want to use your own AWS subscription?!
I have looked at VTL a while back. Originally our goal was to have a simple setup (to have a few days offsite for theft/fire)...We gone away from archiving data where we used to have tapes and kept backup for 5 years.
.