I am having issues getting a script of mine to work and need some asstiance.
The goal of the script is to take SQL backups, ZIP them using 7zip, them move them to a NAS. After the move, the original backup is deleted, but not before confirming the name and size.
You can find my script here.
If there's a better way to achieve what I'm trying to do or an already built script I could be pointed to, that would be great!
Related
I am using PHPMYADMIN from SiteGround CPanel.
Story: I had Cloudflare setup for a php platform, I then realised it was causing issues so I removed it. The issue I'm left with is that half of my site is still running of (https://www.example.com).
What I have done so far: In the config files of my script I have already set it so that it runs through https alone.
What I want to achieve: I noticed in the database that there are some fields that are running through the www. I want to execute a command that will automatically find anything with my old domain (https://www.example.com) and replace it with (https://example.com). I noticed that the fields are not all appearing from a single column/file, it is all over the place, so a field&replace overall should fix the issue.
I would appecaite any help. Since it is database I don't wish to try out random things from different websites provding their feedback. I was recommended to use this website for assistance (if possible).
Thank you in advance.
Probably the most straightforward and quickest way, is to simply take a dump of the entire database, open the sql dump file in some text editor, and then do a text replace from [old url] to [new url]. Then import the dump file back to the database. This should work just fine and avoid the headache of uncertainty and risk over doing a write operation on the entire database's tables via some db query.
I've got a zip file of 1,6gb and it takes me forever to extract it on a server. I left it all night long and when i woke up it wasn't finished. There is no way to keep track how much time is left on extracting a file and how much percantage is done so i'm not sure if the whole thing works properly. Is there a way to exctract that file using File manager in Cpanel so that it can be done while the pc is off and maybe to note me on an email when it's done. I basically need to copy a webshop from live server to developers server and am just loosing too much time on that. So if anyone has a better idea how to extract it please feel free to suggest it.
P.S. Deleting of those files that did extract takes forever too
P.P.S. I'm a linux/SystemAdmin
If it's all about copying files from one server to another - why not just use rsync and avoid archiving?
I mean, if extraction is a pain - remove it from the equation :)
It is not a good ideato use the cPanel File Manager for this task, as the server will probably kill the extract process if it takes too long.
The best way to go about this would be via SSH, while logged in as root. If you need to switch off your computer, you should run it in screen.
You can also use unzipper.php which you can get from github.
It will require you to upload your file and unzipper.php too. Then run wwww.yourdomain.con/unzipper.php
I make a copy of an .mdb database (and it's other partition) every night, and test it by opening it up to see if it works.
By "make a copy" I mean:
I kick all the users out of the database who are connected via RDP (not automated...)
Rename both backend files...and then proceed to make a copy of the files. (automated...)
And by "see if it works" I mean:
Relink a frontend file (.mde) to both files (this is automated)
Open it (and it's other partition) with a frontend (.mde) and workgroup security file (.mdw) on my local machine to see if it works. (this is not automated, and the part I am focusing on here...)
There are only two tables in the other partition, so I run the part of the frontend file I know uses that partition to test if the backup is going to work.
Would connecting to the backup of the files and doing a query on some table in both partitions be enough to prove that the backup is good without actually looking at it with human eyes?
I have also automated the process of compacting the live database, but I don't feel safe automating this part until I have verified that the backups indeed work.
Also before I get any posts along the lines of "Why are you still using access?", let me just state that I don't get to make those decisions and this database was here a long time before I got here.
(Please Note: if you feel I have posted this on SO in error please feel free to migrate to the DBA SE or to Serverfault)
I have backed up a database I had created on an other machine running SQL server 2012 express edition and I wanted to restore it on my machine, which is running the same. I have ticked the checkbox overwriting existing one, and got this error:
Backup mediaset is not complete. Files: D:\question.bak. Family count:2. Missing family sequence number:1
This happens if, when you made the backup, you had multiple files listed in the backup destination textbox. Go back to your source server and create the backup again; this time, make sure there's only one destination file listed.
If you had more than one file listed as the backup destination, the backup is striped across them; you'll need all the files to perform the restore.
You can verify this by performing a RESTORE LABELONLY against the single file you copied to your destination server.
Sandra Walter's Answer provides an accurate description of what has happened, but I found the answer a bit lacking.
To make a backup which isn't striped (which is what has occurred in this situation), go back to the window where you setup the backup of your database. At the bottom is a list of paths where the different stripes will go to.
Go to each of the listed paths and delete the stripe of the backup.
Then remove all but one of the paths from the list in the window. And click the "OK" button. Your unstriped backup will be created at that one path.
Hope that helps.
My backup was scheduled on two different locations. once I selected both options during restoration its worked for me.
I altered a stored procedure and unknowingly overwrote some changes that were made to it by another developer. Is there a way to undo the changes and get the old script back?
Unfortunately I do not have a backup of that database, so that option is ruled out.
The answer is YES, you can get it back, but it's not easy. All databases log every change made to it. You need to:
Shutdown the server (or at least put it into read-only mode)
Take a full back up of the server
Get a copy of all the db log files going back to before when the accident happened
Restore the back up onto another server
Using db admin tools, roll back through the log files until you "undo" the accident
Examine the restored code in the stored proc and code it back into your current version
And most importantly: GET YOUR STORED PROCEDURE CODE UNDER SOURCE CONTROL
Many people don't grok this concept: You can only make changes to a database; you can't roll back the stored proc version like you can with application code by replacing files with their previous versions. To "roll back", you must make more changes that drop/define your stored proc.
Note to nitpickers: By "roll back" I do not mean "transaction roll back". I mean you've made your changes and decide once the server is back up that the change is no good.
"Is there a way to undo the changes and get the old script back?"
Short answer: Nope.
:-(
In addition to the sound advice to either use a backup or recover from source control (and if you're doing neither of those things, you need to start), you could also consider getting SSMS Tools Pack from #MladenPrajdic. His Management Studio add-in allows you to keep a running history of all the queries you've worked on or executed, so it is very easy to go back in time and see previous versions. While that doesn't help you if someone else worked on the last known good version, if your entire team is using it, anyone can go back and see any version that was executed. You can dictate where it is saved (to your own file system, a network share, or a database), and fine-tune how often auto-save kicks in. Really priceless functionality, especially if you're lazy about backups and/or source control (though again, I stress, you should be doing these things before you touch your production server again).
You could look through the cached execution plans and try to find the one where your colleague made his changes and run the relevant parts again.
EDIT
Although Bohemian looks to have a good answer if you've got the changes in the TL, this is what I'm talking about. Review the SQL text for the plan.
SELECT cached.*,
sqltext.*
FROM sys.dm_exec_cached_plans cached
CROSS APPLY sys.dm_exec_sql_text (cached.plan_handle) AS sqltext
But as squillman points out, there is no execution plan for DDL.
You won't be able to get it back from the database side of things. Your options at this point are pretty much limited to 1) recover from backup, 2) go to source control or 3) hope that someone else has a copy still up in an editor somewhere or saved to a file.
If neither of these are an option for you, then here's the obligatory "you should take regular backups and use source control"....
I'm way late to the game on this but I did this same thing this morning and found I had forgot to save my script at some point in the past and needed to recover it. (It will be in source control after I get done fixing this!!!)
Some people mentioned restoring from a backup but no one really mentioned how easy this is if you have a back up. Moreover, you aren't locked into rolling back the production database. I think this is key and assuming you have a back up I would say this is a much better alternative to what has been voted up to the best answer.
All you have to do is take your back up and restore it to a new database. Pull out the sp you are looking for and voila, you've recovered the missing code.
Don't forget to drop the newly created database after you've recovered the missing file.
I had the same problem, and I don't have the confidence to go restoring from log files to another server. I was pretty distraught until I realised the solution was very simple...
Press Ctrl-Z over and over until I had undone my changes and the run the ALTER PROCEDURE again.
Admittedly I was pretty lucky that I still had it there to revert to but it really is the easiest fix. Probably a bit late now though.
If you have scripted the stored procedure out from management studio object explorer this will work.
Before expand and collapse the object explorer just scroll and point to the stored procedure you have opened. Script the stored procedure as create or alter to then you can get the previous version of the proc since the object explorer doesn't refreshed yet. This is always my life saver.