4
The backup file maintains metadata about the database and files that SQL Server uses during the restore process. Part of that metadata is a listing of data and log files that are in the database, and their respective sizes (as well as other information).
If you run RESTORE FILELISTONLY you can see the minimum size required for each data and log file in the ...
3
I have not solved the problem The problem reamains that bad backups
are being taken. I am worried that something is wrong with our prod
server in General or those databases in particular. I am afraid that
my work around will only hide the problem and that we have a train
wreck coming down the line.
Yes. You should be afraid, and proceed on the ...
2
You should not have your backup files on the SQL server as you would lose those backup if ever there is an issue with the SQL server.
Best practice would be to store your backup outside of the SQL Server (on a shared folder for example) that can be accessed by both node of the AG.
As the primary node can switch from one or the other node, you should code ...
2
The size of the backup file is only partly relevant. The restore process first have to create the database files (the "containers" as I like to think of them) and they need to have the same size as when the backup was produced.
So you have have a database with only small amount of information, but sitting in large database files.
Instant File ...
2
Till full\Differential backup I can understand it is like the snapshot of the database
No it does not takes snapshot of the database, it backups up the actual data. Please read the old article written by Paul Randal Understanding SQL Server Backups
how T-log Backup works, if we have point in time recovery.
I would quote from the article instead of ...
2
I think this is the core methodology of database backup and restoration and the whole purpose of taking backup is to be able to restore it to point in time in case of any untoward incident like disk failure, server failure or database crash etc.
Lets understand them one by one.
Full Backup
A full backup, as the name implies, backs up everything. It is the ...
2
I have difficulties understanding your question. Perhaps you can clarify or re-prase? Anyhow:
A regular log backup will clear the contents of the ldf file (a bit simplified). Using COPY_ONLY for the log backup will not clear the contents.
The .tuf file is not related to above. When you restore a log backup, you can specify that you can restore further ...
1
The error message is quite explicit:
Error: datadir must be specified.
The documentation is clear on this too:
--datadir=DIRECTORY The source directory for the backup. This should be the same as the datadir for your MySQL server, so it should be read
from my.cnf if that exists; otherwise you must specify it on the
command line.
When combined ...
1
Install it from PostgreSQL's own apt repository, adapted from these instructions.
sudo apt-get install curl ca-certificates gnupg
curl https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
sudo apt-get update
...
1
It's quite a long topic and for the most part it relates to technology that is irrelevant in this day and age (more specifically: tape storage). However here is a quick summary:
media set
An ordered collection of backup media, tapes or disk files, to which one or more backup operations have written using a fixed type and number of backup devices.
...
1
Log truncation frees space in the log file for reuse by the transaction log. You must regularly truncate your transaction log to keep it from filling the allotted space. Several factors can delay log truncation. One of the most probable reason - you didn't make log backups. You need to backup your transaction log and after that you will be able to shrink it. ...
1
So after digging around further i found how to do that.
In short i needed to take the system.users collection or rather use a query to get only users from that collection that follow a certain pattern. for me it was user@some.domain, without the query i would have gotten all service users also which i did not want or need.
The tricky part was mongorestore ...
1
Yes, they should be. Unless, you have configured datapump to exclude them somehow. Please share the command (and parameter file) that you use to make the datapump export.
Reasons why the dump file is smaller could be that you have large LOB indexes (which are not included, and should not be), or you are using compression.
1
The restore includes the public schema and so does create database. So remove the schema after creating the database so that the restore can create it without error.
Note: Following assumes -h -U -p are default and PGPASSWORD or .pgpass is set
psql << XENDX
drop database if exists DB_NAME;
create database DB_NAME;
/c DB_NAME;
drop ...
1
I had lots of confusion around the topic - In AG cluster restoring Log backup following with Copy - only full backup.
It is now working fine. We can use copy only backup from secondary replica:
USE [master]
RESTORE DATABASE [xxxxx_testDB] FROM
DISK = N'D:\Backups\FULL_COPY_ONLY\xxxxx_testDB_FULL_COPY_ONLY.bak'
WITH FILE = 1,
MOVE N'xxxxx_testDB' TO N'...
Only top voted, non community-wiki answers of a minimum length are eligible
